[WiWo]

Hi everybody,

I'm currently using the subsetMotionSolverFvMesh tool quite successfully together with a type of interTrackFoam solver. I just need to deform one patch in my mesh and restricting the mesh motion to its vicinity obviously makes computation much faster.

At the same time my mesh is of a size for which I would like to use parallel computation. Now here comes the trouble ... as already pointed out in this thread the subSetmotion solver complains as soon as he encounters that a processor does not contain any cells assigned to the moving mesh region. I was able to track down the problem to the update() method inside subsetMotionSolverFvMesh.C where ...

pointField subsetPoints = motionPtr_->newPoints();

... is called. Execution stops with the error message:

[5] --> FOAM FATAL ERROR:
[5] bad size -1
[5]
[5] From function List<T>::List(const label size)
[5] in file /home/wolfgang/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/List.C at line 50.

It seems that providing a completely empty mesh is not a good idea at all :-)

Now, one can either decompose the mesh in such a way that all processors have their share in the moving region (works fine) or trick the solver by artificially assigning one arbitrary cell in each processor mesh to the motion region (works most of the times) ... this one cell can usually not move anyways.

Still, this is far from a clean solution and I was looking into ways to decide for each processor based on its share in the moving region whether the update() function should be called or not - that can easily be achieved by determining the size of the motion mesh on each processor. Unfortunately, it doesn't seem to be so easy, because then I receive an error from MPI

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

That's as far as I was able to get, because neither my knowledge of parallel processing nor of mesh motion goes deep enough here.

Might there be a reason why mesh.update() has to be executed on all processors? I'm not aware of the inner structure of the mesh motion code. Does anybody know if there is a way to skip the motion execution on processor patches of zero size or to somehow accommodate the treatment of an empty mesh without producing a fatal error?
I guess this type of problem is very specific to subsetMotion, because usually a motionSolver would not encounter an empty motionMesh.

I would be very grateful for your suggestions and hints!

Cheers,
Wolfgang