Question on Steady vs Unsteady RANS in Code_Saturne

[ximeng]

Dear Yvan,

I would like to clarify how steady and unsteady RANS are selected in Code_Saturne. Am I correct that choosing Constant or Adaptive time step corresponds to unsteady simulations, while Steady (local time step) corresponds to a steady simulation (But why does the Steady option still require input of adaptive time-step parameters, is it the “pseudo-time”)?

In my case, I used the Adaptive time step option for a wall-bounded square cylinder. The flow should be unsteady, but the results appear nearly steady: the time history shows almost no variation, and the snapshots do not reveal vortex shedding. Do you have any suggestions on how to address this? Is there a specific option I need to enable for URANS?

For reference, I am using Code_Saturne 8.0 with an ABL inlet profile and wall functions at the wall. My setup.xml file is attached.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

The "steady" option is actually (as mentioned) "pseudo-steady", because it is not based on a steady algorithm, but on an unsteady algorithm with a local time step which allows faster convergence to steady state.

In most cases, the fact that a RANS computation leads to stable or fluctuating results depend on a combination of that case's physical behavior, time step/CFL aspects, numerical options, and mesh complexity and quality.

When you do observe fluctuations, they should be compared to the turbulence model's local time scale, to determine whether this may make physical sense (intepret with caution), or have a period which is smaller than that ime scale, in which case they can be considered as numerical artifacts/parasites.

If a case is very stable, this might simply be because the actual physical behavior is stable,

Regards,

Yvan

[Antech]

Sorry, as I can see, he asks how to switch to transient case (with inner iterations on each timestep) using time stepping options in GUI. Something like Constant time step + Inner iterations.

[Yvan Fournier]

Hello,

Inner iterations (nterup) can be used in the velocity/pressure coupling algorithm mostly for FSI computations, but I do not think they ate required for URANS. The same, sweeps for each solver are used to better handle mesh non orthogonalty (where some reconstruction terms are handled explicitly by increments in sub-iteratiobs), and for transient flows, this is recommended over than using relaxation, as it avoids degrading the time scheme.

In code_saturne, I am not aware of sub-iterations being needed for unsteady RANS. There is actually nothing specific separating URANS from RANS in code_saturne, at least from what I understand from conversations with turbulence specialists. I'll check with them in case there is a subtle difference I forgot.

Regards,

Yvan

[Antech]

Hello. It looks strange. As I know, inner iterations are used to stabilize linear system coefficients because they depend on variables solved (velocity, temperature, composition). So, in dynamic approach, inner iterations a always required. In static cases there is no reason for accurate coefficients unless the solution is converged. That's why they use artificial time step: coefficients calculation is intergated with main solution process that saves lots of time with the same result. But it's only a rough approximation of dynamics. If you need true dynamics, you need inner iteration on every big iteration to converge coefficients.

[Yvan Fournier]

Hello,

This really depends on the algorithm you use. In code_saturne, most models assume physical properties do not change too rapidly (otherwise, other types of solvers or algorithms are used, such as the cycle used in neptune_cfd's multi-phase solvers). The segregated nature of the solver in code_saturne already limits the maximum CFL flow somewhat, so we usually do not need inner loops because we do not have "big iterations".

There are some specific updates for example when soling for 2nd order in time with variable density, but this is still not a full sub-cycle. The theory guide of code_saturne may be too detailed for some aspects, and not enough for others, but the basic solution scheme description should still be up to date.

Best regards,

Yvan