Added comment in PrimitivePatchMeshData
Regarding usage of unsorted variant of meshPoints.
This commit is contained in:
parent
15af49e74a
commit
907c80509d
1 changed files with 5 additions and 6 deletions
|
@ -73,12 +73,11 @@ calcMeshData() const
|
||||||
// number of faces in the patch
|
// number of faces in the patch
|
||||||
Map<label> markedPoints(4*this->size());
|
Map<label> markedPoints(4*this->size());
|
||||||
|
|
||||||
// Important:
|
// Note: foam-extend was relying on strong ordering of meshPoints on
|
||||||
// ~~~~~~~~~~
|
// processor patches which causes point ordering errors when doing Dynamic
|
||||||
// In <= 1.5 the meshPoints would be in increasing order but this gives
|
// Load Balancing. Because of this ordering error on two sides of processor
|
||||||
// problems in processor point synchronisation where we have to find out
|
// boundaries, point fields ended up having wrong values near processor
|
||||||
// how the opposite side would have allocated points. We'll use unsorted
|
// boundaries. Revert to unsorted version. VV, 11/July/2019.
|
||||||
// version to avoid certain ordering problems
|
|
||||||
dynamicLabelList meshPoints(2*this->size());
|
dynamicLabelList meshPoints(2*this->size());
|
||||||
forAll(*this, facei)
|
forAll(*this, facei)
|
||||||
{
|
{
|
||||||
|
|
Reference in a new issue