|
[Sponsors] |
October 13, 2010, 05:45 |
mixingPlane
|
#1 |
New Member
Join Date: Jul 2010
Posts: 20
Rep Power: 16 |
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! |
|
April 3, 2012, 13:39 |
Release of the mixingPlane source code for OpenFOAM-1.6-ext
|
#2 |
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
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:
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 |
|
April 15, 2012, 15:48 |
|
#3 |
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
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:
- 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, Martin Beaudoin |
|
April 15, 2012, 18:09 |
|
#4 |
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
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 Last edited by mbeaudoin; April 15, 2012 at 18:12. Reason: minor editing |
|
June 11, 2012, 03:22 |
Mixing Plane for Axial Fan
|
#5 |
Member
Join Date: Oct 2011
Posts: 37
Rep Power: 15 |
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 |
|
June 11, 2012, 04:59 |
|
#6 |
Member
Timo K.
Join Date: Feb 2010
Location: University of Stuttgart
Posts: 66
Rep Power: 16 |
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 |
|
June 11, 2012, 06:20 |
|
#7 |
Member
Join Date: Oct 2011
Posts: 37
Rep Power: 15 |
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 |
|
June 11, 2012, 11:40 |
|
#8 | |
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
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 Quote:
|
||
June 12, 2012, 02:06 |
|
#9 |
Member
Join Date: Oct 2011
Posts: 37
Rep Power: 15 |
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 |
|
June 12, 2012, 12:17 |
|
#10 | |||||
Senior Member
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22 |
Hello Peter,
Quote:
Quote:
Quote:
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. Quote:
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 Quote:
|
||||||
March 2, 2018, 10:47 |
Problems with the simulation of a swirl flow in combination with a mixingPlane
|
#11 |
New Member
Stefan Fraas
Join Date: Mar 2018
Posts: 1
Rep Power: 0 |
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 |
|
Tags |
ggi, interface, mixing plane, rotor stator interface, turbomachinery |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
About mixingPlane GGI in OpenFoam-1.5-dev | Zheng.Zhi | OpenFOAM | 2 | July 3, 2010 19:29 |