#23 Making demos faster

[Burkhard Schmidt]

Observation: Few of the demo examples taking most of the time. Goal should be to reduce the effort such that all demos can be run over night, i.e. within 10-15 hours. Two possible strategies:

1. Avoid too long simulations. Either by deleting them, or by reducing the number of discretization points, time steps, etc.
2. Profiling the Matlab codes and identifying bottle necks. Especially for qm_optimal where the computational effort was not considered during coding ...

[Burkhard Schmidt]

An example for a notoriously slow simulation: OptMorseOscillator/PRJ_0_1/2. Why is that so much slower than most other OCT demo examples? Really only because of the time steps: 100 x 200? Or is it due to the visualization?

[Burkhard Schmidt]

Preliminary test on OptMorseOscillator/AMO_Gauss/1 suggest that perhaps(!) the number of substeps can be reduced from 200 to 100 but not to 50 ("exploding" solutions) .
On the other hand, increasing the number of substeps leads to an increased number of steps before the iteration explodes: Increasing the number of substeps from 200 to 300 allows to do run 40 instead of 30 iterations which leads to a further increase of the target functional.