Questions regarding the use of Code_Saturne: Fans and Numeri

[Stéphane Blanchet]

Dear support and users,

I have several questions I would like to ask you since I don't find the answers, so it would be nice if you can help me.

Here are my questions:

1) Is it possible to model a fan (by using pressure jump, etc.)?
2) This question is regarding the face warping angle in check_mesh. Indeed, in cs_mesh_quality.c, the face warp is defined as a angle, but when I check my check_mesh file, here is what I get for example:

minimum value =         0.00000e+00
maximum value =         1.42109e-14

It doesn't seem to be angles, but maybe I misunderstood the code.
3) Is there any recommendations regarding the use of the centered or SOLU schemes? For example, in which general cases do one prefer to use centered instead of SOLU (or SOLU instead of centered)?
4) And finally, to satisfy my curiosity: which models of turbulence do you use most often in EDF?

Thank you,

Best Regards

Stephane

[David Monfort]

Dear Stéphane,

Here are some answers (mine ) to your different questions...

1) Yes. But unfortunately this is completely undocumented stuff... apologize! You'll have to look at the cs_ventil.c file in the src/base directory of the kernel package. You'll find there a Fortran API to access some C functions (usually to be called in this order):

- define a fan                         -> defvtl (to be done only once)
- initialize fans                       -> inivtl (to be done only once)
- get the number of fans              -> tstvtl
- compute the source term associated -> tsvvtl

Other functions exists to compute the mass flux -- both inflow and outflow -- accross the fan (debvtl), to know which cells are "in" a fan (numvtl). All of this can be done in the ustsns subroutine for source term management (or maybe also in usiniv for fans definition and initialization). And for non-french speakers, fan is translated in French by ventilateur (thus the vtl suffix of all the subroutine API).

ps: if needed, I might dig up an example somewhere...

2) I checked how we compute the face warping coefficient and it seems to be an angle degree (0 being the best value == no warping). How's your mesh ? If there are only tetrahedra, then the warping is (of course) zero ; if there are hexaedra, then it is indeed kind of strange to have so low value (except for brick elements of course).

3) Not really... Let's say that the SOLU scheme is a second-order upwind scheme, but that is generally worse than upwind regarding the min/max principle. Centred scheme is 2nd order as well and may be worse than the SOLU scheme regarding the min/max principle (i.e. more dispersive) but is generally far better regarding energy conservation (i.e. less diffusive). I don't really have advice here... and usually use centred scheme for velocity and scalars (plus clipping to tackle the potential overshoot) and upwind (1st order) for turbulence.

4) Basically, k-epsilon model for historical reasons and habits (some could say bad habits... I don't want to start a flamewar here ) with its linear-production version for jet-impacting flows, but SSG model is being used more often now; k-omega SST is also used but you want to avoid natural convection as it is usually bad for this kind of flows; LES of course, mainly the standard Smagorinsky model, whenever frequential aspects are needed (depending on mesh constraints, wavelength of interest for the physical aspects, ...). v2-f is currently being improved in a new version, not yet integrated within the official version, so you can consider it as in a "stabilization" stage. LRR and mixing length models are rarely used.

Regards,

David

[Stéphane Blanchet]

Dear David,
Thank you for all those answers, it was really helpful!
Regarding the fan model, I would be really interested by your example, it will maybe clear things up.
As for the mesh, there were only tetrahedra...I totally forgot that the warping angle was computed for hexahedra...
 
Regards,
Stephane

[Alexandre Douce]

Hi,

concerning the point 3) some elements and recommendations:

1) Upwind
- 1st order accuracy
- depending of the flow direction
- robust, very stable, but dissipative
- easiest to converge
- bounded (preserves extrema)

2) SOLU
- 2nd order accuracy
- depends of the flow direction
- low numerical diffusion
- less dissipative than the 1st order but not bounded
- more stable than the Centered scheme
- I recommend this scheme for full tetrahedra meshes, and not too fine meshes

3) Centered
- 2nd order accuracy
- symmetric: does not depend of the flow direction
- not dissipative but dispersive (not bounded)
- less stable than the SOLU
- I recommend this scheme for fine meshes, regular (hexahedral meshes) meshes, LES

It is of course my point of view. Any agreements or disagreements are welcome.

[Stéphane Blanchet]

Hi,
 
Thank you Alexandre for those recommendations!

[Sylvain Boutot]

How to make one " porous jump "? I have a simple geometry (pipe), I defined a border in my mesh, and I would like know, where in C_S they point out to him this border? (boundary condition? it has that inlet / outlet / wall / symm)

Comment réaliser un "porous jump"? J'ai une géométrie simple (tuyau), je défini une frontière interne dans mon maillage, et j'aimerai savoir où est ce que dans C_S on lui indique cette frontière? (boundary condition? ---> il n'y a que inlet/outlet/wall/symm )

Merci

Sylvain

[David Monfort]

Hello Sylvain,

What do you exactly mean by "porous jump"? Could you post a scheme or picture of what you intend to model?

Code_Saturne can handle head-loss zones, defined on a specific volumic zone e.g., but it cannot yet correctly model porosity. I mean here that the code cannot, in its standard version, represents the increase of velocity in the porous zone even if it can reproduce the blocking effect of the porous media.

Best regards,

David

[David Monfort]

By the way, in the future, that would be better for everyone's understanding if you opened a new thread (as it is a new question) instead of using somebody's topic
Just for the sake of clarity ;-)
Thanks!

[David Monfort]

Forgot the attachment... sorry :-/

[Jérémie Tâche]

Hi David,

I'd be grateful that it would be possible to get this fan example.

Thanks a lot.

Regards,

Jeremie

Previously David Monfort wrote:

Dear Stéphane,

Here are some answers (mine ;)) to your different questions...

1) Yes. But unfortunately this is completely undocumented stuff... apologize! You'll have to look at the cs_ventil.c file in the src/base directory of the kernel package. You'll find there a Fortran API to access some C functions (usually to be called in this order):

- define a fan -> defvtl (to be done only once)
- initialize fans -> inivtl (to be done only once)
- get the number of fans -> tstvtl
- compute the source term associated -> tsvvtl

Other functions exists to compute the mass flux -- both inflow and outflow -- accross the fan (debvtl), to know which cells are "in" a fan (numvtl). All of this can be done in the ustsns subroutine for source term management (or maybe also in usiniv for fans definition and initialization). And for non-french speakers, fan is translated in French by ventilateur (thus the vtl suffix of all the subroutine API).

ps: if needed, I might dig up an example somewhere...

2) I checked how we compute the face warping coefficient and it seems to be an angle degree (0 being the best value == no warping). How's your mesh ? If there are only tetrahedra, then the warping is (of course) zero ; if there are hexaedra, then it is indeed kind of strange to have so low value (except for brick elements of course).

3) Not really... Let's say that the SOLU scheme is a second-order upwind scheme, but that is generally worse than upwind regarding the min/max principle. Centred scheme is 2nd order as well and may be worse than the SOLU scheme regarding the min/max principle (i.e. more dispersive) but is generally far better regarding energy conservation (i.e. less diffusive). I don't really have advice here... and usually use centred scheme for velocity and scalars (plus clipping to tackle the potential overshoot) and upwind (1st order) for turbulence.

4) Basically, k-epsilon model for historical reasons and habits (some could say bad habits... I don't want to start a flamewar here ;)) with its linear-production version for jet-impacting flows, but SSG model is being used more often now; k-omega SST is also used but you want to avoid natural convection as it is usually bad for this kind of flows; LES of course, mainly the standard Smagorinsky model, whenever frequential aspects are needed (depending on mesh constraints, wavelength of interest for the physical aspects, ...). v2-f is currently being improved in a new version, not yet integrated within the official version, so you can consider it as in a "stabilization" stage. LRR and mixing length models are rarely used.

Regards,

David