[chapman]

Hello everyone,

does anyone use icoDyMFoam on multiple CPUs?

Currently I am trying to use a GGI interface to connect two meshes. This works fine using a single CPU or two cores (Intel Core 2 Duo) on a single machine, but running parallel fails.

Here is the OpenFOAM log:

Create time

Create mesh for time = 0

Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

--> FOAM Warning :
    From function min(const UList<Type>&)
    in file lnInclude/FieldFunctions.C at line 342
    empty field, returning zero
15 additional processes aborted (not shown)

And thats the mpirun error:

Signal: Segmentation fault (11)
Signal code:  (-6)

I would be very glad if anybody had a hint what is going wrong here. Thank you so far.


Regards, Andy

[chapman]

Some additional information

My steps are the following:

1.) setSet -batch setBatch

setBatch
faceSet nameofzone1 new patchToFace outletofmesh1
faceSet nameofzone2 new patchToFace inletofmesh2
quit

2.) setsToZones -noFlipMap
3.) decomposePar

decomposeParDict
numberOfSubdomains 16;
method metis;
// method hierarchical;
preservePatches (outletofmesh1 inletofmesh2);
preserveFaceZones (nameofzone1 nameofzone2);

...

4.) mpirun -np 16 icoDyMFoam -case /mycase -parallel > logfile

[kwardle]

I get the same error but mine runs with no problem otherwise. Perhaps your seg fault is separate from this problem. Did you check that when you decompose your mesh that your sliding boundaries are all on the same processor? Add:

globalFaceZones ( nameofzone1 nameofzone2 );

to your decomposeParDict. This seems to work. I have seen other post which mention adding

preservePatches (__ __);
preserveFaceZones (__ __);

but the globalFaceZones command seems to work fine for me.

[chapman]

Hi,

I will try this command since I have never heard of it.

globalFaceZones ( nameofzone1 nameofzone2 );

Edit:
Thank you very much, kwardle for this hint. It seems like you saved my weekend since I have been working on this problem for days!

I still get the same error for every timestep, but not it runs also parallel.

[louisgag]

Hi Chapman,

Using turbDyMFoam in parallel I had a similar issue... I also found that after doing everything described in this post I get errors running in paralllel from time 0. The trick is then to run in single-processor mode for one or more timesteps and then decomposePar and start the parallel run. I still get the warning about empty field but everything seems fine.

regards,

-Louis

[chapman]

Originally Posted by louisgag

Using turbDyMFoam in parallel I had a similar issue... I also found that after doing everything described in this post I get errors running in paralllel from time 0. The trick is then to run in single-processor mode for one or more timesteps and then decomposePar and start the parallel run. I still get the warning about empty field but everything seems fine.

Hi Louis,

thank you for this hint.

In the meantime I encountered the same problem. Unfortunately, your "trick" to run in single-processor mode for one timestep and then switch to parallel works only from time to time. Sometimes I get the following error:

...

Reading field rAU if present

Starting time loop

Volume: new = 165.213 old = 331.523 change = 166.31 ratio = -0.501653
Courant Number mean: 0 max: 0.0183856 velocity magnitude: 1
deltaT = 0.0012
--> FOAM Warning : 
    From function dlLibraryTable::open(const dictionary& dict, const word& libsEntry, const TablePtr tablePtr)
    in file lnInclude/dlLibraryTableTemplates.C at line 68
    library "libsampling.so" did not introduce any new entries

Creating ggi check
Time = 0.0012

...

After that the process is killed.

I am quite sure that I haven't made any changes in comparison to the succesful runs. Does anyone know what is going wrong here?

Regards, Andy

[louisgag]

Hi Andy,

before doing the single processor "pre-run" I also remove any *Zones files in the polyMesh directory and the cellToRegion file in the constant directory... Also, from the error you posted I only see the warning that mentions libSampling is no longer needed in controDict...

Regards,

-Louis

[chapman]

Originally Posted by louisgag

before doing the single processor "pre-run" I also remove any *Zones files in the polyMesh directory and the cellToRegion file in the constant directory...

Yes, this seems to be necessary. However, before doing the "pre-run" I do the following jobs

setSet -batch setBatch
setsToZones -noFlipMap

which only leeds to the file "faceZones". After removing this file a single CPU run is possible, which seems to create all three "*Zones" files.

What about the other file "cellToRegion" you mentioned above? I haven't got such a file in my constant-directory...

Regards, Andy

[louisgag]

Hello again Andy,

I am stuck on a case which I haven't managed to run in parallel even with my "trick". I'm updating the svn and will let you know if I find the solution.
As for the cellToRegion file, I remove it more due to an habit.. it is probably not necessary for my trick to work...

Have a good day,
-Louis

[chapman]

Hello everyone,

in the meantime icoDyMFoam works very well even without Louis' trick.

However, I am facing another problem at the moment. I would like to connect a stator mesh and a rotor mesh using a SlidingInterface. Unfortunately, not only the rotor mesh is moving


My dynamicMeshDict looks like this:

dynamicFvMeshLib  "libtopoChangerFvMesh.so";
dynamicFvMesh      mixerGgiFvMesh;

mixerGgiFvMeshCoeffs
{
    coordinateSystem
    {
        type            cylindrical;
        origin          (1.7 0 0);
        axis            (0 0 1);
        direction      (1 0 0);
    }

    rpm             60;

    slider
    {
        moving    ( rotor_inlet );
        static      ( stator_outlet );
    }
}

Is it necessary to put also the other rotor patches (like rotor_casing, rotor_hub, etc.) in "moving"?

[olivier]

Hello Andy,

Try to put the patch that delimit your rotating and non rotating parts, like rotor_outlet for the moving slider and stator_inlet for the static slider

Olivier

[chapman]

Hello Olivier,

I am dealing with a turbine, so "stator_outlet" is static and "rotor_inlet" is moving. This definition is correct, isn't it?

Or do I have to put any other patches into moving/static?


Kind regards, Andy

[olivier]

Hi Andy,

You don't need to put more patches than those 2 ones. Where is your origin located then? You have to be careful with it: in the code mixerGgiFvMesh, you can see that OpenFoam will look at the nearest cell to the origin and consider the part where this cell is as rotating.
Is your origin in the rotor or in the stator region?

Olivier

[chapman]

Hi Olivier,

my origin is located in the rotor region.

Speaking of the other keywords:
The keyword axis is self-explaining, but what about direction ?

Andy

[olivier]

I am not quite sure how to define the direction, but I think the way you defined it is correct. I believe it has to be perpendicular to the axis direction.

So if I understood your case right, rotor_outlet and stator_inlet are the two patches that define the GGI interface? Did you set your interface correctly? Did you define your two zones with help of setSet? And when you say that some parts are rotating and shouldn't which are they?

Olivier

[chapman]

Originally Posted by olivier

So if I understood your case right, rotor_outlet and stator_inlet are the two patches that define the GGI interface? Did you set your interface correctly? Did you define your two zones with help of setSet? And when you say that some parts are rotating and shouldn't which are they?

Yes, the two patches that define the GGI interface are defined correctly and I use setSet and setsToZones.

It seems that rotor and (!) stator are rotating. Needless to say, I want only the rotor to rotate...

Perhaps there is something wrong with my GGI interface due to the shape of the two patches. The contact area is kind of conical instead of plain.

[olivier]

Could you share your case?

Olivier

[olivier]

Hi Andy,

I have been thinking about your case, and something is bothering me here:

you put :

slider
{
moving ( rotor_inlet );
static ( stator_outlet );
}

In this part of the dictionary, you have to put the limits of the rotating and static parts of your geometry. That means that if you use the dynamicFvMesh mixerGgiFvMesh, this limit would be your GGI interface. So if have a GGI interface (GGI_INT and GGI_OUT as an example ), you will get

slider
moving GGI_INT
static GGI_OUT

if you want the rotor to move you will need

1 that the rotor is closed to the origin ( so basically that the rotor is the inside part of the turbine )
2 that the GGI_INT part of the GGI interface belongs to the rotor side. So that the GGI_OUT should belong to the stator side.

I don't think that you set the names correctly there, or if you do then I didn't understand your case, and I am sorry.

Olivier

[chapman]

Hi Olivier,

thank you for your help so far.

I'd like to provide some further informationen about what I'm trying to do:

1.) I am dealing with an axial turbine. So basically there is no inside/outside part as the stator and the rotor are arranged in a row and they "share" the same axis.
2.) My GGI patches are normal to this axis. Futhermore they are not plain but rather conical.


Now that I've read you last answer I am wondering about two things:

1.) How far can mixerGgiFvMesh be used to handle this alignment?
2.) Do I need some more patches? As said above, I've been using stator_outlet and rotor_inlet as the GGI patches.


Regards, Andy

[olivier]

Hi Andy,

That changes things. I have tried last year to use the turbDyMFoam on an axial turbine, but there was some kind of error if I remember correctly, all though I did succeed to rotate only the rotor.
One suggestion would be to try the same case with mixerFvMesh to see if it works. As both mixerFvMesh and mixerGgiFvMesh are very similar are very similar, it shouldn't work but you never know.
Then the mixerGgiFvMesh was built on the mixer2D test case, it is a dynamicFvMesh build to solve a mixer case, so I guess a rotor and a stator radially set. It might be that you need to look into the mixerFvMesh or mixerGgiFvMesh, and modify it a bit so that it can fit your case. That might explain why both your rotor and stator are rotating

Good luck

Olivier