[thodi]

Hi all,


I have a mesh for the ONERA M6 wing geometry, to run it with RANS equations. I wanted to add a ffd box around the wing to define a testcase for optimization.

The FFD box I want to add has the same corner points as described in the tutorial for optimizing the ONERA M6 with inviscid flow. Since the wing geometry is the same, only a different mesh around it.

I only added the ffd box by running SU2_DEF with 'DV_KIND= FFD_SETTING' with the according setting. I did not do any actual deformation afterwards!
When I try to run the test case with the new mesh and same config I get a different convergence history afterwards and a slightly different flow solution.

For a further analysis I created two more box. One by taking the lines from the mesh file SU2_DEF gives out and copying them by hand to the original mesh file. The second one by creating a ffd box that is much larger than the wing.
Those two tests have the same result as the original mesh.
I plotted the density residuals for all 4 described flow simulations for comparison.


What I don't understand is why adding an ffd box can change the flow simulation at all?
If i only write the ffd box to the mesh file, but don't do a deformation the mesh should not change?

It would be great if someone can help me with this. Thanks in advance!

[pcg]

Hi Thomas,

Did you use the same number of cores running SU2_DEF to create the small and large FFD's ?
If you take one of the well converged solutions and use it as restart for the "small FFD mesh" are the initial residuals correct? (around -12)
If so, do they remain low or start increasing?

[thodi]

Hi Pedro,

Thank you for your reply.
The problem seems to depend on how I call on SU2_DEF, as you suggested. Originally I ran this on 4 cores: mpirun -n 4 SU2_DEF config_file.cfg
I repeated this and created the mesh with the ffd box again on only 1 process. With this new mesh the convergence is fine. So it really seems to be a problem with the mesh file that the parallel execution of SU2_DEF creates.


Comparing the mesh files directly is difficult, since SU2_DEF orders the lines for the elements of the mesh different when writing the output mesh file in parallel. So a comparison between the files creates lots of mismatches.
I'm not sure if this could be related with the problem, but I would not expect the order to make a difference as long as you have the same elements and coordinates?

I can try and run the problematic output with a converged flow solution to see what happens then.

[pcg]

Hi Thomas,

That is what I thought... My guess is that with the different order of elements, either parmetis makes a different partitioning or the RCM ordering of the points changes slightly.
We try to make those things repeatable by using stable sorts but we may have missed it somewhere. And SU2_DEF should not change the order of anything but that is more difficult to solve.
You can try using ILU instead of LU_SGS and increasing the number of linear iterations, on that example it is only 2. And also increasing the CFL, JST on an inviscid problem should be fine in the 100's

[eromir]

Hi Pedro,

I realized that python script uses multi processes for SU2_DEF. When I run shape_optimization.py with small FFD_BOX range, I see that nothing change on the surface mesh. I added the highlighted line into SU2_PY/SU2/run/interface.py to run it with 1CPU.

def DEF(config):
""" run SU2_DEF
partitions set by config.NUMBER_PART
forced to run in serial, expects merged mesh input
"""
konfig = copy.deepcopy(config)

tempname = 'config_DEF.cfg'
konfig.dump(tempname)

# must run with rank 1
processes = konfig['NUMBER_PART']
processes = min([1,processes])

the_Command = 'SU2_DEF%s %s' % (quote, tempname)
the_Command = build_command( the_Command, processes )
run_command( the_Command )

#os.remove(tempname)

return