Run cross corr on every loop after initial run

[ubdbra001]

The addition of the got_cross_corr flag to this if-statement means that the cross correlation will be re-run on every subsequent image. But I think that the fix for Issue #19 will involve a bit more than just this.

[ubdbra001]

As predicted, I've tried running this as is and it throws an error. Looks like it is because the series used for the correlation are built up over the first 30 mins and then discareded after the first call to generate_cross_corr, so only has a single value in each series in the subsequent call.

[ubdbra001]

I think the most recent commit should fix it, will test more tomorrow

[twVolc]

Amazing, thanks for looking into this! From what I can see I imagine this absolutely will have fixed the issue, but yes worth double checking.

[ubdbra001]

Do I/we need to think about what data is saved from this change? As far as I can see a single file is saved with this info cross_corr_info.txt and this has a single value each for:

• ica_gap
• lag_frames
• lag
• velocity

Which I assume are just the value for the last run of the cross corr. Is that still okay?

[ubdbra001]

Discussed this with @tpering last week and he highlighted that this data also shows up in the final output as velo_eff. Previously it should shown the same value per 30 min chunk (or whatever the user defined), and with this fix should show the same value for the first 30 mins and then a slightly different value for all subsequent timepoints. Will check this, and if it looks like this is happening then I'll make this a proper pull request.

[ubdbra001]

Just returning to this and I have two observations, one minor and one major:

1. The minor one is: re-running the cross correlation on every image slows down processing quite dramatically (from approx < 1s per image pair to approx 1-2 seconds; I don't have actual figures, but I could produce some if you'd like)
2. THe major one is: There appears to some kind of bug in the interaction between matplotlib and the GUI that causes an error (Fail to allocate bitmap, possibly a memory error) after a certain number of plots have been produced (~360). This hasn't been a problem before because the cross-corr plot was only being regenerated rarely, but now it is being generated for each image Pyplis hits this error at around the 30 min mark after the DOAS-FOV alignment has been run (12 images per min of data, 30 mins of data = 360 images).

My initial thought for both of these is maybe including some kind of setting to reduce the frequency the cross-corr is being run? Maybe every 12 images (~1 min of data)? But this is me pulling a number out of a hat, so if you have better ideas or reasons why this is not a good idea I'm all ears.

This is also just a stop-gap, as it will shift the issue in 2. from 30 mins to 6 hours worth of data. Which will not be ideal for real-time processing, so I will continue to look into fixes for the issue.

[ubdbra001]

I found an old issue in the repo for matplotlib which has an answer that works (for pycam I changed matplotlib.use('TkAgg') to matplotlib.use('Agg') in the figures_cam.py file). But I'm not 100% on what that means for the plots in the GUI. Looking at the matplotlib docs, "TkAgg" is an interactive backend, while "Agg" is non-interactive.

[twVolc]

Good to hear you're getting to the bottom of this. Even if we don't run cross-corr every image we would want to solve that matploitlib error as proesumably it will hit similar things eventually if we had this software running long-term? Perhaps the interactive aspect means that the navigation toolbar no longer works? This was a nice feature for some of the plots in the GUI - being able to quickly save figures and zoom in on certain aspects, but it definitely isn't critical, so if your fix prevents the GUI from crashing and everything else looks ok then I'd say go with that. We can always incorporate our own "save figure" function at some point, which is possibly one of the most useful aspects of the navigation toolbar.