<div dir="ltr">It could - some points are:<div><br></div><div>1. This is using the ts->prestep slot for the callback to store the state at the start of the step, so something would have to be done to call that logic before each step (an easy way would be to check a new flag in the TS data).</div><div><br></div><div>2. This should be "opt in" since it stores and updates an extra vector, but TSRollBack_Basic() could throw an error telling you how to activate this (again, set a new flag in the TS data) instead of the current error that TSRollBack() isn't implemented. </div><div><br></div><div>(Further simplified the example, since I don't think that the separate destroy call is needed - if I understand correctly, the composed Vec will automatically be destroyed properly with the TS, since I fixed a dangling reference).</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 4. Juni 2019 um 16:54 Uhr schrieb Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Looks good! Should this go into TS as TSRollBack_Basic()?<br>
<br>
<br>
<br>
> On Jun 4, 2019, at 2:33 AM, Patrick Sanan via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> <br>
> Made that change and otherwise cleaned the example up so it looks quite simple now: <br>
> <a href="https://bitbucket.org/psanan/ts_generic_rollback_example/" rel="noreferrer" target="_blank">https://bitbucket.org/psanan/ts_generic_rollback_example/</a><br>
> <br>
> Am Mo., 3. Juni 2019 um 19:52 Uhr schrieb Patrick Sanan <<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>>:<br>
> <br>
> <br>
> Am Mo., 3. Juni 2019 um 19:12 Uhr schrieb Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<br>
> On Mon, Jun 3, 2019 at 12:32 PM Patrick Sanan via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> Thanks again for the pointers! Here's a quick and dirty experiment as a proof of concept of this, for interest:<br>
> <a href="https://bitbucket.org/psanan/ts_generic_rollback_example/src/master/" rel="noreferrer" target="_blank">https://bitbucket.org/psanan/ts_generic_rollback_example/src/master/</a><br>
> <br>
> 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.<br>
> <br>
> This allows *any* TS implementation (which doesn't already support it) to use TSRollBack(), which I do in a post-step hook.<br>
> <br>
> This is cool. Why are you wrapping the Vec in a Container instead of passing it directly?<br>
> No good reason - I was initially going to also include other data there but then realized I didn't need to. <br>
> <br>
> Matt<br>
> <br>
> Am Di., 28. Mai 2019 um 17:04 Uhr schrieb Zhang, Hong <<a href="mailto:hongzhang@anl.gov" target="_blank">hongzhang@anl.gov</a>>:<br>
> 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.<br>
> <br>
> Hong (Mr.)<br>
> <br>
> > On May 28, 2019, at 4:36 AM, Patrick Sanan via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> > <br>
> > 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.<br>
> > <br>
> > 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).<br>
> > <br>
> > My question is whether the following approach has any obvious fatal flaw, and if any TS gurus have other/better/simpler ideas.<br>
> > <br>
> > The idea is to add my own logic, say with TSSetPreStep(), to:<br>
> > <br>
> > 1. Maintain the previous step's state (this is a 1d problem, so I'm not too concerned about the overhead of this)<br>
> > 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.<br>
> > <br>
> <br>
> <br>
> <br>
> -- <br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
<br>
</blockquote></div>