[bb_]

Hi!
First of all, many thanks to this great community and to everybody who contributes to it - it has been proved to be a valuable resource for my past work and probably to everybody who did his/her first steps into the world of OpenFOAM.

I mainly dealt with turbomachinery problems so far. Simulating a rotor or stator independently works fine now. However, it is essential to couple the two. I did some searching and found that there are by now mainly two approaches to do that with OpenFOAM: frozen rotor with MRF or unsteady simulations with sliding meshes.
A third approach, which is by my knowledge the most common in turbomachinery applications, is to use a mixing plane as rotor-stator-interface.

If I'm correctly informed, the GGI group is currently working an a mixingPlane solution but hasn't released it yet. I kindly wanted to ask about the status of this development? Is is likely that it gets released in the near future, maybe at the upcoming conference in Munich in November?

Thanks for any hints!

[mbeaudoin]

Hello,

We would like to announce that we have published the Release Candidate 1 version of the source code for a mixingPlane interface for OpenFOAM-1.6-ext.

The source code is available on the OpenFOAM-1.6-ext git repository on openfoam-extend, under the branch name mixingPlane_RC1.

This is a Release Candidate version, meaning that this is still work in progress, source code and documentation.
For example, this code is yet not synchronized with the latest available version of OpenFOAM-1.6-ext, but rather based on an earlier version from June 2011.
Improvements from the git master branch will be merged as soon as possible.

The documentation about this development will be available here:
http://openfoamwiki.net/index.php/Si...enFOAM-1.6-ext

In the coming days and weeks, test cases, documentation and improvements to the source code will be published as well, so watch that space.

By publishing this code, we also hope to get some feedback from the OpenFOAM Turbomachinery community in order to make this interface better.

An overview of this development can be found here:

• OpenFOAM TURBO TOOLS: FROM GENERAL PURPOSE CFD TO TURBOMACHINERY SIMULATIONS H. Jasak, M. Beaudoin, Proceedings of ASME-JSME-KSME Joint Fluids Engineering Conference 2011, AJK2011-FED, July 24-29, 2011, Hamamatsu, Shizuoka, JAPAN

• Steady-state capabilities for hydroturbines with OpenFOAM, M. Page, M. Beaudoin, A.-M. Giroux, Internationnal Journal of Fluid Machinery and Systems, 4(1):160–170, Jan-Mar 2011.

• Development of a General Grid Interface for Turbomachinery simulations with OpenFOAM, M. Beaudoin, H. Jasak, Open Source CFD International Conference, December 2008

I would like to take the opportunity to thank Dr. Hrvoje Jasak for his help and contributions to this development.
I would also like to acknowledge the useful comments from many colleagues in the OpenFOAM Turbomachinery Special Interest Group.

This development is not approved or endorsed by Silicon Graphics International Corp. or the OpenFOAM® Foundation, the producer of the OpenFOAM® software and owner of the OpenFOAM® trade mark.

Martin Beaudoin
Hydro-Quebec

[mbeaudoin]

Hello,

I have just uploaded some tutorials on the openfoam-extend git repository, under the branch mixingPlane_RC1, in order to illustrate a few basic concepts for the mixingPlane interface.

Those will be documented in more details on the OpenFOAM Wiki :
http://openfoamwiki.net/index.php/Si...enFOAM-1.6-ext

In the meantime, here is a quick overview:

Tutorials for laplacianFoam:

• tutorials/basic/laplacianFoam/twoBlocksMixingPlane
• tutorials/basic/laplacianFoam/twoBlocksMixingPlaneMismatch

- Very simple tutorials to illustrate the basic syntax for a mixingPlane interface defined in cartesian coordinates

• tutorials/basic/laplacianFoam/Case1.1_mixingPlane_sector_AB_60deg

- Illustrates the basic syntax for a mixingPlane defined in cylindrical coordinates, this time using the ERCOFTAC conical diffuser, Case 1.1

Tutorials for icoFoam:

• tutorials/incompressible/icoFoam/mixingPlane/twoBlocksMixingPlaneMismatch_dirY_spanZ
• tutorials/incompressible/icoFoam/mixingPlane/twoBlocksMixingPlane_dirY_spanZ
• tutorials/incompressible/icoFoam/mixingPlane/twoBlocksMixingPlane_dirZ_spanY

- Very simple tutorials to illustrate the utilisation of the 'orientation' parameter, which defines the basic geometry for the mixingPlane interpolation ribbons

Tutorials for simpleFoam:

• tutorials/incompressible/simpleFoam/mixingPlaneAxial

- A very simple tutorial to illustrate the syntax for a mixingPlane interface defined in cylindrical coordinates, and where the stacking of the mixingPlane interpolation ribbons is in the "axial" direction

• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1
• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1_GGI
• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1_GGI_sector_90deg
• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1_mixingPlane
• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1_mixingPlane_Upstream13_Downstream8
• tutorials/incompressible/simpleFoam/ERCOFTAC_ConicalDiffuser/Case1.1_mixingPlane_sector_AB_60deg

- Slightly more complex tutorials using the ERCOFTAC conical diffuser test case Case1.1.
- Those test cases illustrate the syntax for a mixingPlane interface defined in cylindrical coordinates, and where the stacking of the mixingPlane interpolation ribbons is in the "radial" direction
- Two additional tutorials are also included to illustrate the basic usage of the GGI and cyclicGGI interfaces for the same geometry.
- The base case Case1.1 is also provided as a reference case.
- As for the original Case1.1 test case, the postProcessing of the GGI and mixingPlane test cases will compare their results with some measurements.
- Furthermore, the postprocessing results for the GGI and mixingPlane test cases will also be compared with the results from the base case Case1.1
- The "addSwirlAndRotation" utility from the Turbomachinery group is also provided
- More information about the ERCOFTAC conical diffuser test case 'Case1.1' can be found here: http://openfoamwiki.net/index.php/Si..._a_radial_mesh

Regards,

Martin Beaudoin

[mbeaudoin]

Hello,

The information on how to download, update and compile the source code for the mixingPlane_RC1 version of OpenFOAM-1.6-ext is available here:

http://openfoamwiki.net/index.php/Si..._and_Compiling


Martin Beaudoin

[Peter Müller]

Hello together
I'm trying to set up the Mixing Plane for an Axial Fan which originally was Fluent's Tutorial Case "Using the Mixing Plane Model". The faces of the Mixing Plane therefore point in the direction of the Z-Axis (as for the canonical diffusor).
Actually I have some difficulties to run the case.
1. I always get the information that "rescaleWeightingFactors" found uncovered faces and I do not know whether this is a problem or not.
2. I use MRFSimpleFoam to run the case but it always results in a floating point error after solving for the velocity components. Honestly here I'm not shure whether I set up the boundaries correctly for the Mixing Plane, especially the meanings of the "ribbon patch" settings.
Would it be:
ribbonPatch
{
sweepAxis Theta;
stackAxis R;
discretization bothPatches;
}
?
Thanks in advance
Peter Müller

[timo_IHS]

Hallo Peter,

without knowing the current setup of the mp (I could not test it yet),
you should be sure, that the interface matches in axial and radial direction.

Cheers

[Peter Müller]

Hi Timo

Thank you for your quick reply but I'm pretty shure that this is not the problem and that the two boundaries for the Mixing Plane match pretty good radially and axially.

Cheers too

[mbeaudoin]

Hello,

> 1. I always get the information that "rescaleWeightingFactors" found uncovered faces and I do not know whether this is a problem or not.

Yes, this is a problem. It means that at least one of the mixingPlane patches is not fully covered by the intermediary ribbon patch.

For the mixingPlane, we are building a GGI "sandwich" by introducing this intermediary ribbon patch in between the two mixingPlane patches. The mixingPlane thus becomes a set of two GGIs linked together by the common ribbon patch.

This is why you get familiar GGI error messages related to non-overlap GGI faces. And you currently cannot activate the GGI "non-overlap" feature for this.

So, similarly to the GGI interface, if you are in a situation where GGI non overlap faces are detected for either mixingPlane patches, you will get the floating point error situation you are describing.

We've encounter that situation last year with one of our beta tester; the correction to the problem was found, but is not published yet because not fully tested.

If you are using a test case that you could share, I would like to get a copy so I can double check the correction.

Otherwise, you could also try to play with the 'discretization' parameter by using 'masterPatch' or 'slavePatch'. When using those values, the intermediary ribbon patch discretization will stick to the discretization of either the master or slave mixingPlane patches; this might circumvent the problem.

Hope this helps,

Martin

Originally Posted by Peter Müller

Hello together
I'm trying to set up the Mixing Plane for an Axial Fan which originally was Fluent's Tutorial Case "Using the Mixing Plane Model". The faces of the Mixing Plane therefore point in the direction of the Z-Axis (as for the canonical diffusor).
Actually I have some difficulties to run the case.
1. I always get the information that "rescaleWeightingFactors" found uncovered faces and I do not know whether this is a problem or not.
2. I use MRFSimpleFoam to run the case but it always results in a floating point error after solving for the velocity components. Honestly here I'm not shure whether I set up the boundaries correctly for the Mixing Plane, especially the meanings of the "ribbon patch" settings.
Would it be:
ribbonPatch
{
sweepAxis Theta;
stackAxis R;
discretization bothPatches;
}
?
Thanks in advance
Peter Müller

[Peter Müller]

Hello Martin

Thank you for your reply and the explanations. I could send you the case, what do you need? Zero, constant and system directory? To explain a little bit further, the reason why I run into these problems is that I'm currently working on a GAMG-Interface for the Mixing Plane to make it usable with GAMG-solvers.
Can you tell me whether there are some additional releases in the near future about the Mixing Plane or a GAMG-Interface or whether it would be possible to receive some beta codes of the Mixing Plane or an eventual GAMG-Interface?

Many thanks
Peter

[mbeaudoin]

Hello Peter,

I could send you the case, what do you need? Zero, constant and system directory?

Zero, constant and system directory should be enough. I just need to quickly visualize the mesh, and run a few iterations with something like laplacianFoam or simpleFoam so I can verify our correction to the source code.

To explain a little bit further, the reason why I run into these problems is that I'm currently working on a GAMG-Interface for the Mixing Plane to make it usable with GAMG-solvers.

Great! That would be a very nice contribution if you ever decide to share this.

Can you tell me whether there are some additional releases in the near future about the Mixing Plane or a GAMG-Interface

We plan to keep on improving this interface because it is still not conservative enough for our applications. So yes, there will be additional release or improvements in the near future for the mixingPlane, based on our progress.

As for the GAMG interface, we are not working on this aspect of the code right now at IREQ, but you might want to contact Hrv Jasak about this.

We are certainly welcoming any additional collaborations and contributions to the mixingPlane. If you want to help us improve and/or test this code, just contact me through Email, we will find a way to work together.

or whether it would be possible to receive some beta codes of the Mixing Plane or an eventual GAMG-Interface?

We've decided to publish the source code of the mixingPlane because we thought it was good enough to stimulate collaborations and discussions about this kind of interface.

We don't plan to work on new beta versions of the mixingPlane, but we might create other git branches to explore variants from the base design, new ideas and concepts.

We think that we can build on the current version. And from the git logs from the past months, you can certainly see that the published version is our current day-to-day version too.

Regards,

Martin

Originally Posted by Peter Müller

Hello Martin

Thank you for your reply and the explanations. I could send you the case, what do you need? Zero, constant and system directory? To explain a little bit further, the reason why I run into these problems is that I'm currently working on a GAMG-Interface for the Mixing Plane to make it usable with GAMG-solvers.
Can you tell me whether there are some additional releases in the near future about the Mixing Plane or a GAMG-Interface or whether it would be possible to receive some beta codes of the Mixing Plane or an eventual GAMG-Interface?

Many thanks
Peter

[Stefan Fraas]

Hello,

I found a serious problem simulating a swirl flow in combination with a mixingPlane in foam-extend-3.1. Downstream of the mixingPlane, there is no tangential velocity present anymore. I build a simple test case of a pipe flow to proof this issue. The test case is based on the experiments by Steenbergen (http://cfd.mace.manchester.ac.uk/cgi...as72_rsol.html). The type of swirl is “wall jet” and the Reynolds number is chosen as 300,000. The velocity profile correspondent to the experimental results is mapped on the inlet of the pipe with the profile1DfixedValue function in foam-extend-3.1 and the simulations are solved with the simpleFoam solver. In the middle of the pipe I defined two mixingPlanes. The setup of the mixingPlanes in the boundary file is as follows:

coordinateSystem
{
type cylindrical;
name mixingCS;
origin (0 0 0);
e1 (1 0 0);
e3 (0 0 1);
inDegrees true;
}
ribbonPatch
{
sweepAxis Theta;
stackAxis R;
discretisation bothPatches;
}

The discretisation scheme of the mixingPlanes is set as default areaAveraging. The results of the pipe flow with the two mixingPlanes in the middle of the pipe compared to the results without a mixingPlane are showed in the pictures "Ux_reference", "Ux_mixingPlane" and "Ux_mixingPlane_detail". Downstream of the first mixingPlane, there is no tangential velocity present anymore. This problem occurs after the first cell downstream of the first mixingPlane in flow direction.

Changing the discretisation scheme for the mixingPlanes doesn’t solve the problem. I tried the following further discretisation schemes for the mixingPlanes:

{
default fluxAveraging;
}

{
default fluxAveraging;
k areaAveraging;
epsilon areaAveraging;
p zeroGradient;
}

{
default areaAveraging;
k fluxAveraging;
epsilon fluxAveraging;

}

Another problem occurs in a simulation of the pipe flow with just a 90° part of the pipe in the area between the two mixingPlanes in combination with a cyclicGGI boundary condition. This setup results in a pressure oscillation downstream of the second mixingPlane in flow direction. This is shown in the picture "p_90_mixingPlane_detail".

Furthermore, a simulation of the pipe with the two mixingPlanes is leading to a different pressure distribution downstream of the mixingPlanes. The difference in the area averaged pressure at the inlet of the pipe is around 2 % compared to a simulation of the pipe flow without a mixingPlane.

The mixingPlane is also not mass conservative. I found a difference between the volume flow at the inlet and the outlet of 1,3 %.

If anyone is interested in simulating the case I can share the case setup. Thanks in advance.

Stefan Fraas