On Sun, Oct 23, 2011 at 8:31 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Oct 23, 2011, at 3:26 PM, Jed Brown wrote: > > > On Sun, Oct 23, 2011 at 15:18, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 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(). > > > > 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. > > Wow, that is confusing then :-) So almost every thing in the manual > page is wrong? It may include "partial time-steps"? And x is some weird > shit that should not be passed back into TSSolve()? What the ? Is ftime the > "interpolated to" time? > This seems like a confusion between the continuum level and the discrete level. Matt > Barry > > > TSSolve - Steps the requested number of timesteps. > > Collective on TS > > Input Parameter: > + ts - the TS context obtained from TSCreate() > - x - the solution vector > > Output Parameter: > . ftime - time of the state vector x upon completion > > Level: beginner > > Notes: > The final time returned by this function may be different from the time > of the internally > held state accessible by TSGetSolution() and TSGetTime() because the > method may have > stepped over the final time. > > > > > > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111023/94bbe475/attachment.html>
