CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

SimpleFOAM and MRFZones drive me crazy

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 21, 2013, 05:30
Default SimpleFOAM and MRFZones drive me crazy
  #1
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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?
vinz is offline   Reply With Quote

Old   October 22, 2013, 03:15
Default
  #2
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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;
    }
}
If I don't activate the MRFzone, the result looks ok, I have a velocity in the Y direction of Uy=6m/s which is what I prescribed in the "0" directory.

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.
Attached Images
File Type: jpg Uy.jpg (52.3 KB, 248 views)
File Type: jpg Ux.jpg (49.4 KB, 224 views)
File Type: jpg Uz.jpg (50.4 KB, 181 views)
File Type: jpg Uy_allPatchesRotating.jpg (59.0 KB, 191 views)
File Type: jpg Ux_allPatchesRotating.jpg (58.4 KB, 145 views)
bennn likes this.
vinz is offline   Reply With Quote

Old   October 22, 2013, 03:28
Default
  #3
Member
 
Join Date: Apr 2013
Posts: 32
Rep Power: 12
simt is on a distinguished road
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
simt is offline   Reply With Quote

Old   October 22, 2013, 03:32
Default
  #4
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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
vinz is offline   Reply With Quote

Old   October 22, 2013, 03:36
Default
  #5
Member
 
Join Date: Apr 2013
Posts: 32
Rep Power: 12
simt is on a distinguished road
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.
simt is offline   Reply With Quote

Old   October 31, 2013, 08:52
Default
  #6
New Member
 
Ivan
Join Date: Sep 2013
Location: Czech Republic
Posts: 2
Rep Power: 0
helpmewithcfd is on a distinguished road
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
helpmewithcfd is offline   Reply With Quote

Old   October 31, 2013, 10:23
Default
  #7
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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.
vinz is offline   Reply With Quote

Old   November 1, 2013, 07:47
Default
  #8
Member
 
Join Date: Jun 2011
Posts: 51
Rep Power: 14
cfdivan is on a distinguished road
Greetings all,

It looks like you are not doing the set up of the MRF region in right way.

Check out if the following links can help you: MRF, PDF

Regards,
cfdivan is offline   Reply With Quote

Old   November 5, 2013, 03:32
Default
  #9
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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?
vinz is offline   Reply With Quote

Old   December 11, 2013, 06:05
Default
  #10
Member
 
Julian Langowski
Join Date: May 2011
Location: Bremen, Germany
Posts: 91
Rep Power: 14
Ruli is on a distinguished road
Dear vinz,

Quote:
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?
I also had some problems with cyclic BCs and parallelization. What in my experience helped:
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
Ruli is offline   Reply With Quote

Old   December 13, 2013, 03:57
Default
  #11
Senior Member
 
Onno
Join Date: Jan 2012
Location: Germany
Posts: 120
Rep Power: 15
Kaskade is on a distinguished road
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;
}
excolade likes this.
Kaskade is offline   Reply With Quote

Old   December 13, 2013, 04:30
Default
  #12
Member
 
Julian Langowski
Join Date: May 2011
Location: Bremen, Germany
Posts: 91
Rep Power: 14
Ruli is on a distinguished road
Quote:
Originally Posted by Kaskade View Post
snappyHexMesh does a poor job of preserving cyclic patches. But cyclicAMIs should work.
Could you explain me, what`s the difference between cyclic and cyclicAMI? Can I use the later even if I don`t use AMI?

Quote:
Originally Posted by Kaskade View Post
If you are running MRF you need to add interfaces to nonRotatingPatches.
How do I do that? Is it necessary if my whole volume is rotating and the boundary patches are not?

Thanks!
Julian
Ruli is offline   Reply With Quote

Old   December 13, 2013, 04:57
Default
  #13
Senior Member
 
Onno
Join Date: Jan 2012
Location: Germany
Posts: 120
Rep Power: 15
Kaskade is on a distinguished road
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)
Kaskade is offline   Reply With Quote

Old   December 19, 2013, 07:04
Default
  #14
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Quote:
Originally Posted by Ruli View Post
Dear vinz,

I also had some problems with cyclic BCs and parallelization. What in my experience helped:
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
Sorry for the late reply I have not been informed about a new reply on this thread.

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.
vinz is offline   Reply With Quote

Old   December 19, 2013, 13:53
Default
  #15
Senior Member
 
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18
openfoam_user is on a distinguished road
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.
openfoam_user is offline   Reply With Quote

Old   December 20, 2013, 02:53
Default
  #16
Member
 
Akshay Kumar
Join Date: Aug 2010
Location: India
Posts: 84
Rep Power: 15
Akshay is on a distinguished road
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.
kiddmax likes this.
Akshay is offline   Reply With Quote

Old   December 27, 2013, 09:19
Default
  #17
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Quote:
Originally Posted by openfoam_user View Post
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.
Hi Stephane,

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.
vinz is offline   Reply With Quote

Old   December 30, 2013, 18:07
Default
  #18
Senior Member
 
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18
openfoam_user is on a distinguished road
Hi Vincent,

Sorry, but your 2nd post (with the 5 pictures) show a 3D case.

Regards,
Stéphane.
openfoam_user is offline   Reply With Quote

Old   December 31, 2013, 02:17
Default
  #19
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
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
vinz is offline   Reply With Quote

Old   January 28, 2014, 08:30
Default
  #20
Member
 
Tobias Adam
Join Date: Oct 2013
Location: Siegen
Posts: 55
Rep Power: 12
Tobias Adam is on a distinguished road
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
Tobias Adam is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 10:01.