Hapla Vaclav via petsc-dev <petsc-dev@mcs.anl.gov> writes: > So my overall idea (which I presented also at this year's User Meeting > in London and nobody has objected yet), is that some FE codes could > potentially use only this for both checkpointing and > viewing. Advantages would include removing the redundancy in storage > (reducing the file size) and increased interoperability with 3rd party > tools.
This is great in principle, but note that visualization files often contain diagnostic quantities like pressure, temperature, and vorticity while checkpoint files contain only state variables like density, momentum, and total energy. Although one can be derived from the other, it requires an equation of state (an arbitrarily complex constitutive model) and/or compatible derivatives, both of which are so cumbersome to provide to offline visualization that almost nobody has an appetite for it. It certainly makes sense to use the same format that can include arbitrary diagnostic quantities. I think that should be provided by an extensible Viewer filter so the caller (e.g., a TS monitor) can just call VecView and the viewer's configuration determines which diagnostic and/or state quantities to include. Note that Vec holds a reference to its DM so it can determine whether the topology is already present in the output file and link itself appropriately. There should be no assumption that there is only one DM or that it has already been written.