Re: [petsc-dev] Checkpoint-restart with DMPlex objects
Hapla Vaclav via petsc-dev 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.
Re: [petsc-dev] MatNest and inner KSP
> On 19 Dec 2018, at 9:46 AM, Stefano Zampini wrote: > > Pierre, > > The details of the inner solvers for PCFIELDSPLIT are not known if you don’t > call PCSetUp, so the cascade approach should be preferred. OK, great! It was actually not that big of a deal to implement. Thanks, Pierre > After PCSetUp, you can access the inner solves, see e.g. > https://bitbucket.org/petsc/petsc/src/4ddd364d454d7bce974e92e0b5bd4f4516dbff02/src/ksp/pc/impls/bddc/bddc.c#lines-2715 >> On Dec 19, 2018, at 9:01 AM, Pierre Jolivet via petsc-dev >> wrote: >> >> Hello, >> I have a PCFIELDSPLIT where the fields are defined by a MATNEST >> “decomposition”. >> Right now, I am first defining the KSP of the diagonal blocks of the >> MATNEST, which are themselves PCFIELDSPLIT, then creating the Mat itself, >> and eventually I’d like to solve systems with the complete MATNEST. >> However, the KSP and PC options of the “first level" inner solvers are not >> propagated to the global outer solver. >> Can this be achieved somehow, or do I always need to set the options in the >> opposite direction (first outer solver, then inner solvers, e.g., through a >> cascade of PCFieldSplitGetSubKSP)? >> >> Thanks in advance, >> Pierre >
Re: [petsc-dev] Checkpoint-restart with DMPlex objects
Thanks Karli! That should be it. Vaclav On 18 December 2018 16:48:30 GMT+01:00, Karl Rupp wrote: > > >> >> I have not quickly found how is that "VTK ordering" defined but I >> hopefully it's a well-defined unambiguous cell-local numbering. I >will >> try to find it out soon and get back to you. > >Hope this helps: >https://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf >(page 9) > >Best regards, >Karli
Re: [petsc-dev] MatNest and inner KSP
Pierre, The details of the inner solvers for PCFIELDSPLIT are not known if you don’t call PCSetUp, so the cascade approach should be preferred. After PCSetUp, you can access the inner solves, see e.g. https://bitbucket.org/petsc/petsc/src/4ddd364d454d7bce974e92e0b5bd4f4516dbff02/src/ksp/pc/impls/bddc/bddc.c#lines-2715 > On Dec 19, 2018, at 9:01 AM, Pierre Jolivet via petsc-dev > wrote: > > Hello, > I have a PCFIELDSPLIT where the fields are defined by a MATNEST > “decomposition”. > Right now, I am first defining the KSP of the diagonal blocks of the MATNEST, > which are themselves PCFIELDSPLIT, then creating the Mat itself, and > eventually I’d like to solve systems with the complete MATNEST. > However, the KSP and PC options of the “first level" inner solvers are not > propagated to the global outer solver. > Can this be achieved somehow, or do I always need to set the options in the > opposite direction (first outer solver, then inner solvers, e.g., through a > cascade of PCFieldSplitGetSubKSP)? > > Thanks in advance, > Pierre
