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

Parallel "icoDyMFoam" (min(const UList<Type>&) / FieldFunctions.C / empty field)

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

Reply
 
LinkBack Thread Tools Display Modes
Old   April 24, 2009, 10:25
Default Parallel "icoDyMFoam" (min(const UList<Type>&) / FieldFunctions.C / empty field)
  #1
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
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:

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

Code:
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 is offline   Reply With Quote

Old   April 24, 2009, 10:35
Default
  #2
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
Some additional information

My steps are the following:

1.) setSet -batch setBatch

Code:
setBatch
faceSet nameofzone1 new patchToFace outletofmesh1
faceSet nameofzone2 new patchToFace inletofmesh2
quit
2.) setsToZones -noFlipMap
3.) decomposePar

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

...
4.) mpirun -np 16 icoDyMFoam -case /mycase -parallel > logfile
chapman is offline   Reply With Quote

Old   April 24, 2009, 10:41
Default
  #3
Senior Member
 
Kent Wardle
Join Date: Mar 2009
Location: Illinois, USA
Posts: 195
Rep Power: 10
kwardle is on a distinguished road
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.

Last edited by kwardle; April 24, 2009 at 10:43. Reason: forgot space before parenthese in preservePatches ();
kwardle is offline   Reply With Quote

Old   April 24, 2009, 10:44
Default
  #4
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
Hi,

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

Code:
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.

Last edited by chapman; April 24, 2009 at 11:14.
chapman is offline   Reply With Quote

Old   April 28, 2009, 11:27
Default
  #5
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 208
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to 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
louisgag is offline   Reply With Quote

Old   April 29, 2009, 10:27
Default
  #6
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
Quote:
Originally Posted by louisgag View Post
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:

Code:
...

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

Old   April 29, 2009, 11:00
Default
  #7
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 208
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to 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
louisgag is offline   Reply With Quote

Old   April 29, 2009, 11:19
Default
  #8
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
Quote:
Originally Posted by louisgag View Post
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

Code:
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
chapman is offline   Reply With Quote

Old   April 29, 2009, 13:01
Default
  #9
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 208
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to 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
louisgag is offline   Reply With Quote

Old   May 5, 2009, 06:28
Default Moving parts in dynamicMeshDict
  #10
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
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:

Code:
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"?
chapman is offline   Reply With Quote

Old   May 6, 2009, 11:16
Default
  #11
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
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
olivier is offline   Reply With Quote

Old   May 6, 2009, 11:22
Default
  #12
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
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
chapman is offline   Reply With Quote

Old   May 6, 2009, 11:30
Default
  #13
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
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
olivier is offline   Reply With Quote

Old   May 6, 2009, 11:36
Default
  #14
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
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
chapman is offline   Reply With Quote

Old   May 6, 2009, 11:48
Default
  #15
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
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
olivier is offline   Reply With Quote

Old   May 6, 2009, 12:07
Default
  #16
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
Quote:
Originally Posted by olivier View Post
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.
chapman is offline   Reply With Quote

Old   May 6, 2009, 14:08
Default
  #17
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
Could you share your case?

Olivier
olivier is offline   Reply With Quote

Old   May 6, 2009, 14:38
Default
  #18
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
Hi Andy,

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

you put :

Quote:
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
olivier is offline   Reply With Quote

Old   May 7, 2009, 07:59
Default
  #19
New Member
 
Join Date: Apr 2009
Posts: 29
Rep Power: 8
chapman is on a distinguished road
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
chapman is offline   Reply With Quote

Old   May 7, 2009, 10:08
Default
  #20
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
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
olivier is offline   Reply With Quote

Reply

Tags
icodymfoam, mixerggifvmesh, parallel

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Moving mesh Niklas Wikstrom (Wikstrom) OpenFOAM Running, Solving & CFD 122 June 15, 2014 06:20
Differences between serial and parallel runs carsten OpenFOAM Bugs 11 September 12, 2008 11:16
Problem with rhoSimpleFoam matteo_gautero OpenFOAM Running, Solving & CFD 0 February 28, 2008 07:51
IcoFoam parallel woes msrinath80 OpenFOAM Running, Solving & CFD 9 July 22, 2007 02:58
Parallel FOAM FATAL IO ERROR msrinath80 OpenFOAM Running, Solving & CFD 1 July 28, 2006 12:48


All times are GMT -4. The time now is 14:39.