[petsc-users] TS: How to implement a simple stopping criterion
Smith, Barry F.
bsmith at mcs.anl.gov
Tue Jun 4 09:54:32 CDT 2019
Looks good! Should this go into TS as TSRollBack_Basic()?
> On Jun 4, 2019, at 2:33 AM, Patrick Sanan via petsc-users <petsc-users at mcs.anl.gov> wrote:
>
> Made that change and otherwise cleaned the example up so it looks quite simple now:
> https://bitbucket.org/psanan/ts_generic_rollback_example/
>
> Am Mo., 3. Juni 2019 um 19:52 Uhr schrieb Patrick Sanan <patrick.sanan at gmail.com>:
>
>
> Am Mo., 3. Juni 2019 um 19:12 Uhr schrieb Matthew Knepley <knepley at gmail.com>:
> On Mon, Jun 3, 2019 at 12:32 PM Patrick Sanan via petsc-users <petsc-users at mcs.anl.gov> wrote:
> Thanks again for the pointers! Here's a quick and dirty experiment as a proof of concept of this, for interest:
> https://bitbucket.org/psanan/ts_generic_rollback_example/src/master/
>
> This composes an extra "last step's state" vector with the TS object, overrides ts->ops->rollback, and uses a pre-step hook to keep it up to date.
>
> This allows *any* TS implementation (which doesn't already support it) to use TSRollBack(), which I do in a post-step hook.
>
> This is cool. Why are you wrapping the Vec in a Container instead of passing it directly?
> No good reason - I was initially going to also include other data there but then realized I didn't need to.
>
> Matt
>
> Am Di., 28. Mai 2019 um 17:04 Uhr schrieb Zhang, Hong <hongzhang at anl.gov>:
> You are right that TSEvent is not suitable for this case. To stop the timestepper, I would call TSSetConvergedReason(ts,TS_CONVERGED_USER) in a PostStep function.
>
> Hong (Mr.)
>
> > On May 28, 2019, at 4:36 AM, Patrick Sanan via petsc-users <petsc-users at mcs.anl.gov> wrote:
> >
> > I'm working with/on a code which uses TSSUNDIALS, and I'd like to be able to stop the timestepper based on the value of the solution. In particular, I wish to enforce that a given concentration has not changed by more than a specified amount before stopping. Note that this is simpler than general event detection, as I'm happy stopping before the condition is satisfied and don't care about finding the point in time when the condition is satisfied exactly.
> >
> > As far as I know, PETSc's event handling interface isn't supported with the SUNDIALS implementation. (As an aside, I'd be happier using TSARKIMEX or another native timestepper, but so far haven't been able to avoid tiny timesteps).
> >
> > My question is whether the following approach has any obvious fatal flaw, and if any TS gurus have other/better/simpler ideas.
> >
> > The idea is to add my own logic, say with TSSetPreStep(), to:
> >
> > 1. Maintain the previous step's state (this is a 1d problem, so I'm not too concerned about the overhead of this)
> > 2. Check my condition, and if it's satisfied, dump the previous step's data, and use TSSetMaxTime() with the previous step's time, thus ending the solve.
> >
>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
More information about the petsc-users
mailing list