SimpleFOAM and MRFZones drive me crazy
 

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?

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:

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.

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

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 :)

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.

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 :)

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.

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,

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?

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

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;
}

Could you explain me, what`s the difference between cyclic and cyclicAMI? Can I use the later even if I don`t use AMI?

How do I do that? Is it necessary if my whole volume is rotating and the boundary patches are not?

Thanks!
Julian

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)

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.

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.

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.

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.

Hi Vincent,

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

Regards,
Stéphane.

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 :confused:

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

Hi~ I have some problem about interface. I use Pointwise to generate the file such as the boundary,point and so on,but how to use Pointwise generate the interface? Could you help me?

I currently don't own a Pointwise license, so can't really help you.

But something likes periodic interfaces should be in the manual, if it isn't ask your Pointwise Support.

the Ufile
PfileSRFPropertiesboundary fvoption toposetdictThe important files are here, could you plz tell me the errors ?When I run the SRFSImpleFoam,it shows as follow:

Sorry, I haven't used SRF yet. But it reads like something is wrong with you fvOptions. Or maybe your missing a file. Have you copied one of the tutorials as a starting point?

It is common practice to set p to zeroGradient at the inlet and fixedValue at the outlet. Just like you did with U but inverted.

Thank you!Onno.Yeah! I really dont konw how to set the fvoption file,especially the type and its coefficient.As to say missing a file,which file is missing?the one to difine the rotate zone? I konw that the MRF solver need a MRFZones file,but I can find it in the SRFtutorials`

MRFZones has been merged into the fvOptions, at least when we are talking about the mainline OpenFOAM.

Compare your case-directory to the tutorials of the solver you are using.

My case directory seems to miss no file ,comparing with the tutorials,but I am wonder whether the problem lies on the mesh, because the pointwise mesh doesnt have the interface.but when I run the checkmesh,though the poor quality,it seems no influence to if the case running but if the case convergence.

Hi Jiaojiao,

For MRFSimpleFoam, it needs a MRFZone. And only the cells in this zone are in the rotating reference frame. However, for SRFSimpleFoam, there is no such a zone. All the cells in the SRF-solver are in the rotating reference frame and all the cells are rotating with the frame. So in SRF-solver, you need to re-define your boundary conditions.

Thanks

I've had some similar issues in running the openFoam applications in my propeller case. I could not run neither the snappyHexMesh nor the simpleFoam in parallel when I typed the commands directly in the console. I solved the porblem by setting up an Allrun file similar to the tutorial's and both mesh and solver ran in parallel.

What I did to run my propeller was basically to modify the unsteady propeller tutorial from pimpleFoam or pimpleDyMFoam to run the steady case with simpleFoam and input my geometry and constraints.

Here is my Allrun files:

Allrun
Allrun.pre