[Arnoldinho]

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

[WiWo]

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

[Arnoldinho]

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

[WiWo]

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

[Arnoldinho]

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: http://www.cfd-online.com/Forums/ope...-parallel.html

Have a nice weekend,
Arne

[WiWo]

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

[misklach]

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

[Ya_Squall2010]

Hi All,

Is there any update on this issue yet? I am also trying to combine interTrackFoam + subsetMotionSolver. So far it works in serial mode but throws lot of error in parallel mode. Any hints?

Thanks.