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

Patrick Sanan patrick.sanan at gmail.com
Tue Jun 4 02:33:35 CDT 2019


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


More information about the petsc-users mailing list