Header patch for plot_data_greens3 and misc fix related to waveform figure

[thurinj]

Clean-reset of the waveform_plot_update branch, which makes a clean slate based of PR #333
It should fix both issues #332 and #335.

It introduces several enhancements and bug fixes. It is still mostly focused on improving the waveform figure (header fix, misfit normalization/contribution fix), and I took the opportunity to fix the GitHub python workflows that was broken with the release of Python 3.14.

Will merge before the end of the week and delete PR #333 unless there is an objection.

tag: @rmodrak, @ammcpherson, @aakash10gupta

---

Old message from #333 for quick reference

This should solve issue #332 - fairly minimal fix.

I am not a huge fan of the resulting header when using 3 different filtering parameters:
image
(the time window duration is clipped out of the figure).

I can merge the PR as is in the next day or two if you want (so @ammcpherson can move forward with her work), or take a bit more time to rework the overall text arrangement so everything fits tightly in frame of the figure. (We can probably have the layout a bit smarter depending on what we have to insert in the figure's header.)
Let me know what's the best for you.

[aakash10gupta]

• Will this update, update plot_data_greens_1 and plot_data_greens_2 as well?
• Sometimes the model field has the full path of the database being used, which pushes the fields solver and misfit out of the frame. Is it possible to tackle that in this pull request so that only the name of the database after the final / in the full path is printed?

[thurinj]

Good point, I did implemented an adaptive font size for the header display, but the text might still clip-out if the path is very long. The last commit make it so the path is completely stripped down to the folder name of the model.

Testing on my side yield this for plot_data_greens1(), plot_data_greens2() and plot_data_greens3()

There is a slight difference in header look between the 1 and the [2, 3] versions of the figure, because the plot_data_greens1() figures are only 3 columns and the figure is not the same base size as the plot_data_greens2() or plot_data_greens3().

And just to be sure @aakash10gupta, what do you mean by?:

• Will this update, update plot_data_greens_1 and plot_data_greens_2 as well?

[aakash10gupta]

Since your PR title says plot_data_greens3 I was concerned if this update will not affect the other waveform plotting routines plot_data_greens1 and plot_data_greens2. I mainly use the latter two. I haven't looked at the source code enough to know if the routines are linked in some sense.