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!
Release of the mixingPlane source code for OpenFOAM-1.6-ext
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:
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:
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.
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 :
In the meantime, here is a quick overview:
Tutorials for laplacianFoam:
- Very simple tutorials to illustrate the basic syntax for a mixingPlane interface defined in cartesian coordinates
- Illustrates the basic syntax for a mixingPlane defined in cylindrical coordinates, this time using the ERCOFTAC conical diffuser, Case 1.1Tutorials for icoFoam:
- Very simple tutorials to illustrate the utilisation of the 'orientation' parameter, which defines the basic geometry for the mixingPlane interpolation ribbonsTutorials for simpleFoam:
- 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
- Slightly more complex tutorials using the ERCOFTAC conical diffuser test case Case1.1.Regards,
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:
Mixing Plane for Axial Fan
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:
Thanks in advance
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.
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.
> 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,
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?
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.
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.
|All times are GMT -4. The time now is 14:00.|