Explore and analyse the 2 options of integrating receiver function code and station metadata, catalogs and temporary survey waveforms

[geoscienceaustralia]

Explore and analyse the 2 options of integrating receiver function code and station metadata, catalogs and temporary survey waveforms

[alexgorb]

Why not to use ASDF? The RF code already supports HDF5 format. All our processing will be based on ASDF. We use seiscomp only for phase picking ...

…

Sent from my iPhone On 28 Nov 2017, at 9:50 PM, Niket Chhajed <[email protected]<mailto:[email protected]>> wrote: We have 2 options for using the receiver function codebase at https://github.com/trichter/rf.git to generate the analysis over the temporary stations data: 1. Ingest waveform data, temporary station xmls and event data into a Seiscomp3 instance and then use the receiver function codebase as is by creating an FDSN client connected to the FDSN webservice running on the Seiscomp3 instance. 2. Directly call the receiver function code on the waveform miniseed and skip the ingestion processas suggested by @alexgorb<https://github.com/alexgorb>. Both these approaches have their merits and demerits. The first approach is easy, less error-prone and faster and to implement because we would be using the receiver function code base without any tweaking. But, it will take that extra step of ingesting everything into Seiscomp3. The second approach will require tweaking the receiver function code base to a great extent, primarily how it extracts the waveform centered around the event and uses several routines related to rfstats, which in turn use others. The routines are documented scantily in that only one line describes what the routine does, but the code in the routines is largely undocumented. Will have another discussion with @rh-downunder<https://github.com/rh-downunder> and @alexgorb<https://github.com/alexgorb> before taking a call on which approach to pursue. - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#53>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFjpn7TaQiUub1t-qkGx6YaX5ALa0t0tks5s6-WBgaJpZM4QtCgh>. Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks. -------------------------------------------------------------------------------------------------------------------------

[niketchhajed]

Yes, @alexgorb we will have a technical discussion today and do the analysis. Maybe, I am not finding the right thing and there is a better way. Hopefully, things will be clear after a discussion.

[niketchhajed]

Also, to correct my previous statement of the first approach I suggested. We do not need to ingest all the waveform data into Seiscomp3. We only need to ingest that small time-window of waveform data around the events.

Also, the metadata for the temporary stations will need to be extracted first, irrespective of what approach we take.

[niketchhajed]

After discussion with @alexgorb, it was decided that we will take the second approach and interface receiver function directly with ASDF files instead of the first approach. Just want to clarify that this will take longer to implement than the first approach, both from learning curve perspective and testing. @rh-downunder has passed on some code base at https://github.com/GeoscienceAustralia/passive-seismic/tree/master/xcorqc. I will check how we can integrate the rf functionality with this codebase.