I don't need this feature immediately and don't think I can devote the time for it over the next three months. I can work on this probably next year starting April. I've added it to bitbucket issues.
Shri On Dec 13, 2012, at 2:06 PM, Jed Brown wrote: > Okay, who is working on this? (Is it me?) What is the timeline? Can you add > it to bitbucket issues so we can keep track? (There is a decent amount of > work incorporating it into all the methods.) > > On Tue, Dec 11, 2012 at 5:42 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Right, providing this "list of times" as a user provided function (not as > an array of doubles) is a more general and better interface. I have no > problem with that. (Note that one's provided function could simple access > values in an array as appropriate :-), so Sean and my simple case are also > supported. > > Barry > > On Dec 10, 2012, at 11:59 PM, Shri <abhyshr at mcs.anl.gov> wrote: > > > I think Jed is right. Rather than giving a list of times, it is better to > > provide user-defined callback function (or functions?) for detecting the > > non-smoothness or hitting a time before ts->final_time. MATLAB Ode solvers > > call these discontinuities as 'EVENTS' and provide callback functions to > > detect them. http://www.mathworks.com/help/matlab/ref/ode23.html. > > > > In the power grid project that I'm involved in, there can be three > > possibilities (could be more) when the DAE integrator needs to be stopped. > > > > i) An exogenous event such as a random disturbance at a given prespecified > > time. > > ii) The removal of this disturbance at another prespecified time. (only for > > analysis) > > iii) The removal of this disturbance due to some switching (switch on/off) > > based on threshold crossing (the threshold crossing and switching action > > could be at the same time or delayed). > > iv) Some switching action due to abnormal conditions. > > > > Later on in the project, we will be passing the states from TS at the end > > of each time step to a commercial software that decides the switching logic > > and passes the switching times back to TS PostStep() interface. Thus, there > > could be a need of stopping TS based on the switching times. > > > > Another example of event detection is in circuit simulation where in the > > zero crossing of the waveform needs to be detected. > > > > I think having callback functions for 'EVENTS' would be the right approach. > > > > I recently requested for a couple of features in TS and Jed, Barry, and > > Emil kindly :) agreed > > i) The feature of hitting the exact time has been added to the adaptive > > time-step controller and can be accessed via -ts_exact_final_time > > MATCHSTEP. Note that this is not available with methods that don't use an > > adaptive controller. > > ii) TS can be stopped at any given time via TSPostStep() by calling > > TSSetConvergedReason() with the flag TS_CONVERGED_USER. > > > > Shri > > On Mon, Dec 10, 2012 at 8:36 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > I'd the ability to provide to TS a list of times at which I'd like the ODE > > integrator have exactly match that time on a time-step (that is adjust the > > delta t near that time to hit it exactly). This is something Shri needs. > > > > Is this general enough to add to the library itself? He can write an > > adaptive controller that hits any times he wants. > > > > As a library feature, I'd be more interested in having a controller that > > attempted to hit the zeros of a user-provided functional (because that > > could be used for other forms of model nonsmoothness). > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121213/3ed91320/attachment.html>
