code_saturne User's Forum

Hello Code_Saturne community,

I am currently running an LES simulation (WALE model) of a rotating disk cavity with axial through-flow on a cluster (using MPI). I am trying to impose synthetic turbulence at the inlet using the Synthetic Eddy Method (SEM).

Case Setup:
Version: Code_Saturne V9.1
Geometry: Annular inlet (Outer Radius = 0.07m, Inner Radius = 0.052m).
BC: Inlet axial velocity = 2.93 m/s. The Problem:
I implemented cs_user_les_inflow.c based on the standard examples, setting constant values for the reference velocity,
, k and ϵ in the cs_user_les_inflow_define function. However, the run_solver.log indicates that the dimensions of the SEM virtual box are infinite. It seems the algorithm calculates the maximum coordinates correctly (matching my geometry), but the minimum coordinates (coo_min) are stuck at a negative infinite value (approx -1e30).

Here is a snippet from the log:

-------------------------------------------------------------

SEM INFO, inlet "0"

Max. size of synthetic eddies:
max(sigma_x) = 0.007668, at coordinates (-0.000000,-0.052013,-0.000274)
max(sigma_y) = 0.007668, at coordinates (-0.000000,-0.052013,-0.000274)
max(sigma_z) = 0.007668, at coordinates (-0.000000,-0.052013,-0.000274)

Number of min. clippings (eddy size equals grid size):
sigma_x clipped 0 times
sigma_y clipped 0 times
sigma_z clipped 0 times

LES SEM: dimensions of the virtual box:
Lx = 1000000015047466219876688855040.000000, coo_min : -1000000015047466219876688855040.000000, coo_max : 0.007668
Ly = 1000000015047466219876688855040.000000, coo_min : -1000000015047466219876688855040.000000, coo_max : 0.077651
Lz = 1000000015047466219876688855040.000000, coo_min : -1000000015047466219876688855040.000000, coo_max : 0.077651

Number of eddies leaving the box (regenerated): 0

------------------------------------------------------------- I have already tried setting cs_les_inflow_set_restart(false, false) to ensure no old checkpoints are read, and I confirmed that vel_ref is non-zero.

Could this be related to a parallel reduction issue with the bounding box calculation on annular geometries?
Any insights or workarounds would be greatly appreciated.

Thank you!

Hi everyone,

I have some new findings regarding my simulation.

I discovered that when I run the calculation using a single core (serial), the "infinite virtual box" error does not occur. However, as soon as I switch to multi-core parallel computation (MPI), the virtual box coordinates become infinite again.

Furthermore, even in the single-core case, the dimensions of the virtual box seem incorrect:
It only covers the inlet area located in the first quadrant (positive Y and Z coordinates), instead of the full geometry.
It has zero thickness in the X-direction (the streamwise direction), showing Lx=0.

I am currently stuck on this issue and would be extremely leaf grateful for any guidance or suggestions.

Thank you very much in advance.

Hello,

This seems to be due to an incorrect handling of reducers, fixed in commit 5de8c9.

So updating the code should fix hte issue (v9.1 was released Dec 30, so this is a good option).

Best regards,

Yvan

Yvan Fournier wrote: Thu Jan 08, 2026 12:44 pm Hello,

This seems to be due to an incorrect handling of reducers, fixed in commit 5de8c9.

So updating the code should fix hte issue (v9.1 was released Dec 30, so this is a good option).

Best regards,

Yvan

Hello Yvan,

Thank you very much for your suggestion.

I am currently using a V9.1-alpha version that was installed about six months ago. Do I need to perform a full reinstallation of the software to apply this fix? Or is there a faster way to do this?

Thanks again for your help.

Best regards,
Sun Ziyi

Hello,

If you still avec access to the build directory, you could edit the source code to apply the patch, then got to the build directory and simply re-run "make install".

Otherwise you may try to include the fixed file with user-define files, but you may have link issues related to multiply-defined symbols (at least it's easy/quick to try).

Otherwise, reinstalling (and updating) the code is the safest solution. I think there are also some recent LES balance fixes, so that may be one more reason for updating.

Best regards,

Yvan