[gschaider]

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)

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

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]

I had second thoughts about a detail here:

Originally Posted by gschaider

What I would propose would be to add a member huge to pTraits and change the default of the template to

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]

Hi Bernhard,

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

Thanks,

Mattijs

[gschaider]

Originally Posted by mattijs

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]

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]

Originally Posted by henry

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.

Originally Posted by henry

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