|
[Sponsors] |
October 21, 2013, 04:30 |
SimpleFOAM and MRFZones drive me crazy
|
#1 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Dear all,
I am trying to use the new implementation of MRFSimpleFOAM in OF 2.2.1, i.e. running simpleFOAM with the fvOptions. The case is a simple blade of a wind turbine with an inlet, an outlet, periodic boundary conditions (since I simulate only one of the 3 blades of the WT) and a farfield. I wanted to make the whole domain rotating which is apparently working fine. However, there is no way to make some inflow coming into the domain via the inlet. This is driving me crazy!! I tried different things at the inlet: fixedValue, surfaceNormalFixedValue and none of them are working. The initial step is showing me a correct Ux velocity of 6m/s at the inlet. But then after a number of iteration, I don't have any speed any more. Could someone point me the error I'm doing? |
|
October 22, 2013, 02:15 |
|
#2 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
no one?
I will add some input. I tried to simplify the case in order to figure out where the problem could be coming from. I am currently simulating a full cylinder with inlet, outlet and farfield(outer cylinder). The whole cylinder domain is rotating around Y axis and here is the fvOptions I use: Code:
MRF1 { type MRFSource; active true; selectionMode cellZone; cellZone rotor; nonRotatingPatches (Inlet Outlet MaxR); MRFSourceCoeffs { origin (0 0 0); axis (0 1 0); omega 1.047197551; } } Now if I activate the MRFzones, the results are getting wired, at least for me. The Uy velocity tends to be 0, and Ux Uz have strange values in the center of the domain. See pictures attached. Then finally, if I remove the line of nonRotatingPatches I get the same result as with no MRF (see pictures attached). If someone could explain why I get those results, it would be really appreciated. |
|
October 22, 2013, 02:28 |
|
#3 |
Member
Join Date: Apr 2013
Posts: 32
Rep Power: 13 |
Do you have multiple cell zones? It looks like you have only one, which is not the way multiple reference frames should be used.
Best regards |
|
October 22, 2013, 02:32 |
|
#4 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Yes indeed I have only one cellZone containing the whole domain.
But I don't see why it would be a problem. I agree that MRF can do more, but that's the least it should be able to handle, isn't it? I may have multiple zone in the future, but I wanted to start simple since simple is already not working |
|
October 22, 2013, 02:36 |
|
#5 |
Member
Join Date: Apr 2013
Posts: 32
Rep Power: 13 |
I agree, I don't see a clear reason why it wouldn't be possible to use only one cell zone and have inlet etc as non rotating patches as you have done. However it is not common practice and as your simulation is acting strange I would try using multiple cell zones and see if it helps.
|
|
October 31, 2013, 07:52 |
|
#6 |
New Member
Ivan
Join Date: Sep 2013
Location: Czech Republic
Posts: 2
Rep Power: 0 |
Hi Vinz,
did you find a solution of your problem ? I have the same. I want to simulate the fan blade with ... Maybe I will use SRFSimpleFoam. But I want to try to use the MRF. Ivan |
|
October 31, 2013, 09:23 |
|
#7 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Hi Ivan
No, not yet... I got a case working withouth any object inside my domain but as soon as I add something like a blade, it does not work anymore. The wired thing is that, even if I put a fixedValue of 6m/s at the inlet, during the simulation the inlet does not have this value which then, of course, gives me wrong results. |
|
November 5, 2013, 02:32 |
|
#9 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
The case is now running if I select only the region around my object to be in MRFzone.
But actually, it is running fine in serial but from time to time it crashes in parallel! I noticed that it is apparently depending on how the case was decomposed. Are there some restrictions with MRF and / or cyclic patches regarding the decomposition to avoid problems while running in parallel? |
|
December 11, 2013, 05:05 |
|
#10 | |
Member
Julian Langowski
Join Date: May 2011
Location: Bremen, Germany
Posts: 91
Rep Power: 15 |
Dear vinz,
Quote:
1.) Decomposition in a way, that the cyclic patches remain as a whole in one processor 2.) use of the option preservePatches in the decomposeParDict Anyway, I also currently am working on a HAWT rotor blade 120° wedge with cyclic BCs and MRF approach in OpenFOAM. Would you mind telling me, how you created your mesh? I am having the problem of being quite restricted with snappyHexMesh, as it isn`t allowd to alter the cyclic patches. And, how did you define the MRF cells? I just have found the topoSet function, which might be a solution for me. How did you do it? Best regards Julian |
||
December 13, 2013, 02:57 |
|
#11 |
Senior Member
Onno
Join Date: Jan 2012
Location: Germany
Posts: 120
Rep Power: 15 |
snappyHexMesh does a poor job of preserving cyclic patches. But cyclicAMIs should work.
If you are running MRF you need to add interfaces to nonRotatingPatches. setSet also works for setting up cellZone. Just create a cellSet and then create a cellZone from the cellSet. Setup of the cyclicAMI. cyclic_half0 { type cyclicAMI; nFaces ###; startFace ###; neighbourPatch cyclic_half1; transform rotational; rotationAxis (0 1 0); rotationCentre (0 0 0); matchTolerance 0.0001; } |
|
December 13, 2013, 03:30 |
|
#12 | ||
Member
Julian Langowski
Join Date: May 2011
Location: Bremen, Germany
Posts: 91
Rep Power: 15 |
Quote:
Quote:
Thanks! Julian |
|||
December 13, 2013, 03:57 |
|
#13 |
Senior Member
Onno
Join Date: Jan 2012
Location: Germany
Posts: 120
Rep Power: 15 |
cyclic tries to match the points of the periodic surfaces. This often fails, even if the points are only a little off. This is often the case when using snappyHexMesh in combination with cyclic patches. cyclicAMI doesn't match the points and instead performs an interpolation. If the mesh points almost match you should barely notice the interface in the final result.
Go to fvOptions and just add the patches that are within the MRF but don't rotate (the interfaces for example) separated by spaces. example: nonRotatingPatches(AMI1 someWallThatDoesntRotate) |
|
December 19, 2013, 06:04 |
|
#14 | |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Quote:
For the mesh I use GridPro. I will have a look at the decomposition methods to see if I can get something running in parallel. To create the rotating zone I use setSet. And then the following commands: # cellSet rotor new cylinderToCell (-5 0 0) (5 0 0) 60 # cellZoneSet rotorZone new setToCellZone rotor hope it helps. |
||
December 19, 2013, 12:53 |
|
#15 |
Senior Member
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18 |
At the following link you will find several videos about a surface piercing propeller I computed recently.
www.youtube.com/user/stephanesanchi I have followed the propeller tutorial (AMI) steps for the mesh generation process. And I used the pimpleDyMFoam solver with the settings (fvS* files) of the mixer tutorial. Regards, Stéphane. |
|
December 20, 2013, 01:53 |
|
#16 |
Member
Akshay Kumar
Join Date: Aug 2010
Location: India
Posts: 84
Rep Power: 15 |
I'd suggest you extend the sides of inlet and outlet. The extended region will now not be a part of your MRF zone. This should solve the problem.
The issue is that when you specify velocity on the boundary which is in the reference zone, there arises an issue of relative velocity. This is why SRF foam uses an relative criteria to calculate the inlet and outlet conditions. |
|
December 27, 2013, 08:19 |
|
#17 | |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Quote:
It is a nice simulation. However, how is it related to the problem we are discussing in this topic? Your simulations looks like a 3D simulation right? this is not the case for me. |
||
December 30, 2013, 17:07 |
|
#18 |
Senior Member
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18 |
Hi Vincent,
Sorry, but your 2nd post (with the 5 pictures) show a 3D case. Regards, Stéphane. |
|
December 31, 2013, 01:17 |
|
#19 |
Senior Member
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18 |
Hi Stephane,
Indeed, but that was at the beginning. I got the MRF simulation running in serial with the cyclic problem. The remaining problem is that it does not run in parallel |
|
January 28, 2014, 07:30 |
|
#20 |
Member
Tobias Adam
Join Date: Oct 2013
Location: Siegen
Posts: 55
Rep Power: 12 |
Hi Vincent
I had the same problem with cyclics. I read about a bug in some OpenFoam versions according to the use of cyclics in a case you want to simulate parallel. Maybe you should just simulate all three blades to avoid the cyclics? Or update your Openfoam-version? I have some questions about the use of MRF-SimpleFoam. I did the same simulation like you (one blade, 120 degree, cyclics) and used the SRFSimpleFoam. Now I´d like to use MRF to compare the results. Could you explain how to use MRF with SimpleFoam and the new system-File fvOptions? Maybe you could share your case or give me a link to some Tutorial? kind Regards Tobias |
|
|
|