Hi Mixer,
I am trying to simulate an MRF problem similar to yours and I get exactly the same error message. So were you able to solve the problem. And if you have, could you please tell me how you solved it?
where do you have to define the MRF region?

Thank you,
Srikara

Thanks Maddalena for the info, i tended to your suggestion today, and
Thanks Srikara for forwarding the information. Yes, i had to replace name of zone 'impeller' region to 'rotor' region..to get it working.

Thanks Maddalena for the info, i tended to your suggestion today, and
Thanks Srikara for forwarding the information. Yes, i had to replace name of zone 'impeller' region to 'rotor' region..to get it working.

For OF experts, I have got stuck on another related problem, if someone using OpenFoam is aware of it, can they please help me:

1. gradientInternalCoeffs cannot be called for a genericFvPatchField (actual type ggi) on patch DOMAIN-INTERFACE-3-SIDE-2-1 of field U in file 0/U"
You are probably trying to solve for a field with a generic boundary condition.

the condition i have put in 0/U file is:

DOMAIN-INTERFACE-3-SIDE-2-1
{
type ggi;
value uniform (0 0 0);
}

Can anyone please suggest where i am going wrong and what the above message means. Thanks for your help.

Do i have to define the domain interfaces (having ggi) in MRFZones file to overcome the gradientInternalCoeffs problem (mentioned above). The gradientInternalCoeffsproblem is perhaps caused by the domain interfaces (where ggi condition is to be used), that are incorporated in constant/polymesh/boundary file after converting the fluent mesh format to OF format. If i remove these entries from boundary files, then checkMesh gives error in topology (as the order of nstartFace gets disupted) and on running MRFSimpleFoam, i see error is 'patches are not consistent with the mesh : internalFaces:1627902 total number of faces:1672062#0 Foam::error::printStack(Foam::Ostream&) .

Hello everyone

@Mandar : you are right, you don't need to do cellSet and faceSet, so you do not need to change your cellSetDict the way you do.

What you do need to do however is to change you constant/MRFZones. MRFSimpleFoam works as followed:
You need to create faceZones and cellZones that will rotate (actually if you have the latest update of openFOAM 1.5-x you just need cellZone). Those two Zones are called in the tutorial "rotor".
Once you did that, you need to specify in constant/MRFZones which part will rotate, so that the solver will add the Coriolis force. This is done by writing down the name of your rotating Zones in constant/MRFZones, and that is what you did not do I guess.
If the name of your rotating face and cellZones is IMPELLER, then you should write down IMPELLER in this dictionnary instead of rotor. Plus, if you have any patch in your rotating domain, such as blades, you should write them down in the same dictionnary.

I am at the moment developping a tutorial on the ercoftac pump, using mixerGgi, MRFSimpleFoam, that I am planing on presenting at the OpenFoam workshop in June in Montreal, but I think I will be ready to release it in a week or 2, with some explanation on the wiki.
I am using openFoam dev version, so that MRFSimpleFoam does work with the dev version.

Olivier

Hello Olivier

Thanks for replying to the post. I am sure there are plenty of us looking forward to your tutorials. Keep the good work going. I have been referring to your earlier tut on 'different ways of treating rotating geometries'. Thanks.

I am still stuck on the same error even after implementing all the suggestions so far. I am including my MRFZones, boundary, a glimpse of CellZone and 0/U file here. Is it Possible that the OF-1.5 version that i have cannot apply ggi with MRFSimpleFoam. how to check for this? This is how my files look like.

MRFZones
1
(
IMPELLER
{
patches (IMPELLER);
origin origin [0 1 0 0 0 0 0] (0 0 0);
axis axis [0 0 0 0 0 0 0] (0 0 1);
omega omega [0 0 -1 0 0 0 0] 100;
}
)
/*I did include the regions in MRF file, like this, but didn't make any difference. */
First region, omega = 100 rad/s

IMPELLER (blades)

IMPELLER
DOMAIN-INTERFACE-3-SIDE-1
DOMAIN-INTERFACE-1-SIDE-1
DOMAIN-INTERFACE-2-SIDE-1

second region, fixed

TANK(external wall)

DOMAIN-INTERFACE-1-SIDE-2
DOMAIN-INTERFACE-3-SIDE-2
THROAT
OVERFLOW

Third region,fixed

FALSE-BOTTOM

AQUEOUS-INLET
ORGANIC-INLET
DOMAIN-INTERFACE-2-SIDE-2

************************************************** *******************************

1. The checkMesh shows everything is alright with topology and mesh.

2. Do i have to include shadowPatch in ggi conditions in boundary file (below). But, even after including it gives same error. so, i left it. Perhaps, it's needed for turbDyMFoam solver.

Boundary File:
19
(
AQUEOUS-INLET
{
type patch;
nFaces 70;
startFace 1627902;
}

DOMAIN-INTERFACE-3-SIDE-2
{
type ggi;
nFaces 424;
startFace 1627972;
}
FALSE-BOTTOM-DEFAULT
{
type wall;
nFaces 6314;
startFace 1628396;
}
ORGANIC-INLET
{
type patch;
nFaces 70;
startFace 1634710;
}
THROAT
{
type patch;
nFaces 228;
startFace 1634780;
}
DOMAIN-INTERFACE-1-SIDE-2
{
type ggi;
nFaces 1324;
startFace 1635008;
}
DOMAIN-INTERFACE-2-SIDE-1
{
type ggi;
nFaces 1704;
startFace 1636332;
}
DOMAIN-INTERFACE-3-SIDE-1
{
type ggi;
nFaces 1250;
startFace 1638036;
}
INNERBOTTOM
{
type wall;
nFaces 5124;
startFace 1639286;
}
LOWER-SHAFT
{
type wall;
nFaces 208;
startFace 1644410;
}
IMPELLER
{
type wall;
nFaces 16764;
startFace 1644618;
}
DOMAIN-INTERFACE-1-SIDE-1
{
type ggi;
nFaces 444;
startFace 1661382;
}
DOMAIN-INTERFACE-2-SIDE-1
{
type ggi;
nFaces 500;
startFace 1661826;
}
OVERFLOW
{
type patch;
nFaces 186;
startFace 1662326;
}
TANK-BOTTOM
{
type wall;
nFaces 1304;
startFace 1662512;
}
TANK-DEFAULT
{
type wall;
nFaces 4910;
startFace 1663816;
}
BAFFLES
{
type wall;
nFaces 1094;
startFace 1668726;
}
SURFACE
{
type wall;
nFaces 1810;
startFace 1669820;
}
UPPERSHAFT
{
type wall;
nFaces 432;
startFace 1671630;
}
)

************************************************** *

Cellzones shows 3 zones: IMPELLER, TANK AND BOTTOM.

0/U file:
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
AQUEOUS-INLET
{
type fixedValue;
value uniform (0 0 0.25);
}

ORGANIC-INLET
{
type fixedValue;
value uniform (0 0 0.25);
}
OVERFLOW
{
type zeroGradient;
}

DOMAIN-INTERFACE-3-SIDE-2
{
type ggi;
value uniform (0 0 0);
}
/* The Domain intreface is where the error is occuring
a bunch of other boundries before it closes */
.
.
.}

I am not able to understand where things are going wrong. Can someone let me know where i am going wrong.

Hello Mandar,

I am not quite sure I follow what you want to do here. In a first time you are speaking about MRFSimpleFoam, and then about turbDyMFoam. Which of those two solvers are you using?

Then I gues you are using openFoam 1.5-dev, and not openFoam 1.5, otherwise yes, the Ggi would not work, it is a part of the developpement version. You should always try to update it as often as possible, as Martin Beaudin and Hrvoje Jasak are regularly putting some new tools in it ( the last in date being the parallelisation of the ggi). Once you did that, the definition in your constant/polyMesh/boundary sould look like the following:

DOMAIN-INTERFACE-1-SIDE-2
{
type ggi;
nFaces 1324;
startFace 1635008;
shadowPatch DOMAIN-INTERFACE-2-SIDE-1;
bridgeOverlap false; // this can be set to true if you have a bad ggi interface between your 2 parts of the mesh//
zone insideZone; //this is for the decomposition when you do parallelisation but it is needed as well even in serie so far//
}
DOMAIN-INTERFACE-2-SIDE-1
{
type ggi;
nFaces 1704;
startFace 1636332;
shadowPatch DOMAIN-INTERFACE-1-SIDE-2;
bridgeOverlap false; // this can be set to true if you have a bad ggi interface between your 2 parts of the mesh//
zone outsideZone; //this is for the decomposition when you do parallelisation but it is needed as well even in serie so far//
}

in your 0 folder you put simply type ggi into U k p epsilon., omega ... If you have the latest update of the ggi you shouldn't need to put a value into it, by default, Martin Beaudoin sets the internalFields value to the ggi as well. But it doesn't hurt to have a value there either.

Then depending on whether it is MRFSimpleFoam or turbDyMFoam you are using, you should have MRFZones or dynamicMeshDict correctly setup.

The last step when using the ggi is to create two new Zones that are used in parallelisation but that are needed as well in serie (even though they don't have a purpose in serie I think, but it is hard coded this way). You need the dict setBatch that you can get from Hrvoje's tutorial mixing Ggi, set it correctly, and use
setSet -batch setBatch.
This should creates 2 new Zones. Now you should be set for the computation.

If you still have some problems, I could take a look into your case, if you can send it to me

Good luck

Olivier

Hello Olivier

currently I am working on a similar problem trying to connect two meshes via GGI.

It works fine on a single CPU but running on multiple CPUs fails due to a "segmentation fault". I have tried a lot of different things, but none of them seems to solve the problem.

Do you have any suggestions or hints?

Regards, Andy


PS: Two questions concerning 'zones'

1.) Is it really necessary to use 'zones' in the boundary-file when using a static GGI?

2.) You told us to use the following command
Is it necessary to use this command as well?

Hello Andy,

Yes, I am sorry I forgot this step setsToZones -noFlipMap. The first step creates two different sets, and the setsToZones convert them into Zones.

Yes it is necessary to build the two zones if you have the latest version of 1.5-dev. That is the way Hrvoje implemented the parallelisation of the ggi, and as far as I am concerned it works well. Segmentation fault is never a good error to get, as it doesn't tell anything, but if you want to run a ggi in parallel, even in static, you need to define an insideZone and an outsideZone in constant/polyMesh/boundary, as well as the other usual parameters that define the ggi, then you need the setBatch dict and the decomposePar dict that you can get in mixerGgi tutorial. Of course you have to adapt it to your case, that is to say put the right patches in setBatch.

When does it crash? Do you succeed to do the decomposition? Do you start the computation? Is it doing any time step?

Best regards

Olivier

Hello Olivier,

thank you very much so far.

Well, it does the decomposition and starts the computation, but no time steps are done. Here is my error log: (parallel, 16 CPUs)

Unfortunately I don't have any clue what is going wrong...

Hi Andy,

I am afraid you're reaching the limit of my knowledge here. But did you check in the processor* folders if you do have a 0 folder? And inside it do you have your velocity field? I am not sure this is due to the ggi parallelization, it is anyway to obscure to me to help you here unfortunately.
If you still are stuck with this error, you should try on a simpler testCase, and see if you succeed to parallelize it and compute it.

Sorry I am not of more help here

Good luck

Olivier

Thank you for you help, Olivier.

Yes, I do have a simple test case (which only consists of two blocks), but it also fails. Maybe I have to check my installation for any updates.


PS: One last (maybe stupid) question:
Do I have to name the zones "insideZone" and "outsideZone"? I guess they can be called anything else...

If it is not too big, perhaps you could send it to me I can have a quick look to it

Olivier

Thanks a lot Oliever, and also Srikara and Maddeline. Now, I understand where i was wrong. I was trying to implement ggi with MRFSimpleFoam in the OF-1.5 version. I need to install the development version. Thanks for all the information. Regards, Mandar.

Hi Olivier,

I have installed the dev version, and started implementing your immensely helpful suggestions. I have been able to make some good progress since last time because of that. I am now stuck up with this problem while using the MRFSimpleFoam. Can you help me in this.

1. Error using MRFSimpleFoam

Reading/calculating face flux field phi
Problem with patch-to zone addressing: some patch faces not found in interpolation zone
From function void ggiPolyPatch::calcZoneAddressing() const
in file meshes/polyMesh/polyPatches/constraint/ggi/ggiPolyPatch.C at line 77.
FOAM aborting

Do you have any suggestion on what it means and where i could be going wrong. Is there any means of checking where i could be going wrong.

2. I made changes in boundary as u suggested, and these are the changes i made in my setBatch, and then implemented the two commands that u mentioned above (though as u mentioned it won't be required for single processor).

SetBatch file
faceSet insideZone new patchToFace DOMAIN-INTERFACE-3-SIDE-1
faceSet insideZone new patchToFace DOMAIN-INTERFACE-2-SIDE-1
faceSet insideZone new patchToFace DOMAIN-INTERFACE-1-SIDE-1
faceSet outsideZone new patchToFace DOMAIN-INTERFACE-3-SIDE-2
faceSet outsideZone new patchToFace DOMAIN-INTERFACE-1-SIDE-2
faceSet outsideZone new patchToFace DOMAIN-INTERFACE-2-SIDE-2
quit

boundary file glimpse

DOMAIN-INTERFACE-1-SIDE-2
{
type ggi;
nFaces 1324;
startFace 1635008;
shadowPatch DOMAIN-INTERFACE-1-SIDE-1;
bridgeOverlap false;
zone outsideZone;
}
.....
etc

Thanks you, I really appreciate your help. Thanks.
Mandar.

Hi Mandar,

Try to rename your zone as "patch_name_zone", such as

DOMAIN-INTERFACE-1-SIDE-2
{
type ggi;
nFaces 1324;
startFace 1635008;
shadowPatch DOMAIN-INTERFACE-1-SIDE-1;
bridgeOverlap false;
zone DOMAIN-INTERFACE-1-SIDE-2_ZONE;
}

And in the setBatch, then you put

faceSet DOMAIN-INTERFACE-1-SIDE-2_ZONE new patchToFace DOMAIN-INTERFACE-1-SIDE-2

You can check if you have all the faceZones created in paraFoam, when you open it and select "include Zones", you should see all your 6 faceZones. I think you didn't create all your zones, that is why you get this error message

Best regards

Olivier

Thanks a ton Olivier. The MRFSimplefoam is working on the present problem. Yes, i had not defined all the 6 faces in the setBatch. Your information was spot on and very helpful. I am trying to get it running now by experimenting with solver schemes, discretization schemes and timestep. Generally, after few timesteps, I come across a floatingpoint exception error, though checkMesh says everything is ok. I will work on this for few more days, hopefully i will get it working. Thanks again. Regards, Mandar

MRFSimpleFoam and cyclic BC
 

Hi
I'm trying to simulate a centrifugal fan using MRFSimpleFoam, I'm new in OF and I have not understood if it's possible to implement in a 3D case the axysimmetric cyclic boundary conditions (as the wedge BC do in 2D).
can you please give me advices?
Aldo

MRFSimpleFoam 2nd order upwind
 

Hi Foamers,
I'm trying to simulata a fan rotor using MRFSimpleFoam, I need a second order upwind discratization, I compiled the fvSchemes in the way you can see below, I got divergence after 4000 iterations.
----------------------------------------------

ddtSchemes
{
default steadyState;
}
gradSchemes
{
default cellLimited Gauss linear 1;
grad(p) cellLimited Gauss linear 1;
grad(U) cellLimited Gauss linear 1;
}
divSchemes
{
default none;
div(phi,U) Gauss linearUpwindV cellMDLimited Gauss linear 1;
div(phi,k) Gauss linearUpwind cellLimited Gauss linear 1;
div(phi,epsilon) Gauss linearUpwind cellLimited Gauss linear 1;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}
laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear limited 1;
laplacian((1|A(U)),p) Gauss linear limited 1;
laplacian(DkEff,k) Gauss linear limited 1;
laplacian(DepsilonEff,epsilon) Gauss linear limited 1;
}
interpolationSchemes
{
default linear;
interpolate(U) linear;
}
snGradSchemes
{
default cellLimited;
}
fluxRequired
{
default no;
p ;
}


------------------------------------------------
Can you please have a look and correct the settings I used
Thanks
Aldo

Dear CFD-folks,

I am new with this whole OpenFoam material but I think I might see the opportunities it is holding.. :o

I want to try to get you my problem described:

I am running (intern a university server-system with crunchers etc.) with OpenFoam1.6.x and I am trying to simulate two coaxial cylinders, the inner one rotates within the outer (stator), inbetween of course there is a fluid...

After several researches and trial and errors, I finally catched up on this special thread with all its rotating things ;)

I tried to run a tutorial named mixerVessel2D on potentialFoam, due to not being able to find a solver called MRFSimpleFoam..!

this is what returned:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field p

Reading field U


Calculating potential flow


--> FOAM FATAL IO ERROR:
keyword laplacian(1,p) is undefined in dictionary "/home/itsnas/michael/OpenFOAM/michael-1.6.x/run/mixerVessel2D/system/fvSchemes::laplacianSchemes"

file: /home/itsnas/michael/OpenFOAM/michael-1.6.x/run/mixerVessel2D/system/fvSchemes::laplacianSchemes from line 41 to line 45.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 396.

FOAM exiting
**************************************

Another way I was hoping to find a solution to my problem was to integrate several scripts into my case files (such as: rotatingBC.dict) or simply to integrate some additions to my velocitiy parameters... To be exact:
--> how can I integrate rotatingBC into my case file system, from where does it have to be accessed / whereto is it linked?? And finally, which solver does it the right way in the end?
Because until now I haven´t been able to understand vital differences among several solvers..!

I was greatful if anybody could push me into the right direction!!

Maybe someday I will be able to do the other way round, at least for newcomers :)