GEOS-DEV / GEOS

GEOS Simulation Framework
GNU Lesser General Public License v2.1
211 stars 85 forks source link

Consistent cell nodes ordering #178

Closed AntoineMazuyer closed 5 years ago

AntoineMazuyer commented 6 years ago

Describe the issue We have non consistent node ordering in Silo, VTK and GEOX

Screenshots Here are the different node ordering for several softwares. ordering

We have to chose and be consistent to avoid problems.

rrsettgast commented 6 years ago

@AntoineMazuyer that is a great help.

joshua-white commented 5 years ago

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?

rrsettgast commented 5 years ago

I concur

AntoineMazuyer commented 5 years ago

@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

AntoineMazuyer commented 5 years ago

(and I agree with the choice of VTK ordering)

rrsettgast commented 5 years ago

@joshua-white @castelletto1 @AntoineMazuyer This was never done. Should I do it?

rrsettgast commented 5 years ago

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/

AntoineMazuyer commented 5 years ago

@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 ?)

rrsettgast commented 5 years ago

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:

  1. If we didn't have existing conventions, what order would we pick? The answer is the current ordering.
  2. Do we want IO operations to dictate our node ordering?

On argument for VTK ordering:

  1. It isn't hard to just hardcode a linear shape function basis. At some point we likely will want to do this anyways instead of calculating the basis.
AntoineMazuyer commented 5 years ago

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.