|
[Sponsors] |
April 19, 2011, 12:06 |
Strange behaviour gMax in parallel.
|
#1 |
Senior Member
Francois
Join Date: Jun 2010
Posts: 107
Rep Power: 21 |
Hello all,
A small technical questions which baffles me.. I'm modifying a remapping boundary condition. All works fine on one processor, but switching to a run in parallel, I get "interesting" results. If I do: Code:
Pout << newUValues.size() << endl; Pout << gMax(newUValue) << endl; And if I add: Code:
if( newUValues.size() > 0 ) { Pout << gMax(newUValues) << endl; } Mighty weird. Any ideas why this could be happening? Kind regards, Francois. |
|
April 20, 2011, 05:21 |
|
#2 |
Senior Member
Laurence R. McGlashan
Join Date: Mar 2009
Posts: 370
Rep Power: 23 |
What is the error message, i.e. why does it 'crash'? gMax will give you the maximum value in the field newUValue over all processors. Pout outputs to screen the result on each processor; why not just use Info? I'm guessing there's a problem with your if statement in that perhaps there is a loss of synchronisation, or a problem maybe with gMax only being called on some processors, although I can't say for sure without digging more.
One thing I don't understand is why you're using the if statement?
__________________
Laurence R. McGlashan :: Website |
|
April 20, 2011, 06:26 |
|
#3 |
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 21 |
You can't put global reduce functions inside an if statement that will evaluate differently for different processors. The whole point of a gMax (global maximum) statement is that it will be evaluated for all cpus. If some of them can't evaluate the gMax function because it is inside a heterogeneous if statement, then of course the code will crash. You should first evaluate gMax before the if statement and then do whatever you want to do based on the size of the list.
|
|
April 20, 2011, 12:59 |
|
#4 |
Senior Member
Francois
Join Date: Jun 2010
Posts: 107
Rep Power: 21 |
Dear Laurence, dear Eugene,
Thank you both for your fast replies! It's all clear now. On hindsight, a "stupid" mistake.. I had somehow misunderstood the true meaning of "global maximum". But with the help of Eugene's explanations I can understand what's going on.. gMax is defined in FieldFieldFunctions.C, and when called, it makes a call to PstreamReduceOps.H and does a reduce() operation on the variable being gMax-ed to obtain the data on all processors. So if a processor doesn't answer to the reduce() call, all hell will break lose. @Laurence: The if statement was because I do some computations (boundary layer rescalling) one the variable being if-ed, and that somewhere along the way I was using gMax. So the case here was just a simplified example. Thank you both for your help. Kind regards, Francois. |
|
Tags |
directmappedvelocityflux, gmax, parallel error, pout |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Strange Nut behaviour with K-OmegaSST | nicolarre | OpenFOAM Running, Solving & CFD | 12 | March 19, 2019 21:35 |
Strange behaviour when using LienCubicKE and NonlinearKEShih | hani | OpenFOAM Running, Solving & CFD | 20 | March 6, 2013 11:06 |
Strange behaviour because of contact angle (interfoam) | Kim123 | OpenFOAM Running, Solving & CFD | 0 | January 12, 2011 11:16 |
A Strange Problem in making Parallel (Ansys/CFX 12) | a.sarami | CFX | 13 | October 7, 2010 02:33 |
strange behaviour of GGI in parallel on axis symmetrical case | A.Devesa | OpenFOAM Running, Solving & CFD | 0 | April 6, 2010 04:58 |