CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Bugs (http://www.cfd-online.com/Forums/openfoam-bugs/)
-   -   Inconsistent behaviour of gMax/gMin for parallel runs (http://www.cfd-online.com/Forums/openfoam-bugs/66024-inconsistent-behaviour-gmax-gmin-parallel-runs.html)

gschaider July 3, 2009 07:21

Inconsistent behaviour of gMax/gMin for parallel runs
 
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 July 3, 2009 07:48

I had second thoughts about a detail here:
Quote:

Originally Posted by gschaider (Post 221367)
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

mattijs July 28, 2009 17:29

Hi Bernhard,

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

Thanks,

Mattijs

gschaider July 29, 2009 05:41

Quote:

Originally Posted by mattijs (Post 224475)
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

henry July 29, 2009 10:32

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

gschaider July 29, 2009 14:23

Quote:

Originally Posted by henry (Post 224593)
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 (Post 224593)
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 ;)


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