Configuring multipoint shape design for incompressible sim?
 

Hello,

I'm hoping to take advantage of the multipoint optimization feature for my shape design. However I think I may need some help.

My first question: 1. Is the multipoint option compatible with my first order, incompressible CFD simulation?

If yes, then I have two follow-up questions:

2. What options can I include to take advantage of the multipoint feature?
3. Can I use a farfield in my simulation, or should I reconfigure to use an inlet/outlet?
(SU2 prompted me to add config options for inlet/outlet when I include MULTIPOINT_* settings, which makes me think that perhaps inlet/outlet is the problem here.)

Some details on what I've tried so far:

I did a test run using the settings MULTIPOINT_SIDESLIP=(-11, 0, 11) and OPT_OBJECTIVE=MULTIPOINT_DRAG in addition to my usual settings, and have a few questions about what I see in the results.

From my test run, I see a MULTIPOINT_0 directory in both DSN directories (OPT_ITERATIONS=2 for testing). However, there are no other MULTIPOINT_* directories, and SU2's output indicates that CFD ran the simulation with 0 degrees of sideslip.

Thanks!

Since the above posting, I've learned a bit more about how the shape optimization script works. More recently I've tried hacking my way to an incompressible multipoint optimization. I am now using v7.0.2.

TL;DR To try and hack an incompressible multipoint optimization, I tried hardcoding velocities for each point. This was done in functions.py and gradients.py. (Velocities were set via calls to config/konfig.INC_VELOCITY_INIT in the appropriate spots in each script). However the mesh output by SU2_DEF with this approach is defective. It is about 1/3 the size of the initial mesh, and is missing the "NDIME" and "NELEM" declarations.

My hypothesis is that my INC_VELOCITY_INIT additions to gradients.py messed something up in the deformation, and about a third of the deformed file is not being written as a result. If anyone has ideas, I'd love to hear them!

Long version:

After digging through the python scripts, I realized that the multipoint() function in functions.py could be easily altered to set a new INC_VELOCITY_INIT for each direct run in the multipoint optimization.

This works well - when I altered functions.py this way, each direct run in each multipoint featured the desired initial velocity. This hack didn't obviously break anything, and I ran 6 design iterations with OBJFUN and GNORM decreasing each time. (Note that for each point in this optimization, the adjoint ran with the INC_VELOCITY_INIT specified from the config file submitted to shape_optimization.py.)

To change the velocities for each point in the adjoint, I hardcoded the same initial velocities in gradients.py as I did in functions.py. This time I ran into trouble. I do get a deformed mesh in DSN_002, but that's about as far as things get. SU2 throws an error before running CFD for point 0 in DSN_002.

This deformed mesh is strange. For one thing, the deformed mesh file is ~1.5E7 lines long, as opposed to the original's ~4.3E7 lines. My initial hypothesis is that the deformed file doesn't include at least the first 60% or so of the original file (as far as I can tell). This missing 60% includes the "NDIME=" and "NELEM=" declarations, which is what causes SU2_CFD to throw an error.

Another hypothesis is that my hack messes something up for the volume deformation computation. Maybe the volume deformation is failing silently, but the rest of the deformed mesh still gets written, and so I end up with a whole bunch of missing points in my deformed output file.

Does anyone have ideas as to why I might have end up with a faulty deformed mesh file? To not even have "NDIME" and "NELEM" in the file seems strange to me.

Update:

As it turns out, the mesh issue seems to have been due to an incompatibility between the file system used by my university's student computing cluster and SU2's file writer. TL;DR the hardcoding described in my first post in this chain seems to be functional! The multipoint runs without error, and the objective is reducing in magnitude with design iterations.

The file system I was using is a traditional UNIX file system. My sysadmin mentioned that my file writing issue might have been due to the filewriter expecting a parallel file system. So I tried my hardcoded values on a single, large memory node and my mesh writing problems went away.

As a side note, I think this success can be seen as a testament to SU2's architecture. To me it's pretty incredible that I could extend an existing feature to serve my needs with basically just 6 lines of code. Nothing broke, and the compartmentalized nature of SU2 meant that the objective function still worked as I'd hoped. I think that's pretty cool!