Allowing different time shifts in Rayleigh and Love wave misfit evaluations and waveform plotting

[ammcpherson]

Good morning,

There are certain situations in which one might want to allow different time shifts for the different surface waves, e.g. +/- 5 seconds for Love, and +/- 20 seconds for Rayleigh. This is currently not possible in MTUQ without some significant workarounds, for both the misfit evaluation and to then make the waveform plots at the end.

I've attached figure showing the Love and Rayleigh wave time shifts for an event using 6 different velocity models. There are two stations for which one model has (apparently) anomalously large time shifts compared the rest of the stations and models, leading us to believe that these waves are experiencing cycle-skipping. The hope is then that by changing the allowable time shifts during the misfit evaluation, MTUQ would automatically correct the cycle-skipping without any manual corrections on behalf of the user.

Thanks

[carltape]

Thanks, Amanda. Given that this issue is common to 6 different velocity models (and many earthquakes, as I understand), it's clear that this fix will impact many users, saving us from station- and event-specific fixes and enabling analysis of larger data sets (more events, stations, and velocity models).

[rmodrak]

Hi Amanda, Thanks for the clear description of this issue.

Agreed that having different allowable time shifts for Rayleigh and Love waves could help reduce manual adjustments. (Even then, some manual adjustment could still be necessary, but the overall effort could be reduced I think.)

[rmodrak]

I'd agree with Julien's suggestion: create separate misfit functions for Rayleigh and Love waves and invoke the grid_search separately with each one.  

I think this a good approach in many ways-- easier for the user, easier for the developer (probably also better as we start to speake about more sophisticated data covariance).

[rmodrak]

Modifying the misfit function to accept different allowable ranges is also possible, but given how heavily optimized and difficult to follow the underlying time shifts are already, I'd hesitate to try this.

[rmodrak]

I think that leaves only the question of how to update plot_waveforms(). I'd have to think about this a bit more...

[rmodrak]

@carltape Agreed, this whole discussion seems relevant to the region specific templates we were discussing

[rmodrak]

@carltape In terms of reducing manual adjustments, the feature request makes a difference for only 1 of 6 models? I imagine there are other cases it makes a bigger difference. Agreed +/-20 Rayleigh, +/-5 Love is common to all 6 models.

[ammcpherson]

@rmodrak There are other events I have currently that the feature request would indeed make a bigger difference for. I chose this event because it is relatively clear what the proper allowable time shifts should be.

[rmodrak]

@ammcpherson Makes sense thanks

[rmodrak]

I wonder if a good approach would be just to introduce new functions with slightly different syntax?

    plot_waveforms3(
        filename, data_bw, data_rayleigh, data_love, synthetics_bw, synthetics_rayleigh, synthetics_love, ...)

    plot_data_greens3(
        filename, data_bw, data_rayleigh, data_love, greens_bw, greens_rayleigh, greens_love, 
        process_bw, proces_rayleigh, process_love, misfit_bw, misfit_rayleigh, misfit_love, ...)

Interested in Amanda's, Julien's, and others thoughts. apologies if I missed anything during Wednesday's call

[carltape]

@thurinj what do you think about the plotting proposal from Ryan? I think if we can address the plotting, then Amanda can try out the proposed approach. I agree that we need the plotting to be correct, since that would be the standard way to detect whether cycle skipping is occurring. (Even if the underlying time shift calculation in the code is correct.) Thanks.

[thurinj]

Hi @carltape, @rmodrak, @ammcpherson,

Adding this option would indeed solve part of the problem. But then we wouldn't have any option to plot Rayleigh and Love wave with different time shifts, without plotting the body waves. It's probably a good solution in the meantime, but it won't solve the plotting problem entirely.

I'll open a feature branch to give it a shot, and think of a way of just making our waveform plot more dynamic.