code_saturne User's Forum

Hello,

Do you have another error_* file in the execution directory ?

Also, if you have the possibility of running on a debug build (i.e. configured with --enable-debug, leading to a slower but extra-instrumented code), we might get more detailed/earlier error messages.

Best regards,

Yvan

attene
Regarding the error message, it can also be useful to run on single core for testing directing the output to GUI window and to listing (I don't remember what is more reliable). The message may appear in one of combinations.

attene wrote: ↑Tue Oct 16, 2018 11:00 am Hello everybody,

By updating to the version 5.2.1 as Yvan suggested, I did not face this issue anymore. I am trying a frozen rotor with mesh coupling. No turbulence model is used.
The job started to iterate, but it looks very unstable although the the CFL number seems to be within the "stable range" (below 10) when the velocity starts diverging.


What is weird this time is that no error file was written. The only information regarding this error is written in the file attached script_parallel.o2066175.txt
Please find also listing and setup.xml.

Best regards.
FA

Thank you Antech and Yvan for your latest replies!
Regarding my latest reply ( please see it aforementioned); it ended up was an error in the network card on one of the compute nodes.

These last couple of days I run few test on the same model but with an improved mesh (in terms of quality) for the rotor domain ( as you can see from the listing file attached, not a relevant number of elements gave warning ).
The solution though diverged after few time steps; divergence solving for Velocity appeared.

I am using the version 5.2.1 with unsteady frozen rotor and explicit coupling in the Turbomachinery module.
What can I try to do in order to solve this issue? Any other test? Clipping the velocity may be useful?
I would like also to check my meshes with code saturne in mesh mode, How can I do this? (I have not really understood ..).

Please find attached listing, and .xml files.

Regards,

FA

By looking at the ERROR.case I could look into the quantities appearing in the ERROR.png (see attached).
Please find attached the most significant images I post processed from the ERROR.case in paraview.

Diag_dom_velocity and X_vel_2 are significant at the outlet


Regards
FA

and "Diag_Vel_magnitude" at the interface between rotor and rest of the tank.


Regards,

FA

Hello,

The "Diag_Dom" (diagonal dominance) actually makes the easier for the linear solvers to converge, so we usually check it does not become negative anywhere (which could be related to a mesh quality or other problems, so as some implicit source terms destabilizing rather than stabilizing the system, or other numerical issues).

Does the right-hand-side (RHS) already contain very high or irregular values ? This could be the case if divergence appears progressively over several time steps.

Is your mesh still the one you linked to in an earlier post or a newer one ? I may be able to test your case next week.

Regards,

Yvan

Hi Yvan,

Sorry for my late reply, and thank you for your answer.
I was away last week.
I have not seen any particular high or irregular values on RHS.
I will let you have the last two meshes I am using...which are not the ones I sent the links.

Best regards,
FA