[petsc-dev] Checkpoint-restart with DMPlex objects

[Hapla Vaclav]

> On 20 Dec 2018, at 01:06, Jed Brown <jed at jedbrown.org> wrote:
> 
> Hapla Vaclav via petsc-dev <petsc-dev at 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.

I somehow forgot to reply. I meant mainly the topological and geometrical information. What fields are dumped in which stage is for me the matter of the concrete FE code. HDF5 allows to add different data at different stages to the same file. If there is something extra just for visualization purposes, it doesn't prevent one to use the same file to start the simulation over or load a checkpoint. For me it's mainly important that all reads/writes can be done in parallel and the topo/geo information is reused all the time.

> 
> 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.

Sounds good but such functionality is out of my scope for foreseeable future.

> 
> 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.


Thanks

Vaclav