Issues loading grids with reverse faults

[sindre-nistad]

Hi, When extracting a grid (with reverse faults) from RMS, using xtgeo.grid_from_roxar, the program hangs for a long time (maybe 10 - 20 minutes) before throwing an error message.

I tried extracting a different grid in the same project, and that worked as expected.

  File "/private/snis/.roxar/rms-11/python/lib/python3.6/site-packages/xtgeo/grid3d/grid.py", line 100, in grid_from_roxar
    info=info,
  File "/private/snis/.roxar/rms-11/python/lib/python3.6/site-packages/xtgeo/grid3d/grid.py", line 668, in from_roxar
    self, projectname, gname, realisation, dimensions_only, info
  File "<user folder>/.roxar/rms-11/python/lib/python3.6/site-packages/xtgeo/grid3d/_grid_roxapi.py", line 56, in import_grid_roxapi
    _convert_to_xtgeo_grid(self, rox, roxgrid, corners)
  File "<user folder>/.roxar/rms-11/python/lib/python3.6/site-packages/xtgeo/grid3d/_grid_roxapi.py", line 187, in _convert_to_xtgeo_grid
    self.subgrids = subz
  File "<user folder>/.roxar/rms-11/python/lib/python3.6/site-packages/xtgeo/grid3d/grid.py", line 336, in subgrids
    "vertical range, {}".format(zarr)
ValueError: Arrays are not valid as the do not sum to vertical range, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306]

The version of xtgeo used is 2.6.0.

[jcrivenaes]

A will need an example of such a grid for fix + testing

[oddvarlia]

In my preliminary testing using a grid with staircase reverse faults which implies that the grid is of the type having dual grid indexing, the error reported here still is present in version 2.14. Not only the methods to_roxar and from_roxar but also reading properties into such grid fails. Several functions need to updated to handle dual grid indexing. Also utility functions estimating grid conformity type fails or give wrong results such that proportional gridding ends up being classified as mixed conform with top and base 'erosion' due to misinterpretation of layering for grids with duala grid indexing.

[oddvarlia]

An advantage of fixing this issue will be that the APSGUI plugin can work on al types of corner point grids, not only grids where the roxar API attribute for grid: grid.has_dual_index_system is False. In grids with dual grid index system, grid_indexer and simbox_indexer are different. For grids where there are only one index system, both the grid_indexer and the simbox_indexer give the same indexing scheme and are identical.

[eivindjahren]

https://github.com/equinor/xtgeo/blob/5186c0fae2f17e1647a4b0fe289bfc9937e357ea/src/xtgeo/grid3d/grid.py#L406-L410

zarr will not be in sorted order if zonation ranges are not in sorted order. So for instance in a grid with dual index, the simbox index will be in sorted order, but the grid index might not

grid = project.grid_models["some_reverse_fault_grid"].get_grid()
print(grid.grid_indexer.zonation())
>>> {0: [range(0,2), range(4,6)], 1: [range(2,4), range(6,8)]}
print(grid.simbox_indexer.zonation())
>>> {0: [range(0,2)], 1: [range(2,4)]}

So for the simbox indexing system, the zones are contigous, but when we look at the grid_indexer, they are not. Instead

        if set(zarr) != set(range(1, self._nlay + 1)):
            raise ValueError(
                "Arrays are not valid as the do not sum to "
                "vertical range, {}".format(zarr)
            )

would correctly check that zonations span the entire vertical range, although, other parts of the code might assume that zarr is in sorted order.