Skip to main content
Edit to add information specific to problem.
Source Link
Geoff Oxberry
  • 30.4k
  • 9
  • 65
  • 130

You'll have to describe what you want to do in more detailEDIT: No, that process will not be compatible with any adaptive time-stepper. It's not deterministic, and even for non-adaptive ODE solvers, your proposed process will degrade the accuracy of your solution.


You'll have to describe what you want to do in more detail.

In general, changing a parameter changes the equations you want to solve. If your parameter changes in a smooth (infinitely continuously differentiable, all derivatives bounded over your interval of integration) fashion, depending on this "non-differential equation rule", it's probably better to figure out how to query an update as part of your right-hand side function evaluation (and Jacobian function evaluation).

If it does not change in a smooth fashion, it depends on how many bounded, continuous derivatives you have. In general, differential equation solvers use interpolating polynomials to solve approximately differential equations, and the error term for a method of order $k$ is usually related to the derivative of order $k+1$. If you have bounded, continuous derivatives up to order $k + 1$, then you can use a method of up to order $k$. If you have no continuous derivatives, you have to use special methods that have low orders of convergence.

What will probably happen if you try to kludge in something like you're proposing is that the integrator will restart itself repeatedly, which will be inefficient, and probably inaccurate. I don't think that subclassing the object-oriented version of odeint will rectify the problem because as I've described above, the problem is a fundamental numerical analysis issue.

You'll have to describe what you want to do in more detail.

In general, changing a parameter changes the equations you want to solve. If your parameter changes in a smooth (infinitely continuously differentiable, all derivatives bounded over your interval of integration) fashion, depending on this "non-differential equation rule", it's probably better to figure out how to query an update as part of your right-hand side function evaluation (and Jacobian function evaluation).

If it does not change in a smooth fashion, it depends on how many bounded, continuous derivatives you have. In general, differential equation solvers use interpolating polynomials to solve approximately differential equations, and the error term for a method of order $k$ is usually related to the derivative of order $k+1$. If you have bounded, continuous derivatives up to order $k + 1$, then you can use a method of up to order $k$. If you have no continuous derivatives, you have to use special methods that have low orders of convergence.

What will probably happen if you try to kludge in something like you're proposing is that the integrator will restart itself repeatedly, which will be inefficient, and probably inaccurate. I don't think that subclassing the object-oriented version of odeint will rectify the problem because as I've described above, the problem is a fundamental numerical analysis issue.

EDIT: No, that process will not be compatible with any adaptive time-stepper. It's not deterministic, and even for non-adaptive ODE solvers, your proposed process will degrade the accuracy of your solution.


You'll have to describe what you want to do in more detail.

In general, changing a parameter changes the equations you want to solve. If your parameter changes in a smooth (infinitely continuously differentiable, all derivatives bounded over your interval of integration) fashion, depending on this "non-differential equation rule", it's probably better to figure out how to query an update as part of your right-hand side function evaluation (and Jacobian function evaluation).

If it does not change in a smooth fashion, it depends on how many bounded, continuous derivatives you have. In general, differential equation solvers use interpolating polynomials to solve approximately differential equations, and the error term for a method of order $k$ is usually related to the derivative of order $k+1$. If you have bounded, continuous derivatives up to order $k + 1$, then you can use a method of up to order $k$. If you have no continuous derivatives, you have to use special methods that have low orders of convergence.

What will probably happen if you try to kludge in something like you're proposing is that the integrator will restart itself repeatedly, which will be inefficient, and probably inaccurate. I don't think that subclassing the object-oriented version of odeint will rectify the problem because as I've described above, the problem is a fundamental numerical analysis issue.

Source Link
Geoff Oxberry
  • 30.4k
  • 9
  • 65
  • 130

You'll have to describe what you want to do in more detail.

In general, changing a parameter changes the equations you want to solve. If your parameter changes in a smooth (infinitely continuously differentiable, all derivatives bounded over your interval of integration) fashion, depending on this "non-differential equation rule", it's probably better to figure out how to query an update as part of your right-hand side function evaluation (and Jacobian function evaluation).

If it does not change in a smooth fashion, it depends on how many bounded, continuous derivatives you have. In general, differential equation solvers use interpolating polynomials to solve approximately differential equations, and the error term for a method of order $k$ is usually related to the derivative of order $k+1$. If you have bounded, continuous derivatives up to order $k + 1$, then you can use a method of up to order $k$. If you have no continuous derivatives, you have to use special methods that have low orders of convergence.

What will probably happen if you try to kludge in something like you're proposing is that the integrator will restart itself repeatedly, which will be inefficient, and probably inaccurate. I don't think that subclassing the object-oriented version of odeint will rectify the problem because as I've described above, the problem is a fundamental numerical analysis issue.