ndarray extension to fields

[cyrush]

a few ideas I don't want to lose, so throwing them up here:

using a ND array to define a field on a 2D structured mesh where assoc between field values and the elements is fully specified (vs blueprints implicit i,j relationship)

These examples are for a 10x10 element mesh:

scalar field:

field:
  values: [ lots of values] 
  topology: "topo"
  association: "element"
  shape: [ 10, 10]
  indices: [ "i","j"] # order corresponds to shape above, names matter
  strides: [ blah,blah] # optional

vector field:

field:
  values: [ lots of values] 
  topology: "topo"
  association: "element"
  shape: [ 10, 10, 3 ]
  indices: [ "i", "j", "v"] # order corresponds to shape above, "i" and "j" names matter
  strides: [ blah,blah,blah]  # optional

using a ND array to define a field o on an unstructured mesh where assoc between field values and the elements is fully specified (vs implicit id ->element relationship)

These examples are for a 100 element mesh:

scalar field:

field:
  values: [ lots of values] 
  topology: "topo"
  association: "element"
  shape: [ 100]
  indices: [ "id" ] # "id" name matters
  strides: [ blah,blah] # optional

vector field:

field:
  values: [ lots of values] 
  topology: "topo"
  association: "element"
  shape: [ 100, 3 ]
  indices: [ "id","v"] # "id" name matters
  strides: [ blah,blah] # optional

[cyrush]

@xjrc

this extra info would allow us to automatically use things like ZFP that exploit ND structure.

I think -- its also an idea that could help us solve the striding demands for complex cases like @bryujin has.

[cyrush]

the same approach could be applied to link structured topos to almost structured but kind of funky coordsets.

[cyrush]

offsets is another option we may need.

[cyrush]

and indices conflicts with the o2m use.

Overall - these ideas can help, but we need to carefully consider the proper names (the ones above aren't my proposal for proper names)

[cyrush]

the shapes here implies ND vs sizes which implies o2m (1D to many (ragged/varying))

[cyrush]

matt used labels instead of indices in a demo, that's another option.

[xjrc]

In general, I think this is a great idea and very necessary to deal with the growing complexity of data abstraction being folded into Conduit/Blueprint. I remember @mclarsen presenting some of his ideas on this subject a few months ago at the Conduit meeting; is there anywhere that I can find some recent examples? Looking at some concrete samples would help me better understand the logic/needs.

[cyrush]

TODO: We have an evolution of this and a much better example, add the example here.