Blueprint save_mesh() ignores existing state/domain_id and overwrites the value.

[BradWhitlock]

I was saving a file in parallel to HDF5 using conduit::relay::mpi::io::blueprint::save_mesh() and I was confused when I opened up the results in VisIt and the domain numbering in VisIt was not what I had constructed in memory using Conduit. It turns out that the function overwrites any state/domain_id value that might be in the supplied meshes and renumbers in ascending MPI-rank order.

Suppose you have 2 ranks with the following domain numbering (using state/domain_id)
rank 0: {dom2, dom 3}
rank 1: {dom1, dom0}

You'll get a file that saves the domains like this:
dom2-> file domain 0
dom3-> file domain 1
dom1-> file domain 2
dom0-> file domain 3

The domain numbers have been totally changed and you might not get domains where you expect as a result.

Can the following be done instead?

• If state/domain_id values are not present then create them
• If state/domain_id values are present but contain duplicates, or gaps, renumber and issue warning.
• If state/domain_id values are otherwise well-formed, use that number to write the domain file.

[cyrush]

Thanks brad, they are relabeled for legacy reasons.

We have better support we can leverage now with respect to non trivial domain mappings, we should move to use this in more cases

[BradWhitlock]

I figured that this is to ensure a range [0,ndoms-1] of indices that will make nicely numbered filenames. Assuming the state/domain_id already contains a good range of indices then does it matter which rank writes? It looks like the ranks each write independent HDF5 files. I would think the root file would not know the difference.

[nselliott]

conduit::blueprint::mpi::mesh::generate_domain_to_rank_map() creates a mapping between domain IDs and rank numbers that is intended to be stored in the root file for this purpose, when the IDs may be scattered unpredictably among the ranks. It sounds like save_mesh is something that should make use of this. However I'm not sure the support in the VisIt plugin to read that map is available yet.

[cyrush]

@nselliott VisIt 3.3.2 & newer support this style of index. With that available we can address the renumbering issue.

[cyrush]

VisIt now supports the new index type.

To resolve this and still support the current semantics - we should make re-labeling the domain_ids an option to save_mesh