[pro_]

In the study of the aeroelastic Isogai Case A such as in this paper,
https://kiwi.oden.utexas.edu/papers/...es-Willcox.pdf

It states that, using SU2, they first initialized a steady state solution for an unsteady simulation. How do i go about in doing this (in general)?

Do i need to make 2 configuration files, one that is for the initial steady and the other for the unsteady?

I have tried this, and set the unsteady config file to restart from the steady config but it gives me an error, where it can't find the restart file. So i assume I can do this all in one config file?

I have checked the tutorial on Unsteady NACA 0012, where i assume they first initialized a steady state solution. But attached in the picture is where i dont understand how they did the following.


Attached is an example of my config file

[pcg]

I don't think you can do it in one config file.
I would just rename and duplicate the steady restart according to the time-domain naming convention, and then start the unsteady simulation.
Note that the first time steps of such an unsteady simulation are not useful, you still need to wait for transients to clear and for the simulation to start showing some kind of periodic behavior (starting from steady state hopefully makes this quicker...).

Regarding the passage you highlighted, I think it is not referring to this restart process, they are explaining the dual time-stepping strategy in simple terms (i.e. what goes on inside the solver, it is not something accessible from the user side).

[pro_]

Hi, I have renamed my steady state solutions (restart_flow) to solution_flow_00000. Running this would give me an error of 'negative iterator etc.' I mean i understand the DUAL_TIME stepping strategy would require 2 solution flows, I dont understand how i can create 2 steady state solutions (meaning i dont understand the logic behind this). So what i did was i copy pasted the solution_flow_00000.dat file and renamed it to solution_flow_00001.dat. I still get the error of a 'negative iterator'.

Ive attached my steady config file, hopefully you can help me out here.

Moreover, on the topic of the typical section model, I would like to ask. Is there anyway i can define the x position of the elastic axis in SU2? Based on the template only the Xcg is written.

Would the Elastic axis location be defined by the SU2 variable REF_ORIGIN_MOMENT_X? (for a typical section)

% Distance in semichords by which the center of gravity lies behind
% the elastic axis
CG_LOCATION= -0.2

If i can verify, does the CG_LOCATION defined above coincide with the attached picture?

[pcg]

You need to set RESTART_ITER=2 (1 more than your last restart)
I cannot help with the aeroelastic features, I never used them.

[pro_]

Originally Posted by pcg

I don't think you can do it in one config file.
I would just rename and duplicate the steady restart according to the time-domain naming convention, and then start the unsteady simulation.
Note that the first time steps of such an unsteady simulation are not useful, you still need to wait for transients to clear and for the simulation to start showing some kind of periodic behavior (starting from steady state hopefully makes this quicker...).
.

Hi, you also mentioned removing the first few time steps
Referring to my attachment, would that mean removing the time history up to the blue line?

[pcg]

A lot more than that, the characteristic time (period) seems to be around 0.08s, I would disregard around 10 periods, after which maybe you start seeing a clearly repeating cycle (same peak to peak amplitude, same average, etc.).
That is assuming what you are studying is periodic. If you want to study a short transient that is not periodic, e.g. a quick movement of a control surface, you still need an "unsteady initialization", the gist of it is, until the initial particles (from a steady state of freestream initialization) leave the domain the results are not good.

[pro_]

Originally Posted by pcg

A lot more than that, the characteristic time (period) seems to be around 0.08s, I would disregard around 10 periods, after which maybe you start seeing a clearly repeating cycle (same peak to peak amplitude, same average, etc.).
That is assuming what you are studying is periodic. If you want to study a short transient that is not periodic, e.g. a quick movement of a control surface, you still need an "unsteady initialization", the gist of it is, until the initial particles (from a steady state of freestream initialization) leave the domain the results are not good.

It seems that when i try restarting from my steady solutions, the unsteady solution quickly diverges. Any clue as to why this occurs? and how shall i get around this

[pcg]

You have a moving grid problem, you are probably missing the grid velocities when you restart (similar to this problem Restart causes FGMRES orthogonalization failed).
Try using RESTART_STEADY_STATE= YES and be sure to use v7.0.3.

[pro_]

Originally Posted by pcg

You have a moving grid problem, you are probably missing the grid velocities when you restart (similar to this problem Restart causes FGMRES orthogonalization failed).
Try using RESTART_STEADY_STATE= YES and be sure to use v7.0.3.

I have tried that but obtained a ' linear solver diverged'. I think it has something to do with my initial steady state solution. So to clear things this is what i have done,

Ran the SAME steady state case TWICE and renamed each restart_flow file to solution_flow_00000 and solution_flow_00001, twice because my unsteady simulation is in DUAL_TIME.

I wonder if this is actually a correct procedure?

[pcg]

I played around with your case and I think there is a bug somewhere preventing aeroelastic restarts from steady state. Likely because the grid velocities are not in steady restart files.
I'll investigate this a bit but for now the conclusion is there is a bug.

On another note your case will run much faster if you use ILU as the preconditioner for deformation (for the reasons explained here https://su2code.github.io/docs_v7/Li...econditioners/)

[pro_]

Originally Posted by pcg

I played around with your case and I think there is a bug somewhere preventing aeroelastic restarts from steady state. Likely because the grid velocities are not in steady restart files.
I'll investigate this a bit but for now the conclusion is there is a bug.

On another note your case will run much faster if you use ILU as the preconditioner for deformation (for the reasons explained here https://su2code.github.io/docs_v7/Li...econditioners/)

Thanks for taking a look into the case. Will take your advice