Under certain circumstances, the way that analytical controls are currently discretized onto the time grid may lead to numerical instabilities. This happens in particular for flattop update shapes with a very quick switch-on. In this case, the internal sampling on the intervals of the time grid that is being used inside krotov leads to a zig-zag around the "flat" values 1.0 after the switch-on.
The solution (as described in the notebook) is to sample analytical controls on the time grid interval midpoints first, and then average those exact values onto the time grid points. Since averaging (as opposed to the inverse "un-averaging") is numerically safe, we can guarantee numerically stable pulses this way.
In practice, for the current krotov 1.1.0, any attempt to use an update shape that runs into this problem to a significant degree would trigger a ValueError due to the update shape going over its maximum allowed value of 1.0 after conversion to the midpoints. @zachmanson (U Windsor) reported such an error via private communication.
Under certain circumstances, the way that analytical controls are currently discretized onto the time grid may lead to numerical instabilities. This happens in particular for flattop update shapes with a very quick switch-on. In this case, the internal sampling on the intervals of the time grid that is being used inside
krotov
leads to a zig-zag around the "flat" values 1.0 after the switch-on.See the attached notebook "Numerical instabilities in Krotov's method due to pulse discretization" for details.
The solution (as described in the notebook) is to sample analytical controls on the time grid interval midpoints first, and then average those exact values onto the time grid points. Since averaging (as opposed to the inverse "un-averaging") is numerically safe, we can guarantee numerically stable pulses this way.
In practice, for the current
krotov 1.1.0
, any attempt to use an update shape that runs into this problem to a significant degree would trigger aValueError
due to the update shape going over its maximum allowed value of 1.0 after conversion to the midpoints. @zachmanson (U Windsor) reported such an error via private communication.