Prototype CGNS blueprint mesh relay output

[mlohry]

Not for merge in the current state

This PR is an initial take at providing CGNS file export functionality alongside the existing HDF5 functionality, with the end goal to also enable ascent extracts to CGNS in parallel. In this PR's state the relay::io::blueprint::write_mesh(data, "all_tet", "cgns"); with the braid test mesh produces a valid CGNS file in serial, but reading is not implemented to complete the test. Two initial questions:

1. When calling write_mesh, a call is first made to IOHandle::HandleInterface::write(const Node &node, const std::string &path, const Node &opts) where node contains the raw mesh and solution data. After that a call is made to write(const Node &node, const Node &opts), where now node appears to only contain metadata, not the mesh data. In particular the first call has no filename information -- is the intent for that call to cache the node data somewhere? Only in the subsequent call is the file_pattern given -- should I be writing temp files in the first call and then renaming them in the second?
2. How can I modify your CI to add CGNS test support, or should I leave that to main devs?

@cyrush for notification

[cyrush]

@mlohry awesome that you are working on this!

The IOHandle provides generic I/O vs relay blueprint mesh read/write which is mesh focused.

IOHandle is used to implement many parts of the mesh read/write but that is for convenience. I don't think we need to have CGNS work through the IOHandle.

I think the best analogue for CGNS is our Silo support. IOHandle does not support Silo, since Silo operates at the mesh level of abstraction.

We have Silo logic in the https://github.com/LLNL/conduit/blob/develop/src/libs/relay/conduit_relay_io_silo.cpp, which provide silo::mesh_write and silo::mesh_read methods that handle logic for root files and domain files.

You can place you CGNS logic into the equivalent cgns source file with a cgns::mesh_write and cgns::mesh_read method.

For how silo is connected to the main write/read methods.

When a silo file is detected on read -- the main blueprint read method calls the related silo methods:

conduit/src/libs/relay/conduit_relay_io_blueprint.cpp

Line 2040 in 2eec1ad

if(root_protocol == "silo")

When asked to write a silo file, the main blueprint write method calls the related silo methods:

conduit/src/libs/relay/conduit_relay_io_blueprint.cpp

Line 896 in 2eec1ad

if(file_protocol == "silo")

That way everything works via:

conduit::relay::io::blueprint::write_mesh
conduit::relay::io::blueprint::reaed_mesh

And the python equivalents (we don't need silo specific methods in python)

I think we can follow this same strategy.

For the CI - I will get CGNS added to the build_conduit script. I have a few things in flight with that script right now, and I'll be on travel next week so it might take a bit.

Let me know if you have more questions or if I can clarify more.
Again, thanks for working on this!

[mlohry]

Thanks @cyrush I'll take a look at the silo implementation.
For CI would you be able to change the HDF5 build to enable parallel (single file) support for downstream use in CGNS? As far as I know building HDF5 with parallel support shouldn't affect any of the existing serial code. We'd like to arrive at single-file parallel CGNS output, at least as a runtime option vs the file-per-rank+root-file in the existing hdf5.

[cyrush]

@mlohry yes, I can setup HDF5 to build with mpi support.

[brtnfld]

Also requires HDF5 support.

[mlohry]

@cyrush re previous discussions, my usual build config for CGNS has these cmake options:

        -DCMAKE_INSTALL_PREFIX=... \
        -DCGNS_BUILD_SHARED=ON \
        -DCGNS_ENABLE_FORTRAN=OFF \
        -DCGNS_ENABLE_SCOPING=ON \
        -DCGNS_ENABLE_64BIT=ON \
        -DCMAKE_BUILD_TYPE=Release \
        -DCGNS_ENABLE_PARALLEL=ON \
        -DCMAKE_PREFIX_PATH=.../path/to/hdf5/install \
        -DHDF5_NEED_MPI=ON

the SCOPING and 64BIT options I think are good to opt-in to by default. This requires HDF5 built with -DHDF5_ENABLE_PARALLEL=ON.