Node/cell numbering in InternalMesh

[klevzoff]

The numbering (both local and global) of cells and nodes in InternalMeshGenerator follows z/y/x order, i.e. contiguous indices are assigned along z dimension of the grid. This has the following problems:

• It is inconsistent with the input order of values in TableFunction voxel files, which are ordered x/y/z
• It is inconsistent with users' default expectations, for example when interpreting contents of the HDF5 file generated by TimeHistory output.

The latter point can be somewhat helped by documentation. Currently it doesn't define the ordering explicitly, although the staircase example does show that blocks are numbered that way. It can be argued that users should not rely on cell/node numbering and use other data (such as reference position or element center) for interpretation. In practice that is not what tends to happen though - this discussion is coming from an interaction with someone trying to use GEOSX, and they've stumbled over both of the issues above.

Is there a particular benefit to this cell/node ordering, and is there any opposition to changing it to the more conventional (at least in my experience) x/y/z order?

@rrsettgast @joshua-white @castelletto1 @CusiniM @francoishamon

[joshua-white]

I can't think of a reason not to use x/y/z, as I agree it is more standard. The only minor point is that we often partition in X-Y given our flat geometries, but I don't think the global order should have a real impact on solver performance.

[CusiniM]

I am fine with it. Hopefully it's just a matter of flipping a few loops and it does not require much more effort.

[klevzoff]

Hopefully it's just a matter of flipping a few loops and it does not require much more effort.

I did it in #1715 in order to validate some matrices against my Matlab code, and it was indeed just a few changes in InternalMeshGenerator. However, if anyone depends on it in their post-processing workflows, the change can be a bit more dangerous.

[castelletto1]

I also vote for using the x/y/z order.

[rrsettgast]

XYZ is fine with me.

[francoishamon]

XYZ ordering is fine with me

[CusiniM]

The change is gonna require a rebaseline (I think) and I am guessing we will get numerical diffs in all serial runs and, at least, global Indices diffs in the parallel ones. It won't be very easy to make sure that all results have not changed (although intuitively they shouldn't have). There may be a few postprocessing scripts that rely on the cell index to produce some of the plots of the examples. The first one I could think of is Mandel but that one seems to rely on the coordinates so it should be fine.

[castelletto1]

That used to be the case for the Terzaghi python script. We specifically asked @wrtobin to include the spatial coordinates in the Time History output of the quantity of interest (see #1203, fixed in #1360). Postprocessing scripts should exclusively rely on information available in the Time History output files and/or xml input files. Any script not working due to the new x/y/z ordering (assuming there are) should be modified (removing any ordering assumption).

[paveltomin]

Was x/y/z order implemented at the end?

[FishYNY]

I wanna know, too.

[paveltomin]

seems that it was not, see #2817 (comment)

[castelletto1]

Implemented in #2881.