Question about reference trace for dv/v

[imme-w]

Hello Peter, I have a question about the reference trace for the dv/v calculations. The documentation on the reference trace says: We can opt for a single reference trace for the whole period or multiple reference traces. Is it also possible to have a single reference trace that doesn't span over the whole time window that the dv/v is calculated over? Thank you!

[PeterMakus]

Hi Imme,

Yes, the easiest way to do this would be by initiating ´Monitor.compute_velocity_change´ manually rather than using the ´compute_velocity_change_bulk´ method.

You will find that ´compute_velocity_change´ allows you to provide a reference trace as an argument that you could compute yourself before (e.g., an average of the correlation functions over the time period you would like to use). To use multicore, you could build a function that is very similar to ´compute_velocity_change_bulk´ (you would have to write this yourself; you can check out SeisMIC's source code).

You can find the documentation of the function here

I will close this for now, but feel free to comment if you should have further questions, are stuck.

Peter

[imme-w]

Hi Peter, thanks for your answer! I tried using _compute_velocitychange. I used _select_corrtime to select all the correlations in a certain time window and then I used stack to average all the selected correlations into one array and used this array as reference trace in the _compute_velocitychange. As tag I used subdivision because the documentation said this was almost always the case (not sure what else I could use).

To check if it was working correctly I chose the reference time window over the whole time window first, so I could compare it with _compute_velocity_changebulk, because I would expect the results to be the same. The dv/v results are quite similar but the correlation is much lower when I use _compute_velocitychange (see figure below). Do you think my approach is correct and do you have any idea why this might happen? Thank you!

[PeterMakus]

Hi Imme, I think the reason for this is that you feed in an array of reference traces, which works but it will end up using an approach employing multiple reference traces (see https://www.sciencedirect.com/science/article/pii/S0377027314000596 for details). A side effect of this method will be having a lower correlation coefficient.

If you make sure that you really only feed in the single trace as reference (i.e., a 1D array or vector) then the correlation coefficient should be higher.

Feel free to correct me if I'm wrong in my assumptions.

Cheers, Peter

[imme-w]

Thank you for your answer! I think I am actually using a 1D array already (at least that's what I'm trying), because I select a time window and then stack/average all the correlations in this time window into a Stream that contains 1 correlation and I use the data from this one correlation as my reference trace. Here is an example:

[PeterMakus]

Hey Imme, I see. Technically, you are doing everything right (I think)

Now seeing how short the time window for your reference trace is, I would assume that this is just in the nature of choosing such a short time frame. A single day of cross-correlation is probably not enough to approximate the Green's function of the medium and the CF might thus be quite dissimilar to the CF from other times. You could try repeating the process with reference traces that are created from consecutively longer time windows and see if and how much the correlation coefficient is improving.

What puzzles me is that there is no spike in the correlation coefficient at 1st January 2021 (here reference and actual CF should be very similar).

[imme-w]

Hey Peter. Thanks again for thinking with me! For clarification, the image I sent above was just an example how I make the reference trace, the reference trace I actually used to compute my velocity changes is two years (2021 and 2022). Sorry I was a bit unclear about that. So that explains the absence of the spike at 1st January 2021.

In the end I want to use a reference trace that is some months shorter than the complete two years but for comparison with the compute_velocity_change_bulk I did the complete two years first.

[PeterMakus]

ok that's actually quite strange then. Could you send me your complete script, so I can check whether there might be something that I can work with?