Yup, implemented that with DM.  Works as desired.  Thanks.

-gideon

> On Feb 13, 2017, at 8:03 AM, Matthew Knepley <[email protected]> wrote:
> 
> On Sun, Feb 12, 2017 at 3:21 PM, Barry Smith <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> > On Feb 12, 2017, at 11:30 AM, Gideon Simpson <[email protected] 
> > <mailto:[email protected]>> wrote:
> >
> > I’ve begun working on implementing a projected time stepping method for 
> > solving y’ = f(y), where g(y(t)) is an invariant of the flow.  Per a 
> > previous email exchange, it was suggested that I use TSSetPostStep to 
> > perform the projection routine, calling TSGetSolution obtain the current 
> > iterate, which will be corrected with the projection.  However, I noticed 
> > two things:
> >
> > 1.  The documentation for TSGetSolution says "This vector not changed until 
> > the solution at the next timestep has been calculated.”  Does that mean 
> > that if I make a change to the solution in a PostStep function, it won’t be 
> > captured until the next step?
> 
>    No.
> 
> >  What happens at the final time step?
> 
>    Your function should still get called.
> 
> >
> > 2.  The projection is nonlinear, requiring the use of a SNES.  I had 
> > originally thought that I would create/configure/destroy the SNES within 
> > the main routine of the code, and pass this to the PostStep through a user 
> > data structure.  However, the TSSetPostStep function seems to only take 
> > functions which are exclusively functions of the TS.  Likewise, I would 
> > need to create a residual vector, r, for the SNESSetFunction.  Is there a 
> > way to pass these data structures, so that they can be reused. or would 
> > they have to be created/destroyed within the PostStep function at each 
> > iterate?  How costly would that be?
> 
>    After you create the SNES and the TS call PetscObjectCompose() to attach 
> the SNES to the TS then inside your post-step you can use PetscObjectQuery() 
> or if you want to pass in more than a SNES use PetscContainerCreate().
> 
> An alternative to what Barry suggests, which will definitely work, is to use 
> the DM.
> 
>   DMCreateShell(comm, &dm);
>   DMSetApplicationContext(dm, ctx);
>   TSSetDM(ts, dm);
> 
> In your function
> 
>   TSGetDM(ts, &dm);
>   DMGetApplicationContext(dm, &ctx);
> 
> I prefer this to the Container route.
> 
>   Thanks,
> 
>      Matt
>  
> >
> >
> > -gideon
> >
> 
> 
> 
> 
> -- 
> 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

Reply via email to