code_saturne User's Forum

Hello all:

I have a couple of questions about the simulation convergence in large domains:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Question 1:
I guess warning messages such as:
Warning:
--------
_iterative_scalar_gradient; variable: pressure; sweeps: 100
normed residual: 2.7940e+51; norm: 3.6097e+47
...is related with a poor quality mesh for the imposed mechanisms to be solved, so, should I simply improve the mesh or any other improvement in the solver shall be applied?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Question 2:
I guess warning messages such as:
Incoming flow detained for 447 outlet faces on 1032
...is related with the fact that through an outlet boundary condition the solved flow is trying to go inwards, so (as I have read in the theory manual) is detained.
I have checked from time to time this detention may unstabilize the domain and so, convergence (leading even the simulation to crash).
This happens for example, when an outlet is perpendicular to a flow and the eddies reaches the outlet. In these situations, the returning eddies does not enter the domain, and the pressure decreases so much the domain starts to behave oddly. This kind of situations uses to be solved keeping the outlet face away from the expected eddies situation although the mesh will be bigger as a consequence.
This also happen in other situations when the initial conditions are not correctly settled so that initially the domain is not fixed for the its movement to be outwards the outlet faces, which may happen when the domain is "twisted" (so that the initial conditions for the velocity vectors are difficult to define, with several and opposite to each other outlet faces) and large enough to not allow the initial "wave" of the inlets to arrive to the outlets and stabilize the domain before the simulation breaks.
As far as I have read, the boundary conditions can be defined in a more advanced way so that the outlet boundary conditions might be re-inforced. Is this the way to stabilize these situations or is it another strategy?

My case: A real-scale secondary air distribution duct system for biomass boilers.
Objetive: determine air distribution and pressure drop.
Geometry:
Inlet: one face +OY oriented at the bottom of the geometry (y=0)
Outlets (Several outlets in several levels)
L1 (y=3), one group of faces +OX oriented
L2 (y=10), four groups of faces, so that two groups are +OX oriented and the other -OX oriented.
L3 (y=20), two groups of faces, so that one group is +OZ oriented and the other is -OZ oriented.

Any suggestion?



Thanks in advance.

Hello,

1) and 2 may be related (in the sense that 1) increases the chances of 2) happening).

Is your mesh orthogonal at the outlets ? If not, extruding it for a few additional layers may help. In other cases, if "non-physical" (ie. unrealistically large) vortices start appearing a bit earlier, using relaxation of pressure increase (for steady cases) or significantly increasing the number of RHS reconstruction sweeps (by default, 2 for pressure, 1 for other variables) may help.

Regards,

Yvan

I attach details of part of the geometry domain (the whole flow domain has been divided so that a step-by-step simulation can be performed):


...and details of the mesh:



As it can be seen, the outlet surface direction is orthogonal to the flow, and the domain initialization is complex to define because the outlet direction is different to the inlet flow direction.
The mesh checking file is attached.

The relaxation factor for pressure (RELAXV(IPR)) is set by default to 1, which value shall I take?

Kind regards

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
EDIT:

No improvements has been achieved changing either the relaxation factor or the RHS Sweep reconstruction factor.
Logs of errors attached.

Hello,

I see that from the check_mesh.log file you have some cells that have a high non-orthogonality. My experience is that Code_Saturne doesn't like this type of cell and can cause the calculation to diverge or not run. I usually get around this problem by refining the mesh and eliminating those cells that have high non-orthogonality values.

Can you try to reduce the minimum cell size on the surface and volume meshes and test the new mesh(es) to see what happens.

Regards,

Brian Angel.

Hello Bryan:

Where do you see those cells in the check_mesh.log?

As far as I can read, the quality criterions shows:

Criterion 1: Orthogonality:
Number of bad cells detected: 0 --> 0 %

Criterion 2: Offset:
Number of bad cells detected: 0 --> 0 %

Criterion 3: Least-Squares Gradient Quality:
Number of bad cells detected: 52 --> 0 %

Criterion 4: Cells Volume Ratio:
Number of bad cells detected: 0 --> 0 %

Criterion 5: Guilt by Association:
Number of bad cells detected: 0 --> 0 %

Warning:
--------
Mesh quality issue has been detected

The mesh should be re-considered using the listed criteria.

The calculation will run but the solution quality may be degraded...



...which only seems to show that 52 (of 270645) are supposed to be "bad" according to Criterion 3. (rounding a 0% of the total cells)
I think I have performed simulations with nearly a 5% of "bad" cells according to this criterion.

Is this what you mean?

According to the mesher I have used this is the quality registry:


Does this registry indicate any useful clue for the later Saturne simulation?

Hello,

Regarding the orthogonality, your geometry outlets are orthogonal to the flow, but your mesh is not, in the sense that some of the faces of the tetrahedra are not orthogonal or aligned with the geometry.

Did you visualize the Code_Saturne quality criteria in mesh checking or mesh quality mode ?
Quality criteria are highly dependent on the discretization method, so although the mesher may provide some criteria, they are not a substitute for those of the code.

I suggest adding at least one or 2 layers of "extruded" cells (basically, extracting the outlet boundary, sweep it to a volume of 1 or 2 layers, and join it to the base mesh).

Regards,

Yvan

Hello,

After the lines that you have posted in your message, there are a series of lists or histograms for different mesh checks. One of these lists, starting on line 372 in the check_mesh.log file, called "Histogram of the interior faces non-orthogonality coefficient (in degrees):" indicates that there are cells in the mesh with a non-orthogonality between 69° and 77° (line 386). These cells may be giving you problems hence the proposal to use a smaller surface and volume mesh cell size to see if the non-orthogonality is reduced and alleviates the problem that you are having.

I have seen this numerous times recently with tet meshes (using v3.2.1) and refining the mesh by reducing the minimum cell size has solved the problem.

Regards,

Brian Angel.

Hello all:

According to Yvan's suggestions, I have extruded the outlet boundary faces as it can be seen in the following image:



...which only represents a small variation on the element number.
I have re-run the simulation with the new mesh but the values for the meshing quality criteria are still the same (as well as the warnings), so I guess those non-ortogonality-troublesome elements are not placed in the outlets. (as I feared)
Anyway the simulation behaves a little more stable so that I have been able to post process the results as the simulation fails.

The following (big) image shows the evolution of the results (velocity field) as the outlets begins to stop the flow entries up to the simulation fails. (read the image from the left to the right and from the top to the bottom)


I think as the outlet begins to block the entering flow, the simulation begins to be unstable (the the flow turns around).
This cases are usually solved by means of an initial volume condition so that the domain velocity is forced to be outwards the outlet boundary condition, but considering more complex problems, (with several outlets boundary conditions with different directions) this might not be an adequate solution.

By now, I will refine the mesh and re-run the model, lets see...

|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
EDIT:
Although a mesh refinement has been performed in the outlets, no improvements has achieved.

Error and "check_mesh" files attached for information purposes

Hello,

Progress has been made, which is good news. I think that the problem stems from the initial guess, as you have indicated. I think you have one outlet boundary so can you set the outlet boundary to inlet and define a -ve mass flow rate equivalent to what you are injecting via the inlet(s) (if you have several outlets then you can assume an equal division of mass flow per outlet) and then run the simulation. If it gets past the initial start-up phase let it run until it is stable and then change your outlet boundary condition(s) back to outlet. Then restart from this solution and see what happens.

Pls let me know what happens,

Regards,

Brian Angel.

Are you meaning to generate an initial solution via an inverse simulation?
To be honest, I have never tried to configure a forced mass flow outlet via a negative mass flow at a "supposed" outlet face.
I will share equally at the outlet face a negative mass flow inlet and I will configure the outlet at the inlet face, and I will perform a simulation just in order to establish a velocity domain as an initial solution for the "definitive" simulation.

I will try it tomorrow, it could be interesting.

I will keep you informed.