WIP: Feature bbox improvements

We could send the whole lot over and do the reductions instead of lots of small reductions. B.t.w. is contiguous() true?

Have you been careful with the distinction between VGREAT (point::max) and GREAT? VGREAT is the exact greatest number and e.g. if you use it in a magEqOp() it will bomb out.

nice

I do not think that setting the boundBox to zero warrants a separate function.

I do not see what clear() in the context of a bounding box should do. The centre of the boundBox is still valid. Why clear to zero? What is it different from invertexBox? Also it will still 'hold' (0 0 0) so is not really empty. I would get rid of this function.

boundBox, treeBoundBox are both contiguous.

I guess this is the reason for great vs. vgreat in treeboundbox vs boundbox. For an inverted box, probably no reason not to use great for both. The invalidate() uses great for tree and vgreat for normal bbox (same as current implementation). In fact, invalidate() just uses the same values as the respective invertedBox.

Partially agreed. Clear is not really empty, but in the current the null-constructor version implicitly contains a (0,0,0) too. I think it would be more consistent to always initialize with an invalid (inverted) box - even for the null constructor. This make much more sense to me. It would then be immediately possible to add a point to such a box and it would just work. It is were redefined like that, could have a single reset(), invalidate(), clear() to revert to an initial (inverted) bounding box state. With this type of change, clear() doesn't sound so bad again, and we can ditch invalidate() as being too obscure.

Pstream::listCombineGather(bbs, boundBoxOp()); Pstream::listCombineScatter(bbs);

Marked this merge request as a Work In Progress

By Andrew Heather on 2016-10-04T09:36:11 (imported from GitLab project)

Status changed to closed

To be re-opened after the 1612 release.