Open BenWibking opened 1 year ago
@pgrete @forrestglines any other thoughts on this?
This should be fairly straightforward and I don't think that we'd need xdmf output in the beginning (until someone needs it).
This should be fairly straightforward and I don't think that we'd need xdmf output in the beginning (until someone needs it).
That's true. Unfortunately, I need xdmf output :/
This should be fairly straightforward and I don't think that we'd need xdmf output in the beginning (until someone needs it).
That's true. Unfortunately, I need xdmf output :/
For processing in ParaView/Visit?
Writing an XDMF file should also be "straightforward" for this kind of data though I had my troubles reading the format specs in the past.
This should be fairly straightforward and I don't think that we'd need xdmf output in the beginning (until someone needs it).
That's true. Unfortunately, I need xdmf output :/
For processing in ParaView/Visit?
Writing an XDMF file should also be "straightforward" for this kind of data though I had my troubles reading the format specs in the past.
Yes.
It should be :)
It would be very useful to have a built-in 2D slice output that would save the simulation data along a plane at either i) the simulation-native resolution in XDMF/HDF5 format or ii) fixed-grid resolution in some simple binary format.
It should also be relatively straightforward to implement, at least in Cartesian coordinates (except maybe figuring out the XDMF metadata...).
Ascent can compute and save slices in Blueprint HDF5 format, but for reasons we haven't determined, it is extremely slow (cost can be 10s/100s of simulation timesteps to save one slice).