Continued Silo/Overlink I/O Support

JustinPrivitera commented 1 year ago

Once #850 is complete these will be the next important tasks:

Short term:

[x] materials - #1171
[x] ability to output sparse by material and full matsets from silo -> blueprint - #1236
[ ] row major/column major + striding for quadvars, reorder??? - see visit plugin for inspiration - #1274
[ ] specsets - #1242
[x] adjsets - #1210
[x] overlink support - nearly there; requires materials support and a few other considerations - #1249
[ ] a new solution is needed for the opts mesh name name collision problem. Perhaps for the root only single domain case we could always force 1 domain. Thus mmesh name will always be the topo name. opts mesh name will not be used anymore. If there is going to be a directory name collision we could make it be dom0.
[ ] name schemes
[ ] polytopal support - #1253
[ ] plumbing the write and read silo calls into blueprint write and read at a high level
[ ] units/labels
[ ] overlink conduit tests over in the overlink conduit repo
[ ] visit tests
[x] ability to read files with no multimeshes - #1274
[ ] mixed topo case - additionally see notes about this in t_blueprint_mesh_examples.cpp

Long Term:

[ ] support the "pre-mixed" case, the list case
[ ] AMR silo to blueprint support
[ ] refactor blueprint and silo i/o so they use the same logic under the hood
[ ] we would like it if, when reading overlink, we could use the padding dimensions to create a field that paints the nodes one color if they are ghosts and another if they are not. Extra credit if you also check for the existence of this field when writing padding dimensions, walk it and determine if padding dims can be extracted from it.

Optional:

[ ] we can add a recursive read of multivars and multimeshes placed in subdirectories (like what visit does) if someone needs it.
[ ] For now we are not supporting material-dependent fields, only material-independent and mixed fields are allowed. We could do some math to take a material-independent field and calculate per-element values for it so we can feed that to silo. We can decide later if we want to add that capability.

JustinPrivitera commented 6 months ago

investigate why silo_save_option_overlink_basic breaks VisIt when rendering fields.

JustinPrivitera commented 6 months ago

places I can get bit by major order:

[x] quadmesh
[x] quadvar
[x] meshvar (pointvar) - probably means nothing
[ ] material - unknown if I have solved this
[ ] species

places I can get bit by min and max index

[x] quadmesh
[x] quadvar
[x] meshvar (pointvar) - probably means nothing
[ ] zonelist

places I can be bit by stride

[x] quadmesh
[x] quadvar
[x] meshvar (pointvar) - probably means nothing
[x] material - see below comment
[ ] species

JustinPrivitera commented 6 months ago

I think it might actually be possible to handle strided structured case when reading materials. I just need to be smart about how I index into the matlist. The tools to help me do that should be in the DBmaterial. I don't think it will require transforming the matset to remove entries.

JustinPrivitera commented 5 months ago

Polyhedral topologies have a node ordering requirement in Silo that is not required for Blueprint. See the Silo docs for more information. What this means is that Blueprint data that does not conform to that requirement will not render properly in VisIt. So, meshes like basic don't look right. Perhaps we could look at some kind of inside-out test and then reorder nodes. We can investigate for the future.

JustinPrivitera commented 1 month ago

How is specmix_quad.silo able to have multiple materials defined? Am I not remembering how these things work?

LLNL / conduit