Hi all, I try to get the MR
 

Hi all,

I try to get the MRFSimpleFoam tutorial running. Compiling runs with both 1.4.1 and 1.5 without problems on my Core2Duo (using 64 Bit). However, solving fails:

1.4.1:
MRFSimpleFoam . mixerVessel2D
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.4.1 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : MRFSimpleFoam . mixerVessel2D
Date : Aug 29 2008
Time : 07:05:21
Host : Basti-Notebook.lan
PID : 9432
Root : /home/basti/OpenFOAM/basti-1.4.1/tutorials
Case : mixerVessel2D
Nprocs : 1
Create time

Create mesh for time = 0

Reading field p

new cannot satisfy memory request.
This does not necessarily mean you have run out of virtual memory.
It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library

1.5
MRFSimpleFoam
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5 |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : MRFSimpleFoam
Date : Aug 29 2008
Time : 07:16:41
Host : Basti-Notebook.lan
PID : 11930
Case : /home/basti/OpenFOAM/basti-1.5/tutorials/mixerVessel2D
nProcs : 1

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

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kEpsilon
kEpsilonCoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
alphaEps 0.76923;
}


Starting time loop

Time = 1

smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.0404075, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 0.0403676, No Iterations 2
#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/basti/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/home/basti/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::MRFZone::relativeFlux(Foam::GeometricField<d ouble,>&) const in "/home/basti/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so"
#4 Foam::MRFZones::relativeFlux(Foam::GeometricField< double,>&) const in "/home/basti/OpenFOAM/OpenFOAM-1.5/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 main in "/home/basti/OpenFOAM/basti-1.5/applications/bin/linux64GccDPOpt/MRFSimpleFoam"
#6 __libc_start_main in "/lib/libc.so.6"
#7 Foam::regIOobject::readIfModified() in "/home/basti/OpenFOAM/basti-1.5/applications/bin/linux64GccDPOpt/MRFSimpleFoam"

Any ideas?

BTW can MRFSimpleFOam be run in parallel? I have read somewhere it cannot, but it has a -parallel flag?

Regards BastiL

HI BastiL try to check your
 

HI BastiL

try to check your boundary setting，itseems like the boundary value cause the iteration go divagenced

it can run in parallel way,look at the userguide of OF in appendix A

wayne

Works fine for me in 1.5, also
 

Works fine for me in 1.5, also under valgrind. Your 'new cannot satisfy ..' error is usually caused by inconsistent libraries. Make sure you compile everything with the same compiler.

I see: It seems like 1.5 start
 

I see: It seems like 1.5 starts solving and diverges in Iteration 1. I will check BC; even though I did not change them...
1.4.1 does not seem to start at all. I uses the compiler supplied with 1.5 and 1.4.1, respectively.

I reviewed BC and verything lo
 

I reviewed BC and verything looks fine for me. Maybe I could upload the case here and somebody could try to run it.
How do I make sure to use only one compiler. I usually source bashrc file from appropriate version and run wmake afterwards... That is what I did for both 1.4.1 and 1.5

I reviewed BC and everything l
 

I reviewed BC and everything looks fine for me. Maybe I could upload the case here and somebody could try to run it.
How do I make sure to use only one compiler. I usually source bashrc file from appropriate version and run wmake afterwards... That is what I did for both 1.4.1 and 1.5

Thanks guys got it runnig. Obv
 

Thanks guys got it runnig. Obviously something with compiling was wrong, don't know what exactly.

I can not find something about parallel in UG Appendix A, its about FoamX. Is MRFSimpleFoam fully parallel or does the MRF Fluid have to be on one partition? I read about developments for turbomachinery? is MRFSimpleFoam depreciated?

By the way I compiled PV3FoamReader but I do not understand what it is good for?

Hello BastiL, Yes MRFSimpleFo
 

Hello BastiL,
Yes MRFSimpleFoam is fully parallel, and not at all obsolete!

Dragos

Hi Dragos do you have tried t
 

Hi Dragos
do you have tried the simpleSRFFoam in OF1.5？i think it is similar to the MRFsimpleFoam in consumption of calculation.but when i tried a similar case of centrifugal pump impeller of same mesh and boundary condition.simpleSRFFoam in OF1.5 is too slow--only 10 steps for 10 hours.but hunderds steps for MRFSimpleFoam in OF1.4.that is why? how can i do?

wayne

Thanks once more. I could run
 

Thanks once more. I could run in parallel, too.However, everything runs in DP but not in SP. MAybe I did something wrong in compiling it in SP.

Regards.

Hello Wayne, Unfortunately I
 

Hello Wayne,
Unfortunately I did not switch to 1.5 version, so I can only guess that some of the thresholds for the linear solvers are changed and too tight.

Dragos

Hello every one, As of Differ
 

Hello every one,
As of Different ways to treat rotating geometries by Olivier Petit, the MRFSimpleFoam is on OpenCFD versions and as I get error in runnnig the solver in dev version I like to know if there is any body who is runnig this solver on dev version as well.
My second question is that if there is any adjustment except .bashrc when you want to run two versions of OpenFOAM on the same machine.
Thanks

hi guys i have tried to com
 

hi guys

i have tried to compile the MRFSimpleFoam.C
and run the mixerVessel2D case but i got this error:

/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5 |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : MRFSimpleFoam
Date : Dec 29 2008
Time : 11:39:15
Host : antonio-laptop
PID : 19346
Case : /home/cfduser/OpenFOAM/cfduser-1.5/tutorials/MRFSimpleFoam/mixerVessel2D
nProcs : 1

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

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kEpsilon
kEpsilonCoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
alphaEps 0.76923;
}



cannot find MRF faceZone rotor

From function Foam::MRFZone::MRFZone(const fvMesh& , const dictionary&)
in file cfdTools/general/MRF/MRFZone.C at line 71.

FOAM exiting


any suggestions?

strictly speaking if I have a
 

strictly speaking if I have a case that works with simpleFoam, What file should I add/modify to have a rotation?

thanks in advance

try simpleSRFFoam.you will fin
 

try simpleSRFFoam.you will find more

I have been able to run the mi
 

I have been able to run the mixerVessel case but still i do not understand where to set the region which is rotating. Does anyone have a very simple case?

Hi Antonio, Have a look at th
 

Hi Antonio,
Have a look at this tutorial: MRFSimpleFoam Tutorial

I hope this is helpful,
Dragos

Hello Dragos , Wayne and people who have solved this problem

I need help from you guys. I am facing similar problem: "cannot find MRF faceZone rotor". I tried but i am unsuccessful.

I have done the following steps:

1. fluentMeshToFoam mixer.msh -writeSets -writeZones

It seems to have been able to generate the cellZones and FaceZones, and shows three domains that are there:

TANK domain, IMPELLER domain and a BOTTOM domain (where inlet is).

IMPELLER domain is the rotating domain.

2. So, i felt that i do not need to do cellSet, setsToZones, faceSet, setsToZones routine. Am I right?

3. then, I corrected the cellSetDict file, see below, is this right?

name rotor;
action new;
topoSetSources
(
// Cells in cell zone
zoneToCell
{
name IMPELLER; // name of cellZone
}


as IMPELLER is the rotating domain.

4. Now, on running ./Allrun from the problem directory

i get the error, "cannot find MRF faceZone rotor".

so, i did

cellset and
setsToZones -noFlipMap

It worked upto this.

5. But error cropped up when i did faceSet,

Reading faceSetDict
unexpected class name cellSet expected faceSet
while reading object rotor
file: /usr6/tab01c/OpenFOAM/tab01c-1.5/run/tutorials/MRFSimpleFoam/mixermandar/constant/polyMesh/sets/rotor at line 15.
From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 114.
FOAM exiting

Can anyone please guide me on this. I have three domains, impeller domian being the rotating domain. Is it problem with ./Allrun file?. How i should go about solving this. thanks for your help.

Please let me know your suggestions, i wil ltry implementing this. Enjoy Easter by the way. Thanks.

Newer MRFsimpleFoam?
 

Hello Dragos,
I have a short question about your MRFsimpleFoam tutorial. Since I want to implement a similar case (a ducted fan), I started to run your case to learn how to set up mine. However, after no more than 15 iterations, I had a Floating Point exception error, due to the fast increase in epsilon and k values.
Since to make it run I had to copy an old RASproperties file into /costant , I guess that there is a newer version of the solver. Indeed trasportProperties file has the same function of RASProperties but with a slightly different formulation. I tried to install the solver files that I got when downloaded your files, but it didn't work. So I think it is due to the new OF 1.5.dev version. Am I right? If so, where can I get it? Thanks a lot!

Maddalena

changed MRFZones?
 

Yes, you are right. You do not need to do any cellSet, setsToZones, faceSet, setsToZones routines, neither ./Allrun, that does the same. After doing fluentMeshToFoam mixer.msh -writeSets -writeZones, cells and zones are ok. Btw, did you change MRFZones file to match your rotating patch and domain?
Maddalena

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