code_saturne User's Forum

Dear Code_Saturne team!

Currently I continue the project on which Mr. Sebastian Rible was working in Prof. Behbahani's lab: a CFD benchmark study released by the Food and Drug Administration USA that is related to a simplified centrifugal blood pump.
The purpose of this project is to determine how computational fluid dynamics can be effectively used to characterize fluid flow and to predict blood damage in medical devices. This pump consists out of two parts, one rotor and one housing. In addition was created a boundary cylinder which surrounds the rotor.
The groups of the stator are inlet, outlet, fixed wall and boundary. The groups of the rotor are wall (the rotor itself, also fixed) and boundary. (More detailed see here: http://code-saturne.org/forum/viewtopic.php?f=2&t=1421)

I am new in CFD and having a problem with running LES (Smagorinsky) model computation.

version of Code_Saturne: 3.2.0
compile.log, listing, error files, xml and also addr2line error log are in the attachment.

The computation starts running, however abolishes at the second time step. It also gives a warning:

CHOICE OF TIME-SCHEME
@
@ TIME-SCHEME FOR VELOCITY IS SECOND ORDER
@ (THETAV = 0.50E+00)
@ CERTAIN TERMS ARE HOWEVER FIRST ORDER IN TIME

By using cs_user_parameters.f90 script we managed to change the parameters to be first-order, however the error is still present.

The problem seems to come from:

6: 0x13dca50:
cs_halo_sync_var
/homec/hac28/hac280/SATURNE_3.2.2/SATURNE_3.2.2/saturne-3.2.2/src/base/cs_halo.c:1100

7: 0x121c1d4:
00000012.long_branch_r2off.__libc_start_main+0
/homec/hac28/hac280/SATURNE_3.2.2/SATURNE_3.2.2/saturne-3.2.2/src/mesh/cs_mesh.c:3196

This is probably due to a poor mesh gluing.
However, this mesh was successfully used for RANS computations and we had a nice results.

Could you please suggest what the problem could be?
Please let me know if you need any additional info.

Thank you very much!

Best Regards,
Valeria Marinova

Hello,

The crash is not surprising, as the turbomachinery rotor/stator model is currently enabled only for the first-order time scheme, while LES usually requires a second-order scheme, so the 2 have not been tested together. Colleagues working on this model should be working on the subject in the near future (though I do not have details).

The cleanest solution will probably be to enable a 2nd order scheme for turbomachinery, though near the joining interface, it is expected that the spatial discretization will only be 1st order (at least not quite 2nd order), which may also have an impact (mesh joining usually has an impact on LES).
The amount of work required is probably not huge, so your feedback may help us make progress.

Did you use a transient or frozen-rotor model ? It may be interesting to first try a frozen-rotor model, and see if degrading LES to a 1st-order time scheme leads to the same crash (in which case it is not due to joining, but to LES not being planned/tested with a 1st-order scheme).

For turbomachinery with LES, using the double implicit Euler 2nd-order scheme is probably simpler than using the classical 2nd-order scheme. There might be a few adjustments to make, but this is probably the simplest route.

Best regards,

Yvan