[petsc-users] TS: How to implement a simple stopping criterion

[Patrick Sanan]

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/
> <http://www.cse.buffalo.edu/~knepley/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190603/40ebef5d/attachment.html>