[petsc-users] [TimeStepping] Eventhandler

Tue Feb 5 11:11:51 CST 2019

Ok, I'll add two things; (i) a TSEventSetPostEventTimeStep(), and (ii) a flag that allows the user to select either the previous time-step or the original time-step. For most users, the flag should suffice. For users who know how the dynamics would behave after the event, they can set the appropriate time-step with TSEventSetPostEventTimeStep().

>>>   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.

Once the event is located the system equations get modified that may change the system behavior. As such, the current approach was to use
a conservative smaller time-step. With the above additions, a larger time-step will be allowed.

Shri

>>>-----Original Message-----
>>>From: Smith, Barry F. <bsmith at mcs.anl.gov>
>>>Sent: Monday, February 4, 2019 9:53 PM
>>>To: Abhyankar, Shrirang G <shrirang.abhyankar at pnnl.gov>
>>>Cc: Huck, Moritz <Moritz.Huck at rwth-aachen.de>; PETSc users list <petsc-
>>>users at mcs.anl.gov>
>>>Subject: 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
>>>>>>>>>
>>>>