[petsc-dev] TSSolve web page JED and EMIL READ THIS!

[Barry Smith]

   I note that with the current code if you run TSSolve() with TS_EXACTFINALTIME_INTERPOLATE and then another TSSolve to continue solving for later time it actually uses the "interpolated" value as the starting point for the next solve (and not the final solution of the previous TSSolve()). Is this not intended? If it is ok then we simplify the code by simply interpolating the final solution into ts->vec_sol (and hence not even save the final "solution") and simplify the code and the API. If it is suppose to restart from the previous final solution (not interpolated) then the code needs to be fixed up. 

  An alternative is to say that TSSolve() always returns the solution at a time step and require the user to call something like TSInterpolateSolution(ts,w); to get the solution at the interpolated time?


> On Feb 6, 2015, at 4:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> 
>> On Feb 6, 2015, at 12:28 PM, Mark Adams <mfadams at lbl.gov> wrote:
>> 
>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSolve.html#TSSolve
>> 
>> The TSSolve web page does not have an output parameter.  It is not clear to my why you would use TSSetSolution.  Is there any difference between using and not using TSSetSolution other than you do not need to give TSSolve u?  
> 
> 
>   This is fuzzy (even fuzzier than the fact that KSP has KSPSetSolution() or one can pass it into KSPSolve() while SNESSolve() does NOT take a solution.
> 
>   Our API here is not great:
> 
>   Normally it doesn't matter, one can pass it in either place or both places. BUT if TS_EXACTFINALTIME_INTERPOLATE is used then the u is required (this is not documented and the error checking does not give useful feedback to the user) but the user could either or not call TSSetSolution() also. The reason for this case is that TS internally wants to keep the actual final step step inside the TS object and interpolate the solution into the u provided to the user.  Note also that TSGetSolution() after solve returns the solution at the final time computed by the TSSolve() NOT the interpolated solution at the time requested by the user. This could also be confusing.
> 
>   I can document this crappy API but my instinct is too actually remove TSSetSolution() to get rid of the oddball special case and unneeded and hence confusing two ways of passing the "solution". Thus one would always pass u in the TSSolve() and normally ts->vec_sol and the u passed in would be the same except when TS_EXACTFINALTIME_INTERPOLATE is used in which u is VecDuplicated() internally (as actually happens now if the user did not previously call TSSetSolution()).  The TSGetSolution() would need/regardless does need to be documented as always returning the solution at the final time computed by the solver, not the interpolated time (even with docs this will be prone to error); could remove TSGetSolution() completely?
> 
>    Emil and Jed, what is your feedback? Any good reason to keep TSSetSolution()?
> 
>   Barry
> 
>  Another alternative is to remove the u argument to TSSolve() completely and have the user always call TSSetSolution(). Again when TS_EXACTFINALTIME_INTERPOLATE we'd duplicate that thing internally .....
> 
> 
>> 
>> Mark
>