On Mar 4, 2013, at 9:04 AM, Johannes Lotz <lotz at stce.rwth-aachen.de> wrote:
> > On 03/04/2013 02:40 PM, petsc-dev-request at mcs.anl.gov wrote: >> Message: 7 >> Date: Mon, 4 Mar 2013 07:40:16 -0600 >> From: Barry Smith<bsmith at mcs.anl.gov> >> To: For users of the development version of PETSc >> <petsc-dev at mcs.anl.gov> >> Subject: Re: [petsc-dev] Copy *SNES-struct deeply >> Message-ID:<EEBC730A-F339-482B-8727-DDA3C36ED466 at mcs.anl.gov> >> Content-Type: text/plain; charset=windows-1252 >> >> >> 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 > > Until now the checkpoint stays in memory and fits there well. > The problem for "just keeping in memory" is, that it may get changed > before we reuse it. To make it safe that we recompute the same thing later > on, we have to copy it. Why not keep the old SNES object (perhaps in an array of SNES objects) and create a new SNES object every time you need to solve something "different"? This way you'll always have the exact thing to use again whenever you need it. I am still deeply puzzled, why would you solve the "exact" same system again, surely something must be changed for the next time you solve it? Barry > > Johannes > >>> > >>> > >>> >- 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 >>> > >>> > > > -- > Dipl.-Ing. Johannes Lotz > LuFG Informatik 12 der RWTH Aachen > Software and Tools for Computational Engineering > Room 0.25, S?sterfeldstr. 65, D-52072 Aachen > Phone.: + 49 241 80 20127 > mailto: lotz at stce.rwth-aachen.de http://www.stce.rwth-aachen.de >
