3d: handling non-contiguous memory

ICON uses this weird nproma memory scheme. I.e. 3d variables are stored in a (nproma, nlev, nblks) fortran array. As the number of cells is in general not a divider of nproma this leads to "dead" memory in the last block. Can this be handled with conduit?

Possible workarounds:

• Register the first nblks-1 block as usual (respecting the right cell order) and handle the last block
  • use one "topology" per level and set the memory of the fields separately
  • use one "topology" per cell and set the memory of the fields separately and set stride=nproma

mentioned in issue #5

short answer is yes. I'll need to refresh my memory on how this was handled, but I believe mo_catalyst.f90 does handle this case.

If i see correctly this only handles one level (the surface level) (see here).

I planned to expose all levels (3d data) to catalyst. In this case for the last block we have a nproma x nlev array, where only the first npromz rows hold the actual values.

As far as i see this is not covered by conduits set_external function, right? set_external_float64_ptr_detailed

Another workaround would be to define "dummy" cells. Would that be a better approach?