Closed AntoineMazuyer closed 5 years ago
@AntoineMazuyer that is a great help.
Okay, we need to make a decision here. I vote that GEOSX should prefer VTK ordering, and use it wherever possible. This is PAMELA's preferred ordering. @rrsettgast? @AntoineMazuyer?
I concur
@joshua-white you may want to have a look to https://github.com/GEOSX/GEOSX/blob/27e22aef2ded95eb69794976baa1cc65244c2971/src/coreComponents/mesh/CellBlock.cpp#L192 From this line, node and face ordering are defined
(and I agree with the choice of VTK ordering)
@joshua-white @castelletto1 @AntoineMazuyer This was never done. Should I do it?
Just in cast anyone is wondering how terrible the VTK ordering is for higher order hex elements....here you go: https://blog.kitware.com/modeling-arbitrary-order-lagrange-finite-elements-in-the-visualization-toolkit/
@rrsettgast can we keep the VTK node ordering only for order 1 and then just define the ordering for higher elements like we want ? (for instance, for the hex case, we keep the node ordering for the node 0 1 2 3 4 5 6 7, and them do what we want for the next nodes ?)
We just need to have a custom basis for the linear basis hex with the ordering set by hard-coded values. @joshua-white and I had made the decision to stick with the current ordering. Personally I struggled a little with the "correct" choice. I think in the end it came down to:
On argument for VTK ordering:
For your second point, the IO operations should NOT dictate the node ordering. Let's stick with the current node ordering and we can still adapt the IO operation to reorder on the fly.
Describe the issue We have non consistent node ordering in Silo, VTK and GEOX
Screenshots Here are the different node ordering for several softwares.
We have to chose and be consistent to avoid problems.