Relative-magnitude: weight_by_correlation, min_cc & normalization are a bit confusing

[flixha]

I was trying to calculate some relative magnitudes and was a bit confused by what weight_by_correlation and min_cc are supposed to do (or whether they are doing what they were intended to do).

Main issue

Running relative_magnitude with weight_by_correlation=True returns delta-magnitudes that are each multiplied by the CC of the trace. So to calculate the actual magnitude, the user always has to do something like:

from eqcorrscan.utils.mag_calc import relative_magnitude
delta_mags, ccs = relative_magnitudes(......, weight_by_correlation=True, return_correlations=True)
delta_mag_values = [_delta_mag[1] for _delta_mag in delta_mags.items()]
cc_values =  [cc[1] for cc in ccs.items()]
average_mag = original_mag + np.sum(delta_mag_values) / np.sum(cc_values)

Now I know that family.relative_magnitude is not working anyways right now, but looking into the code the normalization for the CC-values did not happen there as far as I can see. So it seems to me relative_magnitude wasn't intended to work like shown in the snippet above. Is that true?

Other behavior I expected to work differently:

• By returning delta-mags multiplied with CC, if the user wants to save StationMagnitude for each observation, they first have to convert with station_mag = original_mag + delta_mag / cc
• When weight_by_correlation=False, then min_cc has no effect, i.e., delta-mags are returned for all traces, even those that don't correlate well

Code + Example

Here is the code on how the CC-weighting works right now.

Here a minimal example based on the EQcorrscan-tests (this may not show the effect strongly, because the magnitude difference between event1 and event2 is rather small):

(Click to expand minimal example!)

import numpy as np
from obspy.clients.fdsn import Client
from eqcorrscan.utils.mag_calc import relative_magnitude

client = Client("GEONET")
event1 = client.get_events(eventid="2016p912302")[0]
event2 = client.get_events(eventid="3470170")[0]
shared_chans = {p1.waveform_id.get_seed_string()
                for p1 in event1.picks}.intersection(
    {p2.waveform_id.get_seed_string() for p2 in event2.picks})
bulk = [(p.waveform_id.network_code, p.waveform_id.station_code,
            p.waveform_id.location_code, p.waveform_id.channel_code,
            p.time - 20, p.time + 60) for p in event1.picks
        if p.waveform_id.get_seed_string() in shared_chans]
st1 = client.get_waveforms_bulk(bulk)
st1 = st1.detrend().filter("bandpass", freqmin=2, freqmax=20)
bulk = [(p.waveform_id.network_code, p.waveform_id.station_code,
            p.waveform_id.location_code, p.waveform_id.channel_code,
            p.time - 20, p.time + 60) for p in event2.picks
        if p.waveform_id.get_seed_string() in shared_chans]
st2 = client.get_waveforms_bulk(bulk)
st2 = st2.detrend().filter("bandpass", freqmin=2, freqmax=20)

delta_mags, correlations = relative_magnitude(
    st1=st1, st2=st2, event1=event1, event2=event2, return_correlations=True)
delta_mag_values = [_delta_mag[1] for _delta_mag in delta_mags.items()]
cc_values =  [cc[1] for cc in correlations.items()]
original_mag = event1.magnitudes[0].mag
average_mag = original_mag + np.sum(delta_mag_values) / np.sum(cc_values)

[calum-chamberlain]

This is a little confusing, agreed. The paper referenced (Schaff and Richards 2014) does not use the same procedure. I would be tempted to remove the weight_by_correlations option so that the user can work things out themselves.

• You are right that min_cc only works with weight_by_correlation, and this should be changed.
• Yes, to get the StationMagnitude you need to add the original magnitude.

[flixha]

Ok, good that we're on the same page then! The other PR is more urged, so I'll fix the remaining things there until doing anything related to this here.

• The confusing part for me was less that the function returns the delta-magnitude (and one hence has to add the original magnitude), but rather that each delta-magnitude is needs to be divided by CC again for that addition.
• The code that is commented out in Family.relative_magnitude did not contain that division by CC, and it computed the average relative magnitude basically with np.sum(delta_mag_values) / len(delta_mag_values), instead of np.sum(delta_mag_values) / np.sum(cc_values) as it would make sense to me. That would have given results that were not too far off with high values for min_cc, but would have caused larger deviations with small values for min_cc.

[calum-chamberlain]

So what is implemented is supposed to be similar to equation 4 in the paper, but how you go from that to the full magnitude isn't necessarily obvious. Normalizing by the mean of the correlations isn't likely to be the intended use. I will have to reread the paper to work out how it should work, but I won't have time soon, so I will just remove the functionality if it is confusing and it can be added later in a more robust way if/ when someone wants it. CJ Chamberlain, out of office

…

________________________________ From: FelixHa ***@***.***> Sent: Friday, April 16, 2021 7:26:53 PM To: eqcorrscan/EQcorrscan ***@***.***> Cc: Calum Chamberlain ***@***.***>; Comment ***@***.***> Subject: Re: [eqcorrscan/EQcorrscan] Relative-magnitude: weight_by_correlation, min_cc & normalization are a bit confusing (#455) Ok, good that we're on the same page then! The other PR is more urged, so I'll fix the remaining things there until doing anything related to this here. * The confusing part for me was less that the function returns the delta-magnitude (and one hence has to add the original magnitude), but rather that each delta-magnitude is needs to be divided by CC again for that addition. * The code that is commented out in Family.relative_magnitude did not contain that division by CC, and it computed the average relative magnitude basically with np.sum(delta_mag_values) / len(delta_mag_values), instead of np.sum(delta_mag_values) / np.sum(cc_values) as it would make sense to me. That would have given results that were not too far off with high values for min_cc, but would have caused larger deviations with small values for min_cc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feqcorrscan%2FEQcorrscan%2Fissues%2F455%23issuecomment-820976154&data=04%7C01%7Ccalum.chamberlain%40vuw.ac.nz%7C79bd686359964bd538b508d900a9034a%7Ccfe63e236951427e8683bb84dcf1d20c%7C0%7C0%7C637541548292332436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dn2UPTtQrXgLSLdT4qlBr1%2F3VEUnJ707iPZNdxMfCN4%3D&reserved=0>, or unsubscribe<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACTIM44DF3VXNJHNAZV7FZTTI7RD3ANCNFSM4275OAAA&data=04%7C01%7Ccalum.chamberlain%40vuw.ac.nz%7C79bd686359964bd538b508d900a9034a%7Ccfe63e236951427e8683bb84dcf1d20c%7C0%7C0%7C637541548292342430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=itg1%2BPDK0L%2FZfpA9RjvW%2BtcTidw4MfNXEcW9xDr642w%3D&reserved=0>.

[flixha]

Ok, I see where this comes from now - I'll have to do the same in terms of reading the paper in more detail! I should be able to tackle this as I also now have a small dataset that could be useful for testing the bias / scaling between the relative magnitudes and standard local magnitudes. Will getback to that later...

[flixha]

This is now addressed in #461 .