Tag origin of DAGMC file on .h5m

[pshriwise]

Point of discussion for next meeting:

With the many workflows for generating DAGMC models, it would be nice to add a flag to the DAGMC .h5m spec to indicate the point of origin of the DAGMC model (Svalinn plugin, Cubit , cad_to_openmc, cad_to_dagmc, etc.). Based on this flag we can expect additional metadata to be present (or not).

[pshriwise]

Things to determine: what type this flag will be (MB_TYPE_OPAQUE, MB_TYPE_INTEGER, etc.), what will the tag name be

[pshriwise]

Not a bad idea! I think it might be a little overkill though. I expect that the points of origin won't provide metadata that is distinct but rather supplementary to the required data for transport.

[gonuke]

I think that new entrants that have a different set of metadata can just claim any unused integer. I think it's largely self governing as long as we don't have too many folks developing different sets of metadata simultaneously and claiming the same integer.

[gonuke]

There will be a mild/modest incentive to use an already identified set of metadata, because if not it will require extending DAGMC (and possibly the host codes) for the new integer/metadata set.

[ebknudsen]

It does make sense to have the option of setting an origin explicitly, more metadata tends to be better than less, and I can see the point in using an already present set. Now - from an outside tool-developers perspective - the issue then becomes that it is nigh-on impossible to figure out what is defined, without digging through DAGMC/MOAB source code (fun but slow-going :-) ). Or am I missing something? E.g. I for one, have difficulties telling just from an h5m generated by say cubit, what is a tag that is required, present for the sake of generation but ignored by downstream, etc...
Is there an "official" list of existing metadata anywhere? Or is that simply inferred from source code?

[pshriwise]

I'd say it 100% makes sense to document and publish the current set of required metadata that, going forward, we'd expect to be a minimal set of metadata required for transport. There isn't an existing list that I'm aware of at this time 😞 It's been asked for several times but @gonuke and I simply haven't had time to put something formal together.