Mapped Inlet vs Periodic Boundaries

[RobinD]

Dear Code_Saturne community,

I am a new user of Code_Saturne (5.0.8) and I am facing some issues with the mapped inlet.

I am trying to simulate an infinite horizontal channel flow along the x-direction with a "step" in the middle (inlet at the left, outlet at the right) from a .ccm mesh file (see Geometry.png).

I first tried with a mapped-inlet, defined with the GUI.
The problem is that the inlet- and outlet-velocity fields for the y and z components are totally different: I have tried to set the "normalize" parameter inside the cs_user_boundary_conditions-mapped_inlet.f90 subroutine to 0 (still we the GUI definition of the mapped inlet), to just copy the output without any normalization, but then the velocity keeps decreasing.

So, as proposed here by Yvan viewtopic.php?t=2259, I have successfully used periodic boundaries with a source mass term to simulate this infinite channel (I just adapted the subroutine proposed by Yvan), without loosing the y and z components of the velocity. But now, I have troubles with the pressure at the inlet and outlet: the 2 pressure maps visualized with paraview are totally different between the mapped-inlet-case and the periodic-boundaries-case (see the 2 pictures attached for the inlet for instance). It seems that using periodic boundaries for the inlet and outlet change changes totally the pressure profile ?

This case is just a test before using this kind of inlet (periodic or mapped) for other geometries. I will have to calculate the Pressure Lost Coefficient for these other geometries, so the pressure map is crucial for me, and having the same velocity profile at the inlet and outlet is also a requirement...

Is there a way to keep the 3 components of the velocity field and the pressure intact with a mapped-inlet or periodic boundaries?

I hope that I was clear, don't hesitate if you need any other information or clarifications!

Thank you in advance and have a good evening,

Robin

[Yvan Fournier]

Hello,

When you used the mapped inlet, where did you map the inlet from (i.e. which "shift" vector dis you use ?).
If you mapped the inlet from just before the outlet, you may should have a behavior similar to periodicity, execpt it is handled as an explicit boundary condition instead of an implicit condition in the case of periodicity.

Also, a mapped inlet may take some iterations to stabilize.

The "normalize" option should be used for velocity and scalars to keep the desired flow rate, but not used for turbulence variables (k, epsilon, omega, R, ...) which would defeat the purpuse of recycling the inlet. the default options/examples should be good for this.

Best regards,

Yvan

[RobinD]

Dear Yvan,

Thank you for your answer.

I used a shift vector of 1.15 along the x direction to map the inlet just before the outlet as you were suggesting (the domain dimension along this direction is 1.2).

The case has converged but as it can be seen with the pictures attached, the y and z components of the velocity are totally different between the inlet and the outlet (see picture Uz-saturne.png for instance). I know that it is possible to keep these components with a mapped-inlet with OpenFOAM for instance (see the other picture Uz.png attached, but ignore range of the value taken since the inlet velocity is not the same)


You can find attached my mapped inlet subroutine. I have tried to change these lines :

Code: Select all

      if (ivar.eq.iv .or. ivar.eq.iw .or. ivar.eq.iu .or. iscal.gt.0) then
        normalize = 1
      else
        normalize = 0

to

Code: Select all

if (ivar.eq.iu .or. iscal.gt.0) then
        normalize = 1
      else
        normalize = 0

to keep the y and z components of the velocity (as for true periodic boundaries) but it didn't change anything. Is there a way to converse all the components of the velocity ?

I am not sure if I am clear in my explanation ? Please let me know if you need anything else !

You can find the setup.xml file used attached, if needed.

Regards,

Robin

[RobinD]

And here is the picture taken with a mapped inlet using OpenFOAM (I don't know why it wasn't sent with my previous message)

[Yvan Fournier]

Hello,

In cs_user_boundary_conditions.f90, nothing prevents you from setting uz (and possibly uy) to 0 after the mapping, but a cleaner solution would probably be to have a longer outlet, while keeping the mapping at the same distance, to avoid "quasi-recirculation" type effects at the outlet. This kind of breaks the periodicity, but should be better. You may also try other outlet types. Here with a short distance between the bump and outlet, the "free outlet" might not constrain the flow enough...

Otherwise, using a true periodicity (if the dimensions are constrained) may be better.

Best regards,

Yvan

[RobinD]

Dear Yvan,

Thank you for your answer.
I think that I was not clear enough, sorry about that. In fact, I need to study these recirculation effects.

So, ideally, I would like to have a "true" mapped inlet : since there are some recirculations at the outlet, I would like them to be also mapped and "find" them at the inlet.
Said differently, I would like to fix the inlet velocity equal to the outlet velocity after the first iteration, which means using the outlet as a new inlet, without any normalization, at each time step. For instance, the y and z recirculations which appear at the outlet should be seen and re-injected at the inlet, as it is the case on the OpenFOAM picture I posted in my previous message, where the recirculations are also mapped.

In other words, when you say

setting uz (and possibly uy) to 0 after the mapping

, I want to do the exact opposite and keep all the components of the outlet as my new inlet.

I hope that I was clearer?

Concerning the periodic boundaries, I achieved to define a user_source_term and indeed, the recirculation could be seen at the inlet also, which is perfect! But the pressure at the inlet and at the outlet were very strange: when using periodic boundaries, is the pressure given by Code_saturne still physical, or is there a way to rebuild it?

Thank you again for your time,
Best regards,

Robin

[Yvan Fournier]

Hello,

I do not know how OpenFoam's mapped inlet works, so cannot explain the difference (while the two codes often lead to similar results for models present in both).

The pressure using periodicity is only physical as long as you have a source term (which you need to define) ; if you hava a true repeating pattern along a channel, with not other source term, of course the pressure will decrease aong the flow, so velocity could be periodic, but pressure not so. In which case a mapped inlet is more representative of reality, but the choice of outlet condition is important. As Code_Saturne tries to prevent rentrant flows in the outlet, this may lead you to breaking up recirculation patterns which would otherwise occur.

Best regards,

Yvan

[RobinD]

Dear Yvan,

Thank you for these explanations. Which outlet condition would you recommend to keep the recirculation patterns with a mapped inlet?

Thank you again for your help,

Best regards,

Robin

[Yvan Fournier]

Hello,

I am not sure there is an outlet condition adapted to your needs (we try to avoid incoming flow on an outlet, as the flow conditions are then not determined). You might try free/inlet outlet or the other options the GUI provides you. If your computation is not too long, I recommend trying all outlet types which seem to make sense. If one works, good. Otherwise, periodicity + source term would be the way to go.

Regards,

Yvan

[RobinD]

Dear Yvan,

Thank you for your help, I will try that and let you know !

Have a nice day,
Regards,

Robin