Level global cell for CpGrid with LGRs

[aritorto]

This PR is relevant for including wells on LGRs (CpGrid). Potentially relevant for output files too.

For CpGrid with LGRs, we determine the global_cell_ values for refined level grids. If an LGR has NX * NY * NZ dimension (amount of cells in each direction x,y,z respectively), then each refined cell can be associated with a (local) IJK and its (local) Cartesian index. For a leaf grid view, we assign the global_cell_ values of either the parent cell or the equivalent cell from level zero.

Not relevant for the Reference Manual.

[aritorto]

jenkins build this please

[aritorto]

jenkins build this please

[aritorto]

jenkins build this please

[aritorto]

@blattms maps for global cell from level grids and the leaf index set have been added. Could you take a look?

@bska do you think these changes - apart from potential use for wells location on LGRs - are also relevant for including LGRs in output files?

[blattms]

If we refine without LGRs, what size and values does globalCell have for the levels?

[aritorto]

If we refine without LGRs, what size and values does globalCell have for the levels?

Good point. I didn't comment on that in the PR description.

When we refine without LGRs, the size of globalcell coincides with the total amount of cells on the level grid/leaf grid view. For refined level grids, the values are 0,1,2,..., total amount of cells in that refined level grid.

For the leaf grid view, both refine-methods (with or without LGRs) do exactly the same: .globalcell[ leaf cell index ] = globalcell value of the oldest ancestor from level zero.

One idea to make these two refine-approaches compatible is to detect minimum and maximums ijk values of marked cells, and mimic what's done for LGRs in the without-LGRs refinement, with these "fake startIJK and endIJK"

[blattms]

One idea to make these two refine-approaches compatible is to detect minimum and maximums ijk values of marked cells, and mimic what's done for LGRs in the without-LGRs refinement, with these "fake startIJK and endIJK"

I don't think we should make them compatible as they are not. cartesian indices on the level only makes sense for LGRs. In the long term we should probably throw if useers use them in adaptively refined grids. Let's postpone this, though,

[aritorto]

There are also comments on checks that won't hold if there are inactive cells. Maybe that is tested elsewhere and irrelevant?

Now there are a few lines in inactiveCell_test.cpp checking that the max value of global cell is below the max Cartesian Index for level grids, and for the leaf (which corresponds to the max Cartesian Index value of level zero grid)

[aritorto]

jenkins build this please

[aritorto]

@blattms thanks for your feedback! (which is now incorporated)

[aritorto]

jenkins build this please