[petsc-dev] Copy *SNES-struct deeply

[Johannes Lotz]

Ok. Appendix:

just to make our use case clear --

we need to solve the same nonlinear system completely out of the context 
the original system was solved. That means we have to copy ALL data 
needed for that.

I.e. we need to save a checkpoint that enables us to re-run exactly the 
same piece of code (nonlinear system solve) as often as we want -- 
regardless of what happens after the original execution of the nonlinear 
solver and regardless of what happens to the original snes-object. Of 
cource we stick in the same initial x and the same right hand side b 
during the re-run. And we additionally assume the MPI-world to be still 
intact.

I don't know if there are other use cases requiring such a 
functionality. But the application of algorithmic (or automatic) 
differentiation onto petsc (that is what we're working on) will require 
checkpoints on and on again.

So until now -- as I understood -- there's no such Clone()-routine, 
which is fine -- we will have to deal with this contraint. Just wanted 
to be sure to not have missed sth. ...


- Johannes

On 02/28/2013 01:41 PM, Matthew Knepley wrote:
> On Thu, Feb 28, 2013 at 7:10 AM, Jed Brown <jedbrown at mcs.anl.gov
> <mailto:jedbrown at mcs.anl.gov>> wrote:
>
>
>     On Thu, Feb 28, 2013 at 6:50 AM, Matthew Knepley
>     <knepley at gmail.com <mailto:knepley at gmail.com>> wrote:
>
>         Ah, its specialized:
>
>         https://bitbucket.org/petsc/petsc-dev/src/923de80728797e2783dffed96365fada710347b8/include/petscdmplex.h?at=default#cl-23
>
>         Is there an objection to me promoting this?
>
>
>     Matt, your current implementation is sort of a mix of shallow
>     (with respect to private DM_Plex stuff) clone and deep/rebuilt
>     (with respect to DM stuff like defaultSection). I think it's worth
>     making consistent, but safe sharing semantics are tricky to
>     specify. I think DMDA will be somewhat involved regardless of the
>     desired semantics.
>
>
> I think that was justified when PetscSection was just considered data
> like PetscLayout. However, now that it
> is an object, we should reconsider.
>
> Unfortunately, I think sharing the default section between clone could
> be very error prone. I am currently using
> Clone() to share the large mesh data structures in the back end, but
> do not want any sharing of the sections. I
> think this would be the common use case.
>
>     Matt
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener