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

MPI comunication wrong after use of gather/scatter

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 5, 2011, 06:09
Default MPI comunication wrong after use of gather/scatter
  #1
Member
 
matteo lombardi
Join Date: Apr 2009
Posts: 67
Rep Power: 16
matteoL is on a distinguished road
Hello,
I have implemented my own version of a mesh motion solver that, when run in parallel, it needs to exchange data with other partitions.
To do so I have used the gather/scatter and IPStream/OPStream functions available in OF.

The new library seems to work fine.

The problem is that now when i run my code in parallel the fluid solver doesn't work anymore!
The residual of U and P solver are very high and looking at the solution (see attached image) it seems like there is no more comunications between processors since there is a very high unphysical boundary layer where the different partitions touch each other.

The cube shoew in the picture has been decomposed in 3 subdomain with simple (1 1 3) scheme. The correct result should be a small value everywhere but on the top (cavity problem, initial time step).

Any idea how can I have managed to mess up with the MPI comunications in the linear solvers? I haven't touched them at all and my own library I have used only OF MPI functions (i.e. gather/scatter/PStream).

Thanks,
Matteo
Attached Images
File Type: jpg Pressure.jpg (18.1 KB, 23 views)
matteoL is offline   Reply With Quote

Old   October 10, 2011, 14:19
Default Gather/scatter is not the problem... mesh.update() is the trigger..
  #2
Member
 
matteo lombardi
Join Date: Apr 2009
Posts: 67
Rep Power: 16
matteoL is on a distinguished road
After some more analysis, I have discovered that the problem is not linked at all to gather/scatter...

In fact I have no problem If I use my mesh motion solver as long as i don' t call for mesh.update().

mesh.update() call for my own version of curPoints() anbd solve().

Even If i set solve() to do nothing and curPoitns() just to give back the current mesh points without modifiyng them, I still have the problem described above in parallel..

How can this be possible? What else is called in mesh.update that could create such a strange behaviour?

Thanks again,
Matteo
matteoL 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
udf error srihari FLUENT 1 October 31, 2016 15:18
Sgimpi pere OpenFOAM 27 September 24, 2011 08:57
Building OpenFOAM on IRIX lakeat OpenFOAM Installation 7 July 16, 2008 08:27
Error using LaunderGibsonRSTM on SGI ALTIX 4700 jaswi OpenFOAM 2 April 29, 2008 11:54
Is Testsuite on the way or not lakeat OpenFOAM Installation 6 April 28, 2008 12:12


All times are GMT -4. The time now is 12:42.