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

Is the subsetMotionSolver working in parallel?

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

Reply
 
LinkBack Thread Tools Display Modes
Old   November 9, 2011, 07:31
Default Is the subsetMotionSolver working in parallel?
  #1
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 208
Rep Power: 7
Arnoldinho is on a distinguished road
Hi all,

is the current implementation (OF 1.6-ext) of the subsetMotionSolver running in parallel mode?

I'm successfully running the subsetMotionSolver (move cells in a certain area of the mesh only) with the laplaceFaceDecomposition solver in serial mode. However, parallel mode is not working for me! For the decomposition I use decomposeParWithSets, but still have to manually create folders and move variables in the processor* folders. So I'm not sure if its correctly working. When running the simulation in parallel, at the first time step, the simulation crashes giving a "FOAM FATAL ERROR: bad size -1".

Therefore my question: Does anybody successfully use it in parallel mode, and if so, how does the case has to be set up?

Arne
Arnoldinho is offline   Reply With Quote

Old   March 15, 2012, 07:19
Default
  #2
Member
 
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 6
WiWo is on a distinguished road
Hi Arne,

Did you find an answer to this issue in the meantime? I'm also struggling to use the subsetMotionSolver in parallel ... I use decomposePar followed by decomposeSets, which should do the same job as decomposeParWithSets (where did you get that from?).
Still, there are a lot of error messages popping up right away on parallel startup, such as missing files and segmentation issues.
I would appreciate a lot if you could tell me whether or not you've succeeded to get it running and eventually how ...

Cheers,
Wolfgang
WiWo is offline   Reply With Quote

Old   March 16, 2012, 14:11
Default
  #3
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 208
Rep Power: 7
Arnoldinho is on a distinguished road
Hi Wolfgang,

I'm afraid to say that I unfortunately did not manage it and somewhen gave up after some trials with same errors you posted. My purpose was to use the subset as my simulation times were really large due to the motionSolver. In the end, I did not use one of the motion solvers at all but calculated my inner mesh points movement directly. So I avoided the subset problem.
The decomposeParWithSets was somewhere posted by Bernard Gschaider, but I can't remember the source. Just look around in the forum a bit.

I'm sorry that I could not further help you in this regard!

Arne
Arnoldinho is offline   Reply With Quote

Old   March 16, 2012, 15:16
Default
  #4
Member
 
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 6
WiWo is on a distinguished road
Hi Arne,

Thanks for your reply! I was also trying and struggling for some time ... fortunately, I think that I was able to track down the problem.

The error with "FOAM FATAL ERROR: bad size -1" seems to occur as soon as one of my processor domains has no share in the moving region at all. That means that the moving mesh part on that processor domain is zero (meaning the respective set is empty!). Now it seems that mesh.update() still gets called and is deferred to the subsetmotionSolver version of "update()". I believe that there the solver discovers that we were feeding it with an empty mesh ... and produces an error.

Now, I tried to remedy that issue by placing mesh.update() inside an “if” statement which checks the size of the motion mesh and skips the update if it's zero. Sadly, MPI complains about communication errors and drops out - I'm not very much into parallel computation and got no idea why.

Still, there is a very dirty and probably clumsy solution which works (most of the times) ... just make the solver believe that he's actually got one cell of the moving region by changing the "0()" entry inside processor*/constant/polyMesh/sets/motionSubset to "1(0)". I know this is not very elegant and I hope that somebody in here will post a much better and solution!

Still, it seems to work so far because the one allegedly moving cell inside an otherwise static mesh can't really do anything except when it's right at the processor boundary and neighboring a moving Mesh portion on the adjacent processor.

Hope this entry will help others who are probably also struggling with subsetMotion and parallel processing to find a cleaner and more efficient solution than this one.

Cheers,
Wolfgang
WiWo is offline   Reply With Quote

Old   March 16, 2012, 15:32
Default
  #5
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 208
Rep Power: 7
Arnoldinho is on a distinguished road
Hi Wolfgang,

at least you found a workaround! That is good to hear. I'm not sure if it helps you or even if the problem could be similar, but I somewhen had problems with MPI communication as well, so I had to pass some values between the processors. The problem was that I wanted to loop over a patch that was originally only known on one processor, so the others just terminated without "waiting" for the one processor to finish.

As I said, I'm not sure if this helps you, but here is a link to the thread: Access patch points (on different processor) in parallel

Have a nice weekend,
Arne
Arnoldinho is offline   Reply With Quote

Old   March 20, 2012, 14:06
Default
  #6
Member
 
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 6
WiWo is on a distinguished road
Hi Arne,

Thanks - that's a very good hint! Using "if( Pstream::myProcNo() == xyz )" I'm now able to decide whether or not the mesh motion shall be executed based on the size of the motion mesh on each processor. Still, the parallel run fails

*** An error occurred in MPI_Recv
*** on communicator MPI_COMM_WORLD
*** MPI_ERR_TRUNCATE: message truncated
*** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)

... there must still be another twist to this. Maybe somehow the motionSolver needs to do some task on all processors to run properly?

I'll give it another try tomorrow - otherwise my shorthand solution sees to do an acceptable job.

Cheers,
Wolfgang
WiWo is offline   Reply With Quote

Old   April 3, 2014, 13:30
Default
  #7
New Member
 
Giampaolo Cetraro
Join Date: Oct 2012
Posts: 13
Rep Power: 3
misklach is on a distinguished road
Hi,
I know it's a quite old post... did you manage to make subsetMotionSolver work in parallel even if a processor does not have any cell of the subset? I tried the clumsy solution (changing by hand the "0()" entries) but didn't work for me

Thanks
Giamp
misklach is offline   Reply With Quote

Reply

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
Running mapFields with Parallel Source and Parallel Target RDanks OpenFOAM Mesh Utilities 2 June 6, 2011 07:56
parallel fluent under pbs not working kharnabnew FLUENT 0 January 6, 2011 03:28
Problem on Parallel Run Setup Hamidur Rahman CFX 0 September 23, 2007 17:11
OpenCFD enhances OpenFOAM's parallel communications OpenFOAM discussion board administrator OpenFOAM Announcements from ESI-OpenCFD 0 October 2, 2006 08:36
MPICH Parallel Run Error on the Windows Server2003 Saturn CFX 3 August 29, 2006 08:42


All times are GMT -4. The time now is 02:10.