Hello,
I am importing my mesh in .neu format and trying to run a basic steady isothermal flow calculation on Code_Saturne 1.3.3. The preprocessor imports my mesh correctly but when I run the calculation and try to track the residuals by opening the listing file in the tmp_Saturne/ directory, all I see is this at end of the file:
MAIN CALCULATION
INSTANT 0.100000000E+01 TIME STEP NUMBER 1
— Phase: 1
Property Min. value Max. value
Masse vo 0.1179E+01 0.1179E+01
Visc. la 0.1830E-04 0.1830E-04
visc. tu 0.8960E-01 0.8960E-01
** INFORMATION ON BOUNDARY FACES TYPE
Phase : 1
Boundary type Code Nb faces (tot/loc) Min index Max index
Entree 2 1178 663 1 663
Paroi lisse 5 6900 1636 664 2299
Paroi rugueuse 6 0 0 2300 2299
Symetrie 4 0 0 664 663
Sortie libre 3 1178 0 664 663
Indefini 1 0 0 1 0
However, I get no error message and the calculation keeps running (infinitely it seems). Would you know what could be the problem? Is there another way to track the residuals?
Thanks,
Axel Cablé
The residuals are displayed in the listing, but your calculus stops before to print them 
Does your calculus run on several CPU ? Do you use user subroutines ?
Your Time step is set to 1 sec. It’s big but it depends on your cell’s size of course. Is it OK with this value and a reasonable CFL number ?
Thanks for your answer Jean. I finally found the problem, I used to run my calculation on 2 nodes of 4 processors, I tried with 1 node and 8 processors and it works fine now.
About the time step, I’m running a steady-state calculation. So what does the “iterations number” entry mean? (in Steady Management folder). Should I just leave “1” here and it will run as many iterations as needed to obtain sufficiently small residuals?
No, unfortunately Code_Saturne has no automatic stop when the residuals you want are reached in the frame of the steady state algorithm. So you have to set a number of iterations, and after the run, you have to check if the convergence is OK. If not the calculation must be restarted.
Warning: I am not sure, but I understand in the listing that “derive” means the variation of a variable between to iterations, and that “Norm. residual” is related to the convergence of the iterative solver. Therefore, in order to control if Code_Saturne has reached a steady state, I believe that one does check the “derive” in the listing.
Perhaps the development team can confirm (or not!) this affirmation?
Jean is right, indeed!
You can consider the derive as the relative difference between two iterations, basically (not completely exact though…):
derive = |u(n+1)-u(n)|/|u(n)|
Thanks, this is some very helpful information. What is the usual convergence criterion for “Norm. residual” and “derive”? Around 10-5, 10-6? (studied case deals with air diffusion in rooms)
In the GUI there is a parameter “Solver precision” (heading Equation parameters). The solver has converged when “Norm. residual” < “Solver precision”. By default the value of “Solver precision” is 10 -8 . I think it is to low. A more commonly used value is 10 -5 (for all variables) and calculus are faster.
See http://code-saturne.org/forum/viewtopic.php?f=9&t=670
For me the “derive” is not a convenient criterion to evaluate the convergence. I personally prefer to look at the evolution of monitoring points for both steady or unsteady algorithm.
Ok. I’m trying to look at the evolution of the monitoring points but I only get the records for the 10 first time steps, then it stops, even though I chose “monitoring points files at each time step”. Any idea how to change that?
If it happens during the calculation, perhaps it is a buffering problem… At the end of your calculation could you check if you have all the iterations recorded in the monitoring probe files (suffix “hst”) in the HIST.XXXXXXX directory in your RESU directory?
Here are some complements on the probe values management 
Probe values are stored in a temporary (binary) file called hist.tmp before being actually written in the different probes_VarName.dat. This behavior is intended to decrease the filesystem I/O activity.
However, you can use the nthsav variable to control when the values are written (see user manual, chap 7.1.3 “Chronological records”, around page 119).
nthsav = 0 (default, 4 times in the calculation)
nthsav = -1 (only at the end of the calculation)
nthsav > 0 (every ‘nthsav’ time-step)
Thanks for the info, seems to be working now. However, when checking the listing file, I saw this:
** FORTRAN WORK ARRAYS MEMORY USED
-------------------------------
191164 INTEGERS NEEDED: MAXIMUM REACHED IN TRIDIM
4576320 REALS NEEDED: MAXIMUM REACHED IN MEMNAV
Where can I correct this? Thanks.
It is an information, not something to be corrected.
If you wish to adjust the memory usage more precisely than the automatic procedure, you have to use the GUI, heading “Memory Management”.
In a follow up to the residuals tracking I am trying to print these at each time step using the DERVAR array. DERVAR(3) - DERVAR(7) is listing the derived residual for u, v, w, k, e / w respectively but DERVAR(2) is not the pressure, although it is close to that in the listing. Is the pressure residual stored in a separate array or is it manipulated in a manner before being outputted to the listing file?
Hello James,
Actually what we call “derive” in Code_Saturne in somewhat complicated… and may be a remaining of development verification.
For all the convected variables (so everything except pressure), the derive stands for the following expression and may be used as a criterion to see the convergence of a steady calculation (though a true residual would perhaps be better).
dervar(ipp) = || [u(n+1) - u(n)] / “time step” ||² / “total volume” with ||.|| being the L2 norm
On the contrary, for the pressure, the derive stands for a ratio between the divergence of “predicted velocity field + Rhie & Chow filter” and the divergence of “predicted velocity field”. So, I strongly advise you to not take into account this number!
dervar(ipp) = || div(rho.u*) + RC ||² / || div(rho.u*) || with ||.|| being the L2 norm and RC the Rhie & Chow filter
As you can see, this is completely different… and quite complex
Hope this helps !
David
ps : to understand the calculation of the derive, you can have a look at the ecrlis.f90 subroutine (“preduv.f90 + resolp.f90” for the pressure)
Hi David,
Just for information, does the “derive” variable for Pressure have a physical meaning?
Thanks
Hi Axel,
I would answer no. This is definitely numerical information that gives the “weighting” of the Rhie & Chow filter. It actually has nothing to do we a so-called “derive”; it’s more something for developers…
David