<div class="gmail_quote">On Sun, Oct 23, 2011 at 15:31, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On Oct 23, 2011, at 3:26 PM, Jed Brown wrote:<br>
<br>
> On Sun, Oct 23, 2011 at 15:18, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>  I wasn't thinking of anything so complicated. Just having a separate routine TSGetCurrentTime() or something to tell you the time after you called TSSolve().<br>
><br>
> But it's not the current time in the sense that it doesn't correspond to TSGetSolution or any Vec held by TS and it is not used if you call TSStep() or TSSolve(). It's a purely diagnostic point in time with no other significance. I can change the TSSolve() interface if we think of a good name for this thing.<br>

<br>
</div></div>   Wow, that is confusing then :-)   So almost every thing in the manual page is wrong?  It may include "partial time-steps"?</blockquote><div><br></div><div>In general, the steppers hold internal state that is disrupted if you change the solution. Some people like to call TSSolve() in a loop (or the "single step" version, TSStep()), but they still want high order and error control. Some methods are unstable if you change the step size too rapidly, so it's generally better to interpolate to the "exact final time" instead of adjusting the step sizes to hit it exactly at the end of a step.</div>
<div><br></div><div>I'm not completely opposed to getting rid of the interface for hitting an exact final time, and instead have users call TSInterpolate themselves, but I feel like it's a couple unnecessary lines and if we do that, then we can't make it a command line option.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">  And x is some weird shit that should not be passed back into TSSolve()?</blockquote><div><br></div><div>
I think the X argument to TSSolve() should become output-only and require TSSetSolution() if you really want to throw away internal state and start stepping from a different starting point (recognizing that this X is not normally the propagated solution).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">  What the ? Is ftime the "interpolated to" time?<br></blockquote><div><br></div><div>Yes, on return, X is the state at t=ftime. If -ts_exact_final_time, then ftime will be the exact final time (assuming the method completed), but if not -ts_exact_final_time, </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
   Barry<br>
<br>
<br>
 TSSolve - Steps the requested number of timesteps.<br>
<br>
   Collective on TS<br>
<br>
   Input Parameter:<br>
+  ts - the TS context obtained from TSCreate()<br>
-  x - the solution vector<br>
<br>
   Output Parameter:<br>
.  ftime - time of the state vector x upon completion<br>
<br>
   Level: beginner<br>
<br>
   Notes:<br>
   The final time returned by this function may be different from the time of the internally<br>
   held state accessible by TSGetSolution() and TSGetTime() because the method may have<br>
   stepped over the final time.<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>