You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Luc Maisonobe (JIRA)" <ji...@apache.org> on 2011/01/18 21:53:45 UTC
[jira] Created: (MATH-484) events detection in ODE solvers is too
complex and not robust
events detection in ODE solvers is too complex and not robust
-------------------------------------------------------------
Key: MATH-484
URL: https://issues.apache.org/jira/browse/MATH-484
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Reporter: Luc Maisonobe
Assignee: Luc Maisonobe
Fix For: 2.2
All ODE solvers support multiple events detection since a long time. Events are specified by users by implementing the EventHandler interface. Events occur when the g(t, y) function evaluates to 0. When an event occurs, the solver step is shortened to make sure the event is located at the end of the step, and the event is triggered by calling the eventOccurred method in the user defined implementation class. Depending on the return value of this method, integration can continue, it can be stopped, or the state vector can be reset.
Some ODE solvers are adaptive step size solvers. They can modify step size to match an integration error setting, increasing step size when error is low (thus reducing computing costs) or reducing step size when error is high (thus fulfilling accuracy requirements).
The step adaptations due to events on one side and due to adaptive step size solvers are quite intricate by now, due to numerous fixes (MATH-161, MATH-213, MATH-322, MATH-358, MATH-421 and also during standard maintenance - see for example r781157). The code is very difficult to maintain. It seems each bug fix introduces new bugs (r781157/MATH-322) or tighten the link between adaptive step size and event detection (MATH-388/r927202).
A new bug discovered recently on an external library using a slightly modified version of this code could not be retroffitted into commons-math, despite the same problem is present. At the beginning of EventState.evaluateStep, the initial step may be exactly 0 thus preventing root solving, but preventing this size to drop to 0 would reopen MATH-388. I could not fix both bugs at the same time.
So it is now time to untangle events detection and adaptive step size, simplify code, and remove some inefficiency (event root solving is always done twice, once before step truncation and another time after truncation, of course with slightly different results, events shortened steps induce high computation load until the integrator recovers its optimal pace again, steps are rejected even when the event does not requires it ...).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-484) events detection in ODE solvers is too
complex and not robust
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe resolved MATH-484.
--------------------------------
Resolution: Fixed
fixed in subversion repository as of r1070498 for branch 2.X and r1070499 for trunk
> events detection in ODE solvers is too complex and not robust
> -------------------------------------------------------------
>
> Key: MATH-484
> URL: https://issues.apache.org/jira/browse/MATH-484
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Luc Maisonobe
> Assignee: Luc Maisonobe
> Fix For: 2.2
>
>
> All ODE solvers support multiple events detection since a long time. Events are specified by users by implementing the EventHandler interface. Events occur when the g(t, y) function evaluates to 0. When an event occurs, the solver step is shortened to make sure the event is located at the end of the step, and the event is triggered by calling the eventOccurred method in the user defined implementation class. Depending on the return value of this method, integration can continue, it can be stopped, or the state vector can be reset.
> Some ODE solvers are adaptive step size solvers. They can modify step size to match an integration error setting, increasing step size when error is low (thus reducing computing costs) or reducing step size when error is high (thus fulfilling accuracy requirements).
> The step adaptations due to events on one side and due to adaptive step size solvers are quite intricate by now, due to numerous fixes (MATH-161, MATH-213, MATH-322, MATH-358, MATH-421 and also during standard maintenance - see for example r781157). The code is very difficult to maintain. It seems each bug fix introduces new bugs (r781157/MATH-322) or tighten the link between adaptive step size and event detection (MATH-388/r927202).
> A new bug discovered recently on an external library using a slightly modified version of this code could not be retroffitted into commons-math, despite the same problem is present. At the beginning of EventState.evaluateStep, the initial step may be exactly 0 thus preventing root solving, but preventing this size to drop to 0 would reopen MATH-388. I could not fix both bugs at the same time.
> So it is now time to untangle events detection and adaptive step size, simplify code, and remove some inefficiency (event root solving is always done twice, once before step truncation and another time after truncation, of course with slightly different results, events shortened steps induce high computation load until the integrator recovers its optimal pace again, steps are rejected even when the event does not requires it ...).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MATH-484) events detection in ODE solvers is too
complex and not robust
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe closed MATH-484.
------------------------------
Closing issue as it was included in version 2.2, which has been released
> events detection in ODE solvers is too complex and not robust
> -------------------------------------------------------------
>
> Key: MATH-484
> URL: https://issues.apache.org/jira/browse/MATH-484
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Luc Maisonobe
> Assignee: Luc Maisonobe
> Fix For: 2.2
>
>
> All ODE solvers support multiple events detection since a long time. Events are specified by users by implementing the EventHandler interface. Events occur when the g(t, y) function evaluates to 0. When an event occurs, the solver step is shortened to make sure the event is located at the end of the step, and the event is triggered by calling the eventOccurred method in the user defined implementation class. Depending on the return value of this method, integration can continue, it can be stopped, or the state vector can be reset.
> Some ODE solvers are adaptive step size solvers. They can modify step size to match an integration error setting, increasing step size when error is low (thus reducing computing costs) or reducing step size when error is high (thus fulfilling accuracy requirements).
> The step adaptations due to events on one side and due to adaptive step size solvers are quite intricate by now, due to numerous fixes (MATH-161, MATH-213, MATH-322, MATH-358, MATH-421 and also during standard maintenance - see for example r781157). The code is very difficult to maintain. It seems each bug fix introduces new bugs (r781157/MATH-322) or tighten the link between adaptive step size and event detection (MATH-388/r927202).
> A new bug discovered recently on an external library using a slightly modified version of this code could not be retroffitted into commons-math, despite the same problem is present. At the beginning of EventState.evaluateStep, the initial step may be exactly 0 thus preventing root solving, but preventing this size to drop to 0 would reopen MATH-388. I could not fix both bugs at the same time.
> So it is now time to untangle events detection and adaptive step size, simplify code, and remove some inefficiency (event root solving is always done twice, once before step truncation and another time after truncation, of course with slightly different results, events shortened steps induce high computation load until the integrator recovers its optimal pace again, steps are rejected even when the event does not requires it ...).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MATH-484) events detection in ODE solvers is too
complex and not robust
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe resolved MATH-484.
--------------------------------
Resolution: Fixed
fixed in subversion repository as of r1061507 for branch 2.X and as of r1061508 for trunk
> events detection in ODE solvers is too complex and not robust
> -------------------------------------------------------------
>
> Key: MATH-484
> URL: https://issues.apache.org/jira/browse/MATH-484
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Luc Maisonobe
> Assignee: Luc Maisonobe
> Fix For: 2.2
>
>
> All ODE solvers support multiple events detection since a long time. Events are specified by users by implementing the EventHandler interface. Events occur when the g(t, y) function evaluates to 0. When an event occurs, the solver step is shortened to make sure the event is located at the end of the step, and the event is triggered by calling the eventOccurred method in the user defined implementation class. Depending on the return value of this method, integration can continue, it can be stopped, or the state vector can be reset.
> Some ODE solvers are adaptive step size solvers. They can modify step size to match an integration error setting, increasing step size when error is low (thus reducing computing costs) or reducing step size when error is high (thus fulfilling accuracy requirements).
> The step adaptations due to events on one side and due to adaptive step size solvers are quite intricate by now, due to numerous fixes (MATH-161, MATH-213, MATH-322, MATH-358, MATH-421 and also during standard maintenance - see for example r781157). The code is very difficult to maintain. It seems each bug fix introduces new bugs (r781157/MATH-322) or tighten the link between adaptive step size and event detection (MATH-388/r927202).
> A new bug discovered recently on an external library using a slightly modified version of this code could not be retroffitted into commons-math, despite the same problem is present. At the beginning of EventState.evaluateStep, the initial step may be exactly 0 thus preventing root solving, but preventing this size to drop to 0 would reopen MATH-388. I could not fix both bugs at the same time.
> So it is now time to untangle events detection and adaptive step size, simplify code, and remove some inefficiency (event root solving is always done twice, once before step truncation and another time after truncation, of course with slightly different results, events shortened steps induce high computation load until the integrator recovers its optimal pace again, steps are rejected even when the event does not requires it ...).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MATH-484) events detection in ODE solvers is too
complex and not robust
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe reopened MATH-484:
--------------------------------
The fix introduced in r1061507 fails in several cases. If several events of the same type occur within a single long step, only the first one is triggered. If several events of different types occur during a backward integration, they are triggered in the wrong order (i.e. they are triggered in forward occurrence time order instead of backward).
> events detection in ODE solvers is too complex and not robust
> -------------------------------------------------------------
>
> Key: MATH-484
> URL: https://issues.apache.org/jira/browse/MATH-484
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Luc Maisonobe
> Assignee: Luc Maisonobe
> Fix For: 2.2
>
>
> All ODE solvers support multiple events detection since a long time. Events are specified by users by implementing the EventHandler interface. Events occur when the g(t, y) function evaluates to 0. When an event occurs, the solver step is shortened to make sure the event is located at the end of the step, and the event is triggered by calling the eventOccurred method in the user defined implementation class. Depending on the return value of this method, integration can continue, it can be stopped, or the state vector can be reset.
> Some ODE solvers are adaptive step size solvers. They can modify step size to match an integration error setting, increasing step size when error is low (thus reducing computing costs) or reducing step size when error is high (thus fulfilling accuracy requirements).
> The step adaptations due to events on one side and due to adaptive step size solvers are quite intricate by now, due to numerous fixes (MATH-161, MATH-213, MATH-322, MATH-358, MATH-421 and also during standard maintenance - see for example r781157). The code is very difficult to maintain. It seems each bug fix introduces new bugs (r781157/MATH-322) or tighten the link between adaptive step size and event detection (MATH-388/r927202).
> A new bug discovered recently on an external library using a slightly modified version of this code could not be retroffitted into commons-math, despite the same problem is present. At the beginning of EventState.evaluateStep, the initial step may be exactly 0 thus preventing root solving, but preventing this size to drop to 0 would reopen MATH-388. I could not fix both bugs at the same time.
> So it is now time to untangle events detection and adaptive step size, simplify code, and remove some inefficiency (event root solving is always done twice, once before step truncation and another time after truncation, of course with slightly different results, events shortened steps induce high computation load until the integrator recovers its optimal pace again, steps are rejected even when the event does not requires it ...).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira