problems with mixing plane
 

Hi, I am using foam-extend-3.0 to run steady and unsteady simulation of axial compressor stage. The calculations with domain scale and frozen rotor run well. But when I change the rotor-stator interface to mixing plane for a steady calculation, fatal error reports as follows,


Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh staticFvMesh
Initializing the GGI interpolator between master/shadow patches: passageSidesUpper_0/passageSidesLower_0
Initializing the GGI interpolator between master/shadow patches: passageSidesUpper_1/passageSidesLower_1
Initializing the mixingPlane interpolator between master/shadow patches: outlet_0/inlet_1
Reading thermophysical properties

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>
Allocating field rho

Reading field U

Reading/calculating face flux field phi

Creating MRF model

Creating turbulence model

Selecting turbulence model type RASModel
Selecting RAS turbulence model kOmegaSST
kOmegaSSTCoeffs
{
Prt 0.9;
alphaK1 0.85034;
alphaK2 1;
alphaOmega1 0.5;
alphaOmega2 0.85616;
gamma1 0.5532;
gamma2 0.4403;
beta1 0.075;
beta2 0.0828;
betaStar 0.09;
a1 0.31;
c1 10;
}

Create Riemann solver

Allocating field rhoU

Allocating field rhoE

Allocating physDeltaT list for RK and Dual-Time Stepping


Starting time loop


Time = 1



--> FOAM FATAL ERROR:
Unknown mixing type for patch outlet_0 for field (Cp|Cv)

From function tmp<Field<Type> > mixingPlaneFvPatchField<Type>::patchNeighbourField () const
in file fields/fvPatchFields/constraint/mixingPlane/mixingPlaneFvPatchField.C at line 429.

FOAM aborting

Aborted

I don`t know the reason, the following is the setup of mixing plane in costant/polyMesh/boundary file.
=======================
outlet_0
{
type mixingPlane;
nFaces 320;
startFace 119712;
shadowPatch inlet_1;
zone outlet_0_faces;
coordinateSystem
{
type cylindrical;
name mixingCS;
origin (0 0 0);
e1 (1 0 0);
e3 (0 0 1);
}
ribbonPatch
{
discretisation bothPatches;
sweepAxis Theta;
stackAxis R;
}
}

inlet_1
{
type mixingPlane;
nFaces 300;
startFace 126368;
shadowPatch outlet_0;
zone inlet_1_faces;
coordinateSystem
{
type cylindrical;
name mixingCS;
origin (0 0 0);
e1 (1 0 0);
e3 (0 0 1);
}
ribbonPatch
{
discretisation bothPatches;
sweepAxis Theta;
stackAxis R;
}
}
==================================

Same issue...
 

Hi dowlee,

I am facing the exact same issue. Have you figured it out?
I've tried a couple of things but no improvement yet.

Regards,
Javier

Sorry, I have tried a lot, but still didn`t sovle this problem.

Temporary solution
 

Hi dowlee

It seems like not every volume field from objectRegistry is been read properly.

When using turbulence models, a mixing type ‘unknown’ is assigned to the field ‘(Cp|Cv)’ and when setting the RASproperties to laminar the same happens to the field ‘TKE’.

From the mixingPlane source files (MixingPlaneInterpolationName.C) one can see that the types of mixing are listed as follows:
>::names[] =
{
"areaAveraging",
"fluxAveraging",
"uniformValue",
"uniformGradient",
"zeroGradient",
"unknown"
};

Where "areaAveraging" corresponds to the scalar 0, "fluxAveraging" to 1, and so on.

In the source code (mixingPlaneFvPatchField.C) the variable ‘mixing_’ is compared this scalar (from 0 to 5 as showed in previous list). For some reason the fields from transonic*Foam solvers have a 5 assigned (type "unknown") which leads us to the problem we are having.


In order to avoid this problem I have done a quick fix.

I am basically going to bypass the mixingPlane type defined in fvSchemes and assign it directly in the source code. The type of mixingPlane (areaAveragin, fluxAveraging or zeroGradient) will be the same for every field.

This is what you need to do:
In fvSchemes set the following parameters:

mixingPlane
{
default areaAveraging; //Or fluxAveraging or zeroGradient
}

Open the mixingPlane source file with: gedit $HOME/foam/foam-extend-3.0/src/finiteVolume/fvPatchFields/constraint/mixingPlane/mixingPlaneFvPatchField.C

At about line 384 you will find the following code:

template<class Type>
tmp<Field<Type> > mixingPlaneFvPatchField<Type>::patchNeighbourField () const
{
// Get shadow patch internalField field
Field<Type> sField = this->shadowPatchField().patchInternalField();

//--------------------- Add the following line ---------------------------------
//Add line to assign the type of mixingPlane and bypass fvSchemes
mixing_=mixingPlaneInterpolation::AREA_AVERAGING;

if (mixing_ == mixingPlaneInterpolation::AREA_AVERAGING)
{
// Area-weighted averaging
return mixingPlanePatch_.interpolate(sField);
}
else if (mixing_ == mixingPlaneInterpolation::FLUX_AVERAGING)


Add the line in bold letters. You can use on of the three options:
for areaAveraging: mixing_=mixingPlaneInterpolation::AREA_AVERAGING;
for fluxAveraging: mixing_=mixingPlaneInterpolation::FLUX_AVERAGING;
for zeroGradient: mixing_=mixingPlaneInterpolation::ZERO_GRADIENT;


Now recomiple the finiteVolume library
cd $HOME/foam/foam-extend-3.0/src/
wmake libso finiteVolume


You are all set!!
Remember that with this setting you will only use the type of mixingPlane defined in the mixingPlaneFvPatchField.C file

Let me know how it works for you. I have not compared the results with other methods.

Regards,
Javier

Please don't do that. This is probably one of the worst suggestion I have ever seen on this Forum.

If you do this source code modification, I can assure you with certainty, as the main author of the mixingPlane source code, that you are introducing in your code a bug even worse than the one you are chasing. Then you will be breaking your code for sure.

Then you will come back on the Forum asking for some additional help, but based on your own flawed source code modifications. You might even report your problem on the bug tracking system where people will go on a wild goose chase trying to fix a probably existing problem, but compounded by bad information or bad logic coming from your own flawed source code modification.

If you cannot find the source of your problem yourself, then I strongly advise you to report your initial problem on the foam-extend bug tracking system https://sourceforge.net/apps/mantisbt/openfoam-extend, and to supply a small test case triggering the bug.

There are knowledgeable people there that can certainly help you, but usually on their own free time, which can be scarce at time...

Martin

Hi all,

I'm currently use foam-extended 3.0 with density based solver to solve some turbine simulations.
And I'm faced with exactly the same problems.

May I ask if you guys have already fixed the problems or not?
Could you please offer me some thread about that?

Thanks!
Janry