[Bartosz.Ziegler]

Hi there,

I have a problem concerning the inverse pressure design of a transonic cascade (inviscid case, I am fighting with it since few weeks now). I can run the NACA0012 FFD inverse pressure design with no problems, but for a cascade flow it seems that there is a problem in SU2 4.0.0 when SU2_DEF deforms the periodic mesh. In the deformed mesh, in section where SEND_RECEIVE markers where in undeformed mesh, there is something like this:

MARKER_TAG= SEND_RECEIVE
MARKER_ELEMS= 486
111111111(...more ones...)1111111111111111111MARKER_TAG= SEND_RECEIVE
MARKER_ELEMS= 486
11111111(...more ones...)111111111111111111111111111111111111NPERIO DIC= 3

I have also just spotted that in the deformed mesh there is less nodes (by more or less the number of nodes corresponding to number of halo cells). This causes the shape_optimization.py to crash after first mesh deformation.

Is there any way to cope with that ? I really need help quickly! If not, then would it be possible to make the design efficiently by performing direct and adjoint solutions, then performing the SU2_DOT and using the gradient somehow to perform the deformations on non-periodic meshes, and then converting them back to periodic and repeating that process ?
Is that problem only in FFD ? I haven't tried other design variables yet. I am quite new to SU2 and everything takes me a lot of time. I am attaching my .cfg file.

Any help or advice is badly needed.

Bartosz

[talbring]

Hello Bartozs,

we are currently working on the improvement of FFD in combination with periodic boundaries.

If you need quickly a working version, try the branch feature_internalflow: https://github.com/su2code/SU2/tree/...e_internalflow

Get back to me if you encounter any problems.

Tim

[Bartosz.Ziegler]

Hello Tim,

Thank You very much for the answer. I might ask a stupid question but I am new to SU2 and a complete newbie when it comes to programming. You suggest to compile the version of SU2 that can be found in the feature_internalflow ? (I am also new to Github). I assume that I could do it alongside the version 4.0.0 I am having now and just replace the directories in system variables (or something like that)? I would rather not remove the functioning version I have now just in case of messing something up.

What I have established until now, is that what I described in previous post is not only the case of FFD, I had the same result with Hicks Henne bumps. What I managed to do untill now is to make few iterations with steepest descent by doing:
1. Compute direct and adjoint on periodic mesh with FFD definition
2. Perform SU2_DOT on it to get the gradient.
3. Estabisch new DVs ( for example by steepest descent)
4. Put new DVs into a congfig_DEF.cfg
5. Perform SU2_DEF on NON-PERIODIC mesh with FFD definition
6. Write the deformed FFD definition somwhere
7. Convert the deformed mesh with SU2_MSH to a periodic mesh (it looses the FFD definition in the mesh file at this stage)
8. Append the FFD definition back to the deformed, periodic mesh file.
9. Repeat 1-8

Ofcourse this is very inefective. And if no other solution comes up, I will try to continue that with fore exmple L-BFGS.
My assumption is that there is no error in the software, it is just that the optmization algorithm is not designed for periodic cases (I see that the software is aimed more in external aerodynamics).

I hope me feedback has any value, and thanks again for help.

Bartosz

[talbring]

Originally Posted by Bartosz.Ziegler

Thank You very much for the answer. I might ask a stupid question but I am new to SU2 and a complete newbie when it comes to programming. You suggest to compile the version of SU2 that can be found in the feature_internalflow ? (I am also new to Github). I assume that I could do it alongside the version 4.0.0 I am having now and just replace the directories in system variables (or something like that)? I would rather not remove the functioning version I have now just in case of messing something up.

Yes, exactly. Just download the zip here: https://github.com/su2code/SU2/archi...ternalflow.zip or use

git clone -b feature_internalflow https://github.com/su2code/SU2.git

in a terminal if you have git installed on your system. Then compile it the usual way and set the environment variables accordingly. SU2_DEF should then work with periodic boundaries and you can also use the shape_optimization.py script to perform the optimization.

[Bartosz.Ziegler]

Hi Tim,
Some problems again. I downloaded the zip with feature_internalflow, unzipped it, and now when I run the configuration:

./configure --prefix=/home/bziegler/SU2_INTERNAL CXXFLAGS="-03" --enable-mpi --with-cc=/usr/bin/mpicc --with-cxx=/usr/bin/mpicxx --with-CGNS-lib=/usr/local/lib --with-CGNS-include=/usr/local/include

I get an error:
checking whether the C++ compiler works... no
configure: error: in `/home/bziegler/SU2internalflow':
configure: error: C++ compiler cannot create executables

My ubuntu software center says I have the GNU C++ compiler (g++ 4.8) and didn't have that problem when installing SU2 4.0.0. The same happens when I try to make a simple build without mpi and CGNS

I am attaching the config.log which does not tell me much.
Should I install different compiler or am I missing something important.

Thanks in advance,
Bartosz

[talbring]

Hi Bartosz,

the config log already tells you the error:

g++: error: unrecognized command line option '-03'

Apparently you used a 0 (zero) instead of the letter O.

Tim

[Bartosz.Ziegler]

Wow,

Now that was a stupid mistake to make. Thanks, I managed to install SU2 and changed the SU2_RUN and SU2_HOME environment variables to new directories. I have one more problem. When I run shape_optimization.py it crashes on first try on DIRECT problem. I am attaching the terminal output and, log_out and configurations files created by the script.
In the configuration files created by optimisation script, it creates options BOUND_DV (even if it is not in the input .cfg, it then creates by default some big value) The problem is (I think) that BOUND_DV was design variable bound in SU2 4.0.0 (you can also see from terminal output that command shape_optimization.py runs the script from SU2 4.0.0 instead the one from 4.1.0 where the option for DV bound is different according to config_template)

I guess that there is a simple fix for that, but again it is beyond the capabilities of a long term Windows user

I hope this is the last nuisance that I am bothering You with.

Bartosz

Edit: I have just found that when I try to run SU2_CFD manually from terminal, it still tries to run the version from 4.0.0 Just like the export of environment variables gave no difference (but when I run 'printenv' I see SU2_RUN SU2_HOME and PYTHONPATH having values of correct dierectories). I was able to run shape_optimization.py (from 4.1.0 internal flow) by:
python "path to the internalflow4.1.0 shape_optimization.py" -f file.cfg but the optimization stopped after one iteration as in the adjoint folder, the calculated gradient was having constant close to zero components (attached of_grad). Interestingly, when I run the same config_DOT (only changing math problem from DISCRETE_ADJOINT to ADJOINT for older SU@ version) I get the sensible values of gradient (also attached). I still use the mesh with FFD information (3 boxes) created with SU2 4.0.0. Maybe the method for FFD specification in mesh files changed from SU2 4.0.0 to 4.1.0. I am attaching also my .cfg. Tomorrow I will try to generate FFD mesh information with the SU2 feature_internalflow 4.1.0 and update what came of my efforts.
Help greatly appreciated.

With many Thanks in advance
Bartosz

[Bartosz.Ziegler]

Hi there, again

The problem is still that the SU2_DOT from SU2 4.1.0 feature_internalflow in my case is not computing the gradient. What I have tried since yesterday:
1. I have generated FFD mesh information again with SU2_DOT from SU2 4.1.0 but it is in the same form as in SU2 4.0.0 (mesh file and computed in first design iteration surface_adjoint.csv are linked at the end of this post)
2. I tried to compute the gradient with SU2_DOT from SU2_4.0.0 and SU2_4.1.0-internalflow. Terminal outputs from both versions are attached to this post, also the .cfg for SU2_DOT is attached. As earlier, with 4.1.0 the gradient vector is of constant very small components while 4.0.0 gives sensible results.
3. I have replaced the SU2_DOT binary in the SU2 4.1.0 with the older working version but when running shape_optimization this will crash because of different option names for DV bounds and MATH_PROBLEM.

I think the best solution would be to establish why SU2_DOT (from 4.1.0 internalflow) calculate wrong gradient. The terminal output for FFD_CONTROL_POINT_2D is of different structure than for version 4.0.0 does it need different definition of DVs or FFD information ? In config_template.cfg it looks the same for both versions.

Bartosz

mesh+surface_adjoint.csv: http://www.filedropper.com/meshandsurfacesensitivity

[talbring]

Hi Bartosz,

thanks for sharing the mesh and the config. I will try to figure out what the problem is there. I wouldn't rule out that there is a bug somewhere.

Tim

[talbring]

Hi Bartosz,

I just had a look at the FFD box you defined. You don't need to define multiple boxes. It is enough if you just define one rectangular box that contains the blade.

The problem with your boxes was, that a lot of boundaries were crossing the blade. In order to keep the continuity of the surface, the control points on this boundaries (+ the ones next to them if FFD_CONTINUITY=2ND_DERIVATIVE) are fixed.

Note that currently the movement of the control points is restricted to a fixed direction. We are working on that so that a general movement is available during the next couple of days.

There is also a lot more regarding turbomachinery features for SU2 coming in the next months. So stay tuned!

Tim

[Bartosz.Ziegler]

Hi Tim,

Thanks for the answer. I thougth that this is the way of building more complex boxes. In the ones I have described the boxes where connected so whole designed marker was insight boxes. Can I somehow create a box that is not a rectangle (for example by defining the list of control points of a single box ? In my case I think I have quite a different need for "resolution" of the control points at different blade sections. I will try with a single box as soon as possible and post the result here. I am also awaiting any more advice from your side as they are very valuable for me.
I look forward on whats comming up in SU2 for turbomachinery flows as I am quite interested in adjoint inverse design for such cases.

Bartosz