a lot of metadata issues of AlpArray + permanent stations

PetrColinSky commented 4 years ago

Dear colleagues, after reporting the issues #49, #51 and #52, I am digging deeper into the station xml and I am reporting other issues.

First, back to issue #52, where I reported stations RD.SAVF http://ws.resif.fr/fdsnws/station/1/query?network=RD&station=ETNF&channel=???&level=response and RD.ETNF http://ws.resif.fr/fdsnws/station/1/query?network=RD&station=SAVF&channel=???&level=response saying, that after deconvolving the response using the xml from RESIF web service, it works fine. Actually, it does not (wrong testing, sorry). But I found the problem: these are really the FIR filter coefficients in the xmls, which blow up the record to infinity. There is something like division by zero somewhere. I solved it for myself by simply deleting the stages with FIR filters, since I am only interested in the long-period part. Then it works fine.

Other issue which does not allow to deconvolve: Z3.A028B http://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A028B&channel=???&level=response has <Dip>0</Dip> for the Z channel (zero dip for the vertical channel). There needs to be -90 (or maybe +90), otherwise the channels do not look orthogonal and things are crashing.

The other issues are about the wrong entries in the metadata files. Meaning, technically, the deconvolution works fine, and visually, the records look nice. This is what makes it dangerous. My procedure how to find these issues is based on the techniques reported in these two papers: here: https://academic.oup.com/gji/article/218/1/115/5315763 end here: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2019JB019102 It is about precise measurement of the phase shifts between the neighboring stations. The simplest method I use now is just plotting of selected phase of a long teleseismic wave (usually period = 100 s) to a map. Such a map then clearly shows, that some station is off the phase with respect to the others. See an example in the attached figure.

example

This is a 100s Rayleigh wave wavefront (picked at vertical component as zero-crossing of the wave the closest to the maximum of the envelope of the fundamental mode). Contours are by 5 s of propagation. It clearly shows, that A037A is off (it is from Japan earthquake on 2016-11-21, not important in the moment). The other stations reported in this issue are either corrected or removed from the map to show just one station being off the time. This has a precision of +/- 1 or 2 seconds. The array-beamforming from the papers above have even higher precision. All these methods are based on the assumption, that majority of the records is right. The two papers above WERE NOT based on using the metadata. I processed the records using my own script and my own database of Poles and Zeros (PaZ) sets for all the BB sensors used. I only listed the station name and the sensor in place. This approach could be potentially erroneous, if I miss a sensor change at some station. However, when now switching to using station xml, I need to say, that xmls are even much more erroneous than my stone-age deconvolution method. However, right the comparison of the two approaches gave me the chance to reveal some station xml issues. I not only revealed that there are issues, many times I found what is the problem, I corrected it for my copy of xml files and I tested, that after the correction, the deconvolution gives “reasonable” result (especially, that it matches my stone-age method used in the papers above). Maybe, for some stations, there are other issues which I did not find. Anyway, these "corrections" need to be validated and entered to EIDA by the respective network opearators. The comments below are based on analysing data for three earthquakes on 2016-08-19 2016-08-29 2016-11-21 Here we go:

CH.AIGLE http://eida.ethz.ch/fdsnws/station/1/query?net=CH&station=AIGLE&channel=???&level=response For the epoch 1998 – 2018, where there was STS2, only 1 Pole and 1 Zero is given, which is not a transfer function of STS2. At 100 s wave, it shifts the phase by roughly 15 seconds. When replaced by proper STS2 PaZ, it works fine.

CZ.GOPC According to the web page of the hosting institute, there is Guralp 360s sensor: https://oko.pecny.cz/pecny/seismom.html The PaZ in the xml are given for Guralp 120s http://geofon.gfz-potsdam.de/fdsnws/station/1/query/?net=CZ&station=GOPC&channel=???&level=response When exchanged for Guralp 360s PaZ set, it works fine.

GU.RNCA http://webservices.ingv.it/fdsnws/station/1/query?net=GU&station=RNCA&channel=???&level=response GU.GRAM http://webservices.ingv.it/fdsnws/station/1/query?net=GU&station=GRAM&channel=???&level=response GU.EQUI http://webservices.ingv.it/fdsnws/station/1/query?net=GU&station=EQUI&channel=???&level=response GU.POPM http://webservices.ingv.it/fdsnws/station/1/query?net=GU&station=POPM&channel=???&level=response GU.RORO http://webservices.ingv.it/fdsnws/station/1/query?net=GU&station=RORO&channel=???&level=response NI.VINO http://webservices.ingv.it/fdsnws/station/1/query?net=NI&station=VINO&channel=???&level=response These stations have the PaZ written in xml in HERTZ, but the header says it is in RADIANS: <PzTransferFunctionType>LAPLACE (RADIANS/SECOND)</PzTransferFunctionType> Exchanging the string “RADIANS/SECOND” --> “HERTZ” helps a lot. This error shifts the phase of 100s wave by around 20s. The only exception is VINO, where even after correcting this, the phase still does not match the neighboring stations. So, there is some other mistake in addition, or it is a timing issue.

Z3.A121A http://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query/?net=Z3&station=A121A&channel=???&level=response Z3.A122A Z3.A123A Z3.A124A Z3.A125A Z3.A127A Z3.A128A Z3.A129A This took me a while to find, it is well hidden and it again distorts the records by around 15 seconds at 100s wave. In the set of PaZ, if there is a non-zero imaginary part, there must always be a complex-conjugate Pole with the same real part but opposite sign at the imaginary. For all these 8 stations, there are two Poles, where the imaginary is always positive. It is the entry: <Real>-463.1</Real> <Imaginary>430.5</Imaginary> which repeats two times. The minus sign needs to be in front of one of the “430.5” values. It applies for all channels.

The following stations have several issues. First, there were some sensor changes reported, but not reflected in the xml. Second, currently there are sensors in place, which are not in the xmls at all. CR.BRJN http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=BRJN&channel=???&level=response – xml has PaZ for 30s Guralp, currently there is STS2 in place CR.PLIT http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=PLIT&channel=???&level=response – xml has PaZ for 30s Guralp, currently, there is 60s Guralp CR.MOSL http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=MOSL&channel=???&level=response – xml has PaZ for 30s Guralp, currently, there is 60s Guralp CR.PTJ http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=PTJ&channel=???&level=response – xml has unusual set of PaZ, currently, there is 60s Guralp and the transfer function differs a lot from the one given in the xml CR.MORI http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=MORI&channel=???&level=response – PaZ in the xml are the same as for PTJ, currently, there is 120s Guralp CR.KALN http://www.orfeus-eu.org/fdsnws/station/1/query?network=CR&station=KALN&channel=???&level=response – xml has PaZ for 30s Guralp, currently, there is 60s Guralp After I created my own xmls for these stations with respective PaZ, everything matches nicely.

Following stations have flipped polarity at least for vertical, and at least sometimes: A351B (always) A350A (always) GU.RORO (always, see other issue above) A352A at least in November 2016 A210A, correct in August 2016, flipped in November 2016

For the next group of stations, I did not find the error. They are nicely matching the phases of the AlpArray network in August 2016, but are off in November 2016. In the xml, these times are in the same epoch. My question is, if maybe, meanwhile, there was a sensor change which is not reflected in the xmls. All these stations are distorted the same way (very suspicious, it does not look like a random coincidence), and also, the time shift is dispersive, meaning, it changes with period. For high-frequency waves (10s), it is almost invisible. For longer waves, it increases and it reaches around 20 – 22 seconds at 100s wave. It is certainly not a timing issue, because it would create the same shift over the whole period range.

Then, I have a bunch of stations, which are always off and I did not found any obvious mistake in the matadata. As they are always shifted the same way for all earthquakes (not just the 3, but many others), I guess, there must be a systematic error. The most obvious could again be a wrong sensor reported in xml. If such a mistake is consistently reported everywhere the same, I have no means to correct it. I did not check, if the time shift is dispersive. It is a bit laborious job. If it is constant, it is probably a timing issue. If it is dispersive, it is wrong set of PaZ.

MT.AVM FR.AJAC FR.ARTF FR.BSTF FR.SAUF GU.ENR GU.BURY GR.GEC2 IV.ASSB IV.ATMI IV.PII IV.SSFR NI.VINO (see above) OX.MPRI OX.ACOM Z3.A032A Z3.A030A

These issues are about the metadata of “good” stations only. I do not report here all the many stations, which have serious problems with the data itself (missing components, glitches, gaps, thousands of traces per day, recording electronic noise only, ...), as these I removed from my analysis anyway. So, this is for the 3 earthquakes. I have 31 of them in my to-do-list (till mid 2019), so stay tuned for updates. I hope it will not be 40 stations for each EQ, though.

cheers petr, UniWien

sheimers commented 4 years ago

I have updated CH.AIGLE with the correct STS2 response for the old (1998 - 2018) epoch.

http://eida.ethz.ch/fdsnws/station/1/query?net=CH&station=AIGLE&channel=???&level=response

aschloem commented 4 years ago

Hey Petr, thank you for checking the metadata.

I fixed Z3.A028B (Dip HHZ: -90); Z3.A121A, Z3.A122A, Z3.A123A, Z3.A124A, Z3.A125A, Z3.A126A, Z3.A127A, Z3.A128A, Z3.A129A (wrong poles and zeros).

Other metadata updates will follow soon.

Regards Antje

LMU Munich

aschloem commented 4 years ago

Hi, I wrote the polarity flip of A350A, A351A, A351B, A352A into the metadata. The reversal polarity occurred due to incorrect wiring. Antje

petrrr commented 4 years ago

Short update on NI.VINO: We learned that station instrumentation has changes but still need the details from the data provider to get this fixed.

petrrr commented 3 years ago

@PetrColinSky: Update on GU stations: The metadata were upgraded with metadata were provided regenerated and provided by the station operator. PSD look okay now.

If you have the occasion, maybe check if the problem you saw has gone.

petrrr commented 3 years ago

@PetrColinSky: I have just checked the status of the NI stations. Stations has been updated back in October NI.VINO to solve the issue. The response seems reasonable, so you might want to check with also for this station.

PetrColinSky commented 3 years ago

@petrrr Thanks, I will have a look at it at some point. I may add NI.VINO to my analysis then. cheers p

petrrr commented 3 years ago

The stations (OX.MPRI, OX.ACOM) have been corrected in collaboration with the data provider.

jschaeff commented 2 years ago

Let's do a recap on all the stations reported here, by type of problem and by network:

Please each node, check again for the issues reported in the metadata and report back here.

Problem in FIR filters

[ ] RD.SAV RESIF
[ ] RD.ETNF RESIF

Problem with deconvolution

[X] Z3.A028B LMU

Stations that are off the phase

[X] CH.AIGLE ETHZ
[ ] CZ.GOPC GFZ
[X] GU.RNCA INGV
[X] GU.GRAM INGV
[X] GU.EQUI INGV
[X] GU.POPM INGV
[X] GU.RORO INGV
[X] NI.VINO INGV
[X] Z3.A121A LMU
[X] Z3.A122A LMU
[X] Z3.A123A LMU
[X] Z3.A124A LMU
[X] Z3.A125A LMU
[X] Z3.A127A LMU
[X] Z3.A128A LMU
[X] Z3.A129A LMU
[ ] CR.BRJN ODC
[ ] CR.PLIT ODC
[ ] CR.MOSL ODC
[ ] CR.PTJ ODC
[ ] CR.MORI ODC
[ ] CR.KALN ODC

Stations with flipped polarity

[X] A351B LMU
[X] A350A LMU
[X] GU.RORO INGV see also the other point above
[X] A352A LMU at least in November 2016
[ ] A210A RESIF correct in August 2016, flipped in November 2016

Missing sensor change in metadata ?

[ ] Z3.A100A LMU
[ ] Z3.A102A LMU
[ ] Z3.A104A LMU
[ ] Z3.A108A LMU
[ ] Z3.A109A LMU
[ ] Z3.A033A LMU
[ ] Z3.A036A LMU
[ ] Z3.A037A LMU (see the attached map of wavefronts)

Stations are systematicaly off

[ ] MT.AVM RESIF
[ ] FR.AJAC RESIF
[ ] FR.ARTF RESIF
[ ] FR.BSTF RESIF
[ ] FR.SAUF RESIF
[X] GU.ENR INGV
[X] GU.BURY INGV
[ ] GR.GEC2 BGR
[ ] IV.ASSB INGV
[ ] IV.ATMI INGV
[ ] IV.PII INGV
[ ] IV.SSFR INGV
[x] NI.VINO INGV (see above) waiting for metadata correction.
[X] OX.MPRI INGV
[X] OX.ACOM INGV
[ ] Z3.A032A LMU
[ ] Z3.A030A LMU

petrrr commented 2 years ago

Thanks a lot to @jschaeff for coming up with the summary of the status of this ticket.

Just some question regarding stations NI.VINO: As already commented in https://github.com/EIDA/userfeedback/issues/68#issuecomment-785915467, the inventory data for this station have been updated. We only do not have any confirmation by the issue author @PetrColinSky that the observed problem has been fixed.

In the summary summary list this station appears two times, one time it is check, the other time it is not. So either we consider this problem solved, or we are waiting for confirmation. But we should be clear and consistent here.

jschaeff commented 2 years ago

I's because there was 2 issues with NI.VINO. If the action has been taken on your side, the best is to consider it done.

PetrColinSky commented 2 years ago

Hi, @petrrr, yes, I have NI.VINO on my to-do-list for some while (as well as GU.* stations), so, it is not forgotten and I plan to get back to the "wavefront check" in next weeks. I am currently experiencing some technical issues running my codes on the server, but I will have a look at it, as I still want to include these stations to my tomography project. As @jschaeff suggested, if you have checked the responses and did all the corrections you could, then you can consider it done. Thanks!

jschaeff commented 2 years ago

FR AJAC, ARTF, BSTF, SAUF are in the correction pipeline on our side. More news next week.
MT.AVM is under investigation.
RD has been investigated and that's what the experts said:

We checked the metadata for RD_SAVF and RD_ETNF stations. We cannot reproduce the problem you encountered. We used python and the obspy removeresponse module. With opspy the deconvolution process works properly, on data segments of the given stations (4 hours the 10th February, between 00h00 to 04h00 UTC, see attached images). Can you tell us what you are using to deconvolve the signals ?

@PetrColinSky how does it looks like ?

petrrr commented 2 years ago

I's because there was 2 issues with NI.VINO. If the action has been taken on your side, the best is to consider it done.

We believe this are just two independent observations of the same issue. Actually, there was a mismatch of the described instrument. So we expect this problem to be solved. The spectrum and other checks look plausible.

EIDA / userfeedback