[petsc-users] [TimeStepping] Eventhandler

Tue Feb 5 06:19:11 CST 2019

@Shri 
The system is very stiff, but the stiffness is handled well by ARKIMEX.

I'am using PETSc 3.10. (I cannot use 3.10.3 at the moment due to compatibilty with a third library), no special options for TS
Writing an MWE might take some time, if it is necessary I will write something at the weekend.

@Barry
A third option for 2) would be to let the adapator start from the event time, this might be usefull if a user doesnt know a good time step after the event.

Best Regards
Moritz
________________________________________
Von: Smith, Barry F. <bsmith at mcs.anl.gov>
Gesendet: Dienstag, 5. Februar 2019 04:53
An: Abhyankar, Shrirang G
Cc: Huck, Moritz; PETSc users list
Betreff: Re: [petsc-users] [TimeStepping] Eventhandler

  Ahh, thanks, for some reason I didn't find that.

  Based on Moritz's code example perhaps we need to add one or more TSEvent methods. The simplest thing would be to have a routine to allow reseting the "base" timestep that is used 1) within the TSEvent search and 2) after an event is found. Something like

   TSEventSetBaseTimeStep()

of course Base is a terrible name but I'm not sure what else to use.

   This is, of course, not a perfect solution because the user would have to know what value to use (though they could set it using values from TSGetTimeStep().)

   As an alternative or additional feature there could be a flag so that TSEvent proceeds with the current time step for 1) and 2) not the timestep_orig?

   It does seem absurd for the code to revert to a tiny step in dealing with the Event if the time stepper is happy with a much much large time-step for solving the ODE at that time range.

  Barry

> On Feb 4, 2019, at 7:48 PM, Abhyankar, Shrirang G <shrirang.abhyankar at pnnl.gov> wrote:
>
> It's stashed in event->timestep_orig. At the beginning of the TSEventHandler there is this code that sets timestep_orig.
>
> if (event->status == TSEVENT_NONE) {
>    if (ts->steps == 1) /* After first successful step */
>      event->timestep_orig = ts->ptime - ts->ptime_prev;
>
> After the step is resynchronized after event location, the next step chosen is the min. of the time-step before the event interval (event->timestep_prev) and the original step.
>
> if (event->status == TSEVENT_RESET_NEXTSTEP) {
>    /* Restore time step */
>    dt = PetscMin(event->timestep_orig,event->timestep_prev);
>    ierr = TSSetTimeStep(ts,dt);CHKERRQ(ierr);
>
> So, if the event->timestep_prev is smaller than event->timestep_orig (which could be possibly with adaptivity ON, it is allowed)
>
> Shri
>
> -----Original Message-----
> From: petsc-users <petsc-users-bounces at mcs.anl.gov> On Behalf Of Smith, Barry F. via petsc-users
> Sent: Monday, February 4, 2019 4:37 PM
> To: Huck, Moritz <Moritz.Huck at rwth-aachen.de>
> Cc: Abhyankar, Shrirang G <shrirang.abhyankar at pnnl.gov>; petsc-users at mcs.anl.gov
> Subject: Re: [petsc-users] [TimeStepping] Eventhandler
>
>>
>> Is there any reason you'd like to use the last time step? We used the initial time-step (which is assumed to be small) so as (a) to minimize any numerical issues that may be caused by a large last time-step, and (b) to not miss any ensuing events that may be triggered by the discontinuity.
>>
>> Shri
>
>  Shri
>
>     How do you get access to this initial time-step later in the run? TSSetTimeStep() sets the value ts->time_step but I don't see any place where that initial timestep is stashed so could be used later.
>
>   Thanks
>
>    Barry
>
>
>> On Feb 4, 2019, at 1:56 AM, Huck, Moritz via petsc-users <petsc-users at mcs.anl.gov> wrote:
>>
>> Hi,
>> yes there is one.
>> My system has a set of very different time contants.
>> At some events the fast one may be fully developped and only the slower ones are of concern after the event (depending on the postevent).
>> If the last step is not an option, setting it manually might be helpfull since I generall know which timeconstants will be relevant (TSSetTime step seems not to have an effect during the postevent call).
>>
>> Moritz
>> ________________________________________
>> Von: Abhyankar, Shrirang G <shrirang.abhyankar at pnnl.gov>
>> Gesendet: Montag, 4. Februar 2019 05:09:24
>> An: Huck, Moritz; Zhang, Hong
>> Betreff: RE: [petsc-users] [TimeStepping] Eventhandler
>>
>> Is there any reason you'd like to use the last time step? We used the initial time-step (which is assumed to be small) so as (a) to minimize any numerical issues that may be caused by a large last time-step, and (b) to not miss any ensuing events that may be triggered by the discontinuity.
>>
>> Shri
>>
>> -----Original Message-----
>> From: petsc-users <petsc-users-bounces at mcs.anl.gov> On Behalf Of
>> Moritz Huck via petsc-users
>> Sent: Sunday, February 3, 2019 10:45 AM
>> To: Zhang, Hong <hongzhang at anl.gov>
>> Cc: petsc-users at mcs.anl.gov
>> Subject: Re: [petsc-users] [TimeStepping] Eventhandler
>>
>> Hi,
>>
>> I see I am sorry, I misinterpreted the output -ts_adapt_monitor.
>>
>> You are right point 2 is not an issue.
>>
>> I there a way to let the time stepping continue with the last time step instead of the initial time step?
>>
>> Best Regards,
>>
>> Moritz
>>
>> Am 03.02.19 um 17:04 schrieb Zhang, Hong:
>>> ex40 seems to work fine. Here is the output with -ts_monitor -ts_event_monitor -ts_dt 0.01 :
>>>
>>> 8 TS dt 0.5 time 3.11
>>> 9 TS dt 0.5 time 3.61
>>> TSEvent: iter 0 - Event 0 interval detected [3.61 - 4.11]
>>> 9 TS dt 0.467955 time 3.61 (r)
>>> TSEvent: iter 1 - Stepping forward as no event detected in interval
>>> [3.61 - 4.07796]
>>> 10 TS dt 0.00365179 time 4.07796
>>> TSEvent: iter 2 - Stepping forward as no event detected in interval
>>> [4.07796 - 4.08161]
>>> 11 TS dt 2.5403e-05 time 4.08161
>>> TSEvent: Event 0 zero crossing at time 4.08163 located in 3
>>> iterations Ball hit the ground at t =  4.08 seconds
>>> 12 TS dt 0.0283673 time 4.08163
>>> 13 TS dt 0.01 time 4.11
>>> 14 TS dt 0.1 time 4.12
>>>
>>> The event occurs during the step [3.61- 4.11]. After the event is located at 4.08163, the next step after the event should be 4.11-4.08163 = 0.02837 (see 12 TS) to complete the original step. After 4.11, the specified initial stepsize dt=0.01 will be used.
>>>
>>> Hong (Mr.)
>>>
>>>> On Feb 3, 2019, at 6:08 AM, Moritz Huck via petsc-users <petsc-users at mcs.anl.gov> wrote:
>>>>
>>>> Hi Barry,
>>>>
>>>> src/ts/examples/tutorials/ex40.c (run with ARKIMEX3 and initial dt=1e-2) has the same behavior:
>>>>
>>>> TSEvent: iter 0 - Event 0 interval detected [3.61 - 4.11]
>>>> TSEvent: iter 1 - Stepping forward as no event detected in interval
>>>> [3.61 - 4.07796]
>>>> TSEvent: iter 2 - Stepping forward as no event detected in interval
>>>> [4.07796 - 4.08161]
>>>> TSEvent: Event 0 zero crossing at time 4.08163 located in 3
>>>> iterations Ball hit the ground at t =  4.08 seconds
>>>>      TSAdapt basic arkimex 0:3 step  13 accepted t=4.11       + 1.000e-02 dt=1.000e-01  wlte=    0  wltea=   -1 wlter=   -1
>>>>
>>>>      TSAdapt basic arkimex 0:3 step  14 accepted t=4.12       + 1.000e-01 dt=5.000e-01  wlte=    0  wltea=   -1 wlter=   -1
>>>>
>>>> It continues at the end of the "event interval" with the initial timestep.
>>>>
>>>> Best Regards,
>>>>
>>>> Moritz
>>>>
>>>>
>>>>
>>>>
>>>> Am 03.02.19 um 02:43 schrieb Smith, Barry F.:
>>>>>> On Feb 2, 2019, at 12:08 PM, Moritz Huck via petsc-users <petsc-users at mcs.anl.gov> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> I am trying to use SetEventHandler.
>>>>>> I hav eencountered two "problems":
>>>>>>
>>>>>> 1. after an event is encountered the next time step is needlessly small (h=1e-6), even if a don't change anything in the function (for testing).
>>>>>>
>>>>>>
>>>>>> 2. the integration does not continue at the event encounter e.g.
>>>>>> my eventfunction is g(t,u)=t-1, the event is found in the step
>>>>>> from t=
>>>>>> 0.9 to 1.1 at tevent=1 but the next step is not 1+dt but it is 1.1
>>>>>> + dt I would expect the next step to be 1.+dt
>>>>>     Hmm, this sounds like it could be an error. Could you send us a simple code that exhibits it?
>>>>>
>>>>>   Thanks
>>>>>
>>>>>   Barry
>>>>>
>>>>>> Best Regards,
>>>>>> Moritz
>>>>>>
>