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

Inconsistent behaviour of gMax/gMin for parallel runs

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

Reply
 
LinkBack Thread Tools Display Modes
Old   July 3, 2009, 07:21
Default Inconsistent behaviour of gMax/gMin for parallel runs
  #1
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
This seems to be the case for almost any OF-Version I know of:
Assume that you have a scalarField foo whose values are in the range [7,13]. In anticipation of later parallel runs you fetch the minimum of that field using gMin. The correct result of gMin(foo) is of course 7. Now assume that the case runs in parallel. The data in foo is the same, but now it is distributed and on some processors the local foo has the length 0. On these processors the local min is computed using (I quote)
Code:
template<class Type>
Type min(const UList<Type>& f)
{
    if (f.size())
    {
        Type Min(f[0]);
        TFOR_ALL_S_OP_FUNC_F_S(Type, Min, =, min, Type, f, Type, Min)
        return Min;
    }
    else
    {
        WarningIn("min(const UList<Type>&)")
            << "empty field, returning zero" << endl;

        return pTraits<Type>::zero;
    }
}
(BTW: if it doesn't happen on the master processor the Warning is not seen) and defaults to 0. Therefor after the reduce the global minimum is 0.

What I would propose would be to add a member huge to pTraits and change the default of the template to
Code:
return pTraits<Type>::huge;
(negative for gMax )

The only problem that I see to this solution is that there might be code somewhere that relies on min(foo)==0 for foo.size()==0.
gschaider is offline   Reply With Quote

Old   July 3, 2009, 07:48
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
I had second thoughts about a detail here:
Quote:
Originally Posted by gschaider View Post
What I would propose would be to add a member huge to pTraits and change the default of the template to
Code:
return pTraits<Type>::huge;
(negative for gMax )
If this is solved using pTraits it would be a good idea to define (and use) an additional member pTraits<Type>::minusHuge to give consistent treatment for types (like bool ... OK ... not the best example) that have no negative values
gschaider is offline   Reply With Quote

Old   July 28, 2009, 17:29
Default
  #3
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
Hi Bernhard,

this is fixed in 1.6 by indeed using min,zero,one and max from pTraits.

Thanks,

Mattijs
mattijs is offline   Reply With Quote

Old   July 29, 2009, 05:41
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by mattijs View Post
Hi Bernhard,

this is fixed in 1.6 by indeed using min,zero,one and max from pTraits.

Thanks,

Mattijs
Great.

Just one question: will this fix every be coming to 1.5.x? Or let me rephrase this question in more general terms: I noticed that a git for 1.6.x is already available. Does this mean, that the 1.5.x is "closed" (No more fixes will be posted there) or will there still be fixes there for some time?

Any way is fine with me it'd just be good to know what your policy is for that

Bernhard
gschaider is offline   Reply With Quote

Old   July 29, 2009, 10:32
Default
  #5
Senior Member
 
Join Date: Mar 2009
Posts: 854
Rep Power: 13
henry is on a distinguished road
We will concentrate on 1.6.x but if there are urgent problems with 1.5.x we will apply bug fixes as required.

The change to gMax and gMin required changes in several places in the code and given that the problem does not manifest itself often we are not planning to make this change to 1.5.x unless there is a big demand to do so.

Henry
henry is offline   Reply With Quote

Old   July 29, 2009, 14:23
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by henry View Post
We will concentrate on 1.6.x but if there are urgent problems with 1.5.x we will apply bug fixes as required.
This is what I expected. Thanks for clarifying.

And BTW: Thanks for the new release.

Quote:
Originally Posted by henry View Post
The change to gMax and gMin required changes in several places in the code and given that the problem does not manifest itself often we are not planning to make this change to 1.5.x unless there is a big demand to do so.
That's fine with me. I'll just have to remember to remove the workaround when I port to 1.6
gschaider is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 07:37.