[petsc-dev] Copy *SNES-struct deeply

[Barry Smith]

On Mar 4, 2013, at 6:40 AM, Johannes Lotz <lotz at stce.rwth-aachen.de> wrote:

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

   Currently there is no Clone() for the solver objects. 

   Can you just "keep" the solver object around in memory and use it again later, when needed, or do you absolutely need another copy of the solver object?

   You mention checkpoint, does this mean you want to serialize the solver object to disk and load it again later, or are you merely talking about "in memory" check pointing?

  Barry

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