# non-uniform geometry between cyclic boundary

 Register Blogs Members List Search Today's Posts Mark Forums Read

June 25, 2018, 10:17
non-uniform geometry between cyclic boundary
#1
New Member

Georg
Join Date: Jun 2018
Posts: 7
Rep Power: 7
I want to simulate an infinite serpentine channel with laminar flow only.
The aim is a periodic inlet/outlet and the flow driven by a constant pressure gradient. The basic setup can also be seen in the pictures attached (serpentine_massflow.png).

For basic channel flows, the case is solved by applying a constant momentum source (as pressure gradient) to the momentum equation which holds for the whole fluid domain. The U and p inlet/outlet are set to cyclic, respectivley.

However, when facing a more complex geometry, the pressure gradient is not uniform in streamwise direction and only known at the boundaries (in the form of Reynolds number and hence, mass flux, pressure gradient, all equivalent).

I have found the suggestion of applying the "fan BC" for the cyclic pressure boundaries here (Periodic B.C or Inlet/Outlet B.C), which sould define the pressure gradient at a cyclic boundary. However, with

type fan;
patchType cyclic;
f List<scalar> 1(6e-05); // p_OF = p_real / rho
value uniform 0;

for the pressure inlet/outlet, the result is not desirable.

Am i using the right boundary conditions for the setup?
I appreciate any thoughts on this problem.

Greetings, G.

Picture 1: "serpentine_cyclic.png" using U and p as cyclic without any flow driving source.
Picture 2: "serpentine_fan.png" using U as cyclic and p as fan at the boundary.
Picture 3: "serpentine_massflow.png" using U inlet as constant mass flow at inlet and zeroGradient at outlet. The pressure es set to zeroGradient at inlet and a fixedValue at outlet. This case is just for the general vizualisation of the setup.
Attached Images
 serpentine_cyclic.jpg (53.3 KB, 24 views) serpentine_massflow.jpg (44.0 KB, 27 views) serpentine_fan.jpg (46.4 KB, 22 views)

June 28, 2018, 06:52
#2
New Member

Georg
Join Date: Jun 2018
Posts: 7
Rep Power: 7
I have finally broken down the case to a very simple one of one fourth of a circle. So, the the flow is driven by an artificial pressure gradient, introduced with the fan boundary condition.
Anyhow, the result is oscillating at the inlet/outlet. The case is available here https://ufile.io/fak0j, maybe someone has ideas on the stability of this case. The attached pictures show, mesh, pressure and velocity, where
the oscillations are at the inlet/outlet of those fields.

Summary of the case: 2-D, laminar, steady-state (just run simpleFoam), cyclic inlet/outlet where the flow is driven by the pressure gradient defined as "fan" bc at the inlet. OpfenFOAM version 5.x and 4.0 tried out.

I use stable schemes and solver setting (as far as i know), and played around with the relaxation factors wich ended up in relax_p=0.7 and relax_U=0.1. This seems to be kind of weird, but standard values of 0.3, 0.7, respectivley caused early divergence by enhancing the oscillations. Moreover, finer meshes exhebit the same behaviour (wheter streamwise or normal refinement).
Attached Images
 Arc_mesh.jpg (132.8 KB, 20 views) Arc_p.png (46.1 KB, 18 views) Arc_U.png (40.6 KB, 20 views)

 June 28, 2018, 09:50 #3 Senior Member   Robert Join Date: May 2015 Location: Bremen, GER Posts: 292 Rep Power: 11 Hello Georg, you wrote in your first post that for basic cases you would apply a constant momentum source to the whole domain. For you more complex cases have you tried using the same source and applying it only to a cell set at the cyclic inlet of your domain? Constantly forcing the inflow to a certain threshold without influencing all cells of your domain. Technically it should work with e.g. the meanVelocityForce or the vectorExplicitSetValue. /edit: From this souce it seems like the fvOptions sources accept a mapRegion. Maybe you could even use a steady profile at your inlet without compromising your cyclic BCs.

July 4, 2018, 06:46
#4
New Member

Georg
Join Date: Jun 2018
Posts: 7
Rep Power: 7
The case seems to be kind of solved, but i am still not sure wheather this setup is valid to hold proper validation.

Thank you Robert for your interest in this one.

For the final case i have applied usual cyclic bcs at the inlet/outlet and used the meanVelocityForce momentum source in fvOptions with

Code:
```momentumSource
{
type            meanVelocityForce;
active          yes;

meanVelocityForceCoeffs
{
selectionMode   cellSet;
fieldNames      (U);
fields        (U);
Ubar            (0.056 0 0);
relaxation      0.8;
}```
where the cellSet SetgradP is one channel hight into the domain from inle/outlet respectivley (see attached picture). In this region, the driving pressure gradient should theoretically be uniform. Prior to this, i have tried SetgradP as the firtst internal field cells right next to the inlet boundary. This resulted into oscillations in the U-field and, same goes for SetgradP as the first internal field cells next to the inlet AND outlet. Intuitvley i have decied for a wider region which ended up in the approach above.

Somehow, this approach does work. But i still think a definition of the pressure gradient at the boundaries ONLY should be me appropriate as intended by the fan bc, since i think the former approach is way too restrictive by constraining certain gradients within the domain.
Attached Images
 cyclic_with_setSet.jpg (43.0 KB, 22 views)

 July 8, 2018, 04:32 #5 New Member   Georg Join Date: Jun 2018 Posts: 7 Rep Power: 7 Still struggeling with the fan bc. The problem seems to be kind of OF5.X related, since the implementation of this particular bc is unusual. I have found a very good reference page http://translate.google.com/translat...00201,15700208. This case is prepared for OF2.1, using fan bc and works fine for me aswell. Here, the cyclic fan patches are both defined with Code: ``` type fan; patchType cyclic; f (- 87.622); value uniform 0;``` When using OF5.X, the bc of the outlet is automatically switched to the normal cyclic bc and the flow is not driven by the pressure anymore, hence no solution. So i assume the issue is with the implementation of this bc in OF5.X.