#2 hspo prints wrong eigenvalues when used with certain atlas algorithms

[Harry Dankowicz]

Bug in hspo with some atlas algorithms: prints wrong eigenvalues when restarts continuation in second direction. I don't have example, but the cause is the (mis)use of chart data, I suspect. I can generate example, I suppose, but I think you will understand the issue.

[Harry Dankowicz]

Further clarification: this is an incompatibility between atlas_recipes and bddat slot functions. This latter may be a more general bug. The problem is that when we restart to go in the other direction, the starting chart gets the bddat data from the last chart in the ptlist.

[Frank Schilder]

I think I know what to look for. Will try to do it soon.

[Frank Schilder]

I checked the code and it looks OK to me. Please check if the error still occurs and send me an example if it does.

[Frank Schilder]

Hi Frank,

Run demo_varcoll_v1 in the old recipes repository that you checked out. For simplicity, change the interval for p to go from 0.9 to 1.1.

Then take a look at the last column of the bifurcation data. You will see that two rows have the same eigenvalues, but that these are not actually rows corresponding to the same chart. The problem is that the repetition of the initial chart is not flushed to disk until after the detection of the first new chart (in the opposite direction), which leads to the evaluation of the eigenvalues using function data associated with the new chart. For atlas algorithms that only flush one chart at a time, all's fine, but if more than one chart is flushed at a time, then they will all end up having the same values for the function data and therefore the same eigenvalues as the last located chart.

cheers,

Harry

[Frank Schilder]

I cannot confirm the description above. When I run linosz/demo_varcoll_v1 for p=0.9...1.1 I get the following data:

'PT'  'TYPE'  'p'       'mult1'             'mult2'             'mult3'
[ 4]  'EP'    [0.9000]  [0.0150 - 0.0405i]  [0.0150 + 0.0405i]  [1.0000]
[ 3]      ''  [0.9096]  [0.0164 - 0.0400i]  [0.0164 + 0.0400i]  [1.0000]
[ 2]      ''  [0.9598]  [0.0237 - 0.0361i]  [0.0237 + 0.0361i]  [1.0000]
[ 1]      ''  [0.9861]  [0.0271 - 0.0336i]  [0.0271 + 0.0336i]  [1.0000]
[ 0]  'EP'    [     1]  [0.0288 - 0.0322i]  [0.0288 + 0.0322i]  [1.0000]
[ 0]  'EP'    [     1]  [0.0304 - 0.0307i]  [0.0304 + 0.0307i]  [1.0000]
[ 1]      ''  [1.0139]  [0.0304 - 0.0307i]  [0.0304 + 0.0307i]  [1.0000]
[ 2]      ''  [1.0402]  [0.0331 - 0.0278i]  [0.0331 + 0.0278i]  [1.0000]
[ 3]      ''  [1.0904]  [0.0374 - 0.0216i]  [0.0374 + 0.0216i]  [1.0000]
[ 4]  'EP'    [1.1000]  [0.0381 - 0.0204i]  [0.0381 + 0.0204i]  [1.0000]

I guess what you mean is that the two points corresponding to p=1 should have the same data, but don't.

If this is not what you observe, can you rerun the same demo, save bd as a .mat-file and attach this file to your post, so I can compare?

Thanks!

[Frank Schilder]

Snippets from an e-mail conversation:

[Harry] Yes, the two points corresponding to the initial chart should have the same eigenvalues. They don't, because the reflushing of the initial chart uses the function data most recently computed (which corresponds to the new chart in the opposite direction).

[Frank] [...] After changing direction, the atlas does not flush the initial chart immediately, hence, we see wrong multipliers for the first chart. It might be possible and desirable to fix that in atlas_1d.

In general, caching values in data is correct when the life-time of the cached value is an execution of efunc_F etc. Anything that needs to survive more than that should be stored in chart data.

[Harry] [to changing atlas_1d] But the problem would also occur if you encountered an event, in which case a curve segment would consist of multiple points, but the function data would be associated only with the last point.

Options:

1) Add explicit re-computation of variational solution and multipliers (defeats the intended purpose of caching).
1a) Define a monitor function po_mult_eigs that accesses data.M and assigns each multiplier to a separate parameter ('seg.m(1)' ... 'seg.m(3)').
2) Change var_coll_add to use chart data.