CFD Online Discussion Forums - Inconsistent behaviour of gMax/gMin for parallel runs

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Bugs (https://www.cfd-online.com/Forums/openfoam-bugs/)

- - Inconsistent behaviour of gMax/gMin for parallel runs (https://www.cfd-online.com/Forums/openfoam-bugs/66024-inconsistent-behaviour-gmax-gmin-parallel-runs.html)

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.

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

Hi Bernhard,

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

Thanks,

Mattijs

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

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

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 ;)