Stationary vs. non-stationary NS equations in Code_Saturne

Miscellaneous discussion topics about Code_Saturne (development, ...)
Post Reply
pomarede

Stationary vs. non-stationary NS equations in Code_Saturne

Post by pomarede »

Hi everyone,

I have a question about the stationary mode: in the numerical scheme used to solve stationary Navier-Stokes equations, where is the difference with the non-stationary solving, since the solution of the first problem is obtained as a limit of the second one ?

Thank you for your kind enlightening :)

Marie
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Stationary vs. non-stationary NS equations in Code_Satur

Post by Yvan Fournier »

Hello Marie,

There are 2 "steady" algorithms in Code_Saturne.

The first (idtvar = 2 in Fortran, SIMPLEC in the GUI) is similar to the unsteady algorithm, but uses a local time step (trying to ensure a local CFL close to 1). As such, intermediate results can not be interpreted as matching a given physical time, but convergence is usually much faster than when using a spatially constant time step.

The second (idtvar = -1 in Fortran, SIMPLE in the GUI) I know less about. It was intended to be closer to a "true" steady algorithm, but it is often less well-behaved than the first, and we also have less feedback. So I'll let others complete this post...

Regards,

Yvan
CAVT
Posts: 9
Joined: Wed Mar 14, 2012 9:10 pm

Re: Stationary vs. non-stationary NS equations in Code_Satur

Post by CAVT »

Marie,

Although I have not deeped into Code_Saturne's source code and theory, one of the risks of using a stationary model in some CFD codes is that it will try to find a stationary solution, so three possibilities arise (asuming the mesh and initial data is of good quality):
1) A stationary solution exists, it is reached, and the real-life case also exhibits the stationary behaviour.
2) A stationary solution exists, it is reached, but the real-life case never reaches such condition. This is because the chosen model is not accurately representing the real case, and so you only have a valid mathematical solution with no physical meaning. Imagine solving an ideal ballistic trajectory and you get complex roots for the equation; you'll have a mathematical solution, but in real life it means such a shot is impossible with the given data.
3) A stationary solution doesn't exist and the numerical solution diverges. If you are sure that the real-life case does develop, then check your inputs and chosen model.

A non-steady solver may or may not end in a stationary solution after sufficient iterations. This heavily depends on the input, both for the data and the numerical method variables (mesh quality and refinement, CFL, relaxation factors, etc.).
Post Reply