> On Aug 1, 2017, at 3:29 AM, Lisandro Dalcin <[email protected]> wrote: > > On 31 July 2017 at 19:50, Barry Smith <[email protected]> wrote: >> >>> 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". >> > > But IMHO it is also reasonable to use -ts_adapt_type none > -ts_max_steps <n> -ts_dt <dt>, without specifying a maximum time. If > you don't set the final time, the previous example will fail despite > the solver not integrating forever but stopping after <n> steps. My > proposal gives users maximum freedom about how to terminate the > integration. Is there anything wrong with my reasoning?
No you're reasoning is ok. But I don't really understand why one would do -ts_adapt_type none -ts_max_steps <n> -ts_dt <dt> That is just an obscure way of setting a final time; better to have the user set the final time. It is clearer to both them and the code what they are doing. If they forget to set adapt none then they could end up with any strange final time they had no control over. Barry > > > -- > 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
