> On Aug 1, 2017, at 7:26 PM, Emil Constantinescu <[email protected]> wrote:
> 
> On 8/1/17 2:16 PM, Barry Smith wrote:
>>> 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.
> 
> Well, there are situations in which you want to do a certain number of fixed 
> steps.

   Really, I think users ALWAYS want to get to a particular time; it is only 
due to flaws in the software that they may think they need to (or due need to) 
control things with a fixed number of steps.


> Moreover, there are methods that do not have adaptors so setting the exact 
> final time will not work. I guess one can set a final time that exceeds n*dt 
> by some margin. In the end I don't think it really matters because none would 
> be intuitive for all use cases. I think it would be useful to document it 
> really well (with use-case examples). I don't know how to do that so the 
> users find it easy and easy to understand.
> 
> Emil
> 
>>   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

Reply via email to