> On Jul 31, 2017, at 5:12 AM, Lisandro Dalcin <[email protected]> wrote: > > Once I merge this PR > https://bitbucket.org/petsc/petsc/pull-requests/722/proper-support-for-successive-tssolve/diff > we will have TS{Set|Get}Max{Steps|Time}(). > > Barry asked about deprecating TSSetDuration(), but I'm not completely > sure about it. We could keep it as a supported convenience method > which calls directly TS{Set|Get}Max{Steps|Time}(), just as > TSSetInitialTimeStep() works. <sarcasm-on> I'll assume you guys are ok > with having TSSetInitialTimeStep() as a convenience method, otherwise > it would have been deprecated and eventually removed (and the ton of > examples updated) ages ago <sarcasm-off> . > > Or maybe we just need to rethink our default max_steps and max_time. > What about the following: > > * TSCreate() > max_steps = PETSC_MAX_INT > max_time = PETSC_MAX_REAL (or maybe PETSC_INFINITY? ) > > * TSSolve()/TSStep() > Error if both max_step and max time are set to unlimited.
I would only error if max_time is infinite. I think it is reasonable to say, "solve this problem to time T and I don't care how many time steps it takes". While it is not reasonable to say "integrate this equation forever". > > If we had these features in place, I would no longer consider > TSSetDuration() as a convenience method, and I would be just fine with > deprecating it. > > What do you think? > > > -- > Lisandro Dalcin > ============ > Research Scientist > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > Extreme Computing Research Center (ECRC) > King Abdullah University of Science and Technology (KAUST) > http://ecrc.kaust.edu.sa/ > > 4700 King Abdullah University of Science and Technology > al-Khawarizmi Bldg (Bldg 1), Office # 0109 > Thuwal 23955-6900, Kingdom of Saudi Arabia > http://www.kaust.edu.sa > > Office Phone: +966 12 808-0459
