Question about mixingPlane boundary condition

[ZorziM]

Dear Professor,
I try to use MixingPlane boundary condition in a 2D model as a interface between stator and rotor.
I put MixingPlane condition for patch at rotor side and zeroGradient for stator as indicated in mixingPlaneFvPatchField.H, however the boundary condition has a wrong behavior because it doesn't seem to transfer information upstream as you can see in the picture.

Am I doing it wrong or is there something else?

Best Regards

[furstj]

Hi,

first of all: the mixingPlane is still highly experimental and there can be still bugs in it :). Can you please send me your setup? At least the system and 0 directory? Is MRF? If so, then send me also constant/MRFProperties.

[ZorziM]

Yes, I can share all settings for rhoSimpleFoam with the modification for energy equation due to high speed rotation in rotor stage.

[furstj]

Hi,

there are two main problems with your setup:

1. Your case is planar cascade. My mixingPlane BC works only for 3D configurations (i.e. case with rotational periodicity). The "origin" and "axis" items correspond to the axis of the machine then.

2. The mixingPlane transfers the quantity from source patch. Typical setup for turbine stage (ie. stator- rotor) should be then

pressure: mixing plane at stator outlet and zero gradient at rotor inlet
temerature, velocity, turbulence quantities: zero gradient at stator outlet and mixing plane at rotor inlet

In this way T, U, k, ... are propagated downstream to rotor whereas p is propagated upstream to stator.

[ZorziM]

Ok, I try to use this BC in a 3D model and I let you know in few days.
About 2D configurations, Do you think it is possible to modify the code to make it compatible with 2D too?

[furstj]

Hi,

Definitely, it should be possible to make a 2D version. The 3D version does averaging in cylindrical coordinates wheres 2D should do simple averaging. Therefore a simple and ugly "hack" will be to erase calls to "toXRTheta" and "fromXRTheta", e.g. instead of

patchField[i] = fromXRTheta(average, r/mag(r));

use

patchField[i] = average;

Note that "order" has to be 0 for 2D configuration and "origin" has to be selected somewhere far from the domain.

[ZorziM]

Hi,
I solved the 2D case with your suggestions. I will check the results in the next few days.
For 3D case at the moment I have a convergence problem in the interface (stator side) with spikes in temperature field. I will try to change setup to improve stability.

Thank you and happy new year

[furstj]

I'm glad to hear about your progress.

[ZorziM]

Hi Professor,
I solved my trouble about the convergence. I compared the results between Frozen Rotor and your MixingPlane ("Order zero") and the results are very good.
Have you never considered the possibility of creating a circumferential average for Velocity fields?

[furstj]

Hi, nice to hear good news. The circumferential average is not easy task. One would have to interpolate data to some structured mesh. That's the reason why I developed the mixing plane interface in different way. I just approximate the distribution of quantities using a polynomial function of given order (using least square method)...

[ZorziM]

Dear Professor,
I'm continuing my work of validation on mixingplane BC but if for Frozen Rotor I don't have convergence problem when I switch to MixingPlane I have big convergence problems in the first iterations. I'm using the same setup in terms of BC inlet-outlet and Schemes-Solvers beetween FrozenRotor and MixingPlane. I use PIMPLE algorithm with a low Courant Number and a ramp for omega in MRF volume. Do you have any suggestions to improve the stability of the MixingPlane solution?

[furstj]

Can you send me the case? I hope that I will have time to look at it...

[ZorziM]

Dear professor, thank you for your time, at the moment I can only share the setup of simulation because the mesh has many elements, so I will try to make a coarse mesh and then share it.
Now if you see something wrong in the setup please let me know.
case.zip

[furstj]

Hi,
the setup seems to me (almost) fine. There is an error in T: s_outlet_1 is there twice. But it should not make problem as OpenFOAM takes (probably) the last definition (i.e. zeroGradient). Did I get it right that you have three domains:

s (stator) -> mixing plane -> r (rotor) -> cyclicAMI -> e (exhaust) ?

[ZorziM]

Hi,
the twice definition on T:s_outlet_1 is a typo. The simulation start correctly (with zeroGradient on T:s_outlet_1) but after 10-20 iterations in one step T diverges. The divergence point is very close to mixingplane in proximity of shroud on rotor side.
Yes, I have 3 domains as you wrote.
I'm preparing the case to share the mesh with you too.

[furstj]

Hi,
sometimes it happens that during the simulation startup there is a backflow through the mixing interface. It makes problems in general. Sometimes it helps to start from non-zero velocity and/or to change the boundary condition for T at the stator side from zeroGradient to inletOutlet.

If the mesh is too large then it will be probably better to send it via google drive, weTransfer or similar service.

[ZorziM]

Hi Professor, I'm very sorry for may delay but I have had some personal problems in this period.
Anyway I tried with inletOutlet for T but the problem remained the same but I tried putting inletOutlet for pressure instead of zeroGradient, I know it is wrong because with this condition I set an inletValue to BC but in this case the simulation goes on for many iterations (then it crashes but due to incompatibility with inlet-outlet and MRF BC). So I think that the problem is focused on p. I already tried to use outletInlet for p but the instability is the same as zeroGradient.

I'm still working on mesh to share a case with you.

Best regards