CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

subsetMotion solver in parallel

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

Like Tree1Likes
  • 1 Post By WiWo

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   March 21, 2012, 11:21
Default subsetMotion solver in parallel
  #1
Member
 
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 17
WiWo is on a distinguished road
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
Bernhard likes this.
WiWo is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
IcePak network objects in parallel solver Alexey FLUENT 1 December 25, 2013 09:32
AMG Solver in parallel fra76 OpenFOAM Running, Solving & CFD 13 February 22, 2007 03:38
Which parallel solver is most suitable for my app? zonexo Main CFD Forum 1 November 17, 2006 10:46
compressible two phase flow in CFX4.4 youngan CFX 0 July 2, 2003 00:32
Airpak: How to use the parallel solver? Ivan de Miguel FLUENT 1 December 27, 2001 10:15


All times are GMT -4. The time now is 20:54.