-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MQZ issue with broadband vs. accelerometer comparison #84
Comments
the graph is an indication though it does not help to troubleshoot really. I encourage to have a look at the raw data (say using daily streams) as it should be done prior to any processing of some sort :) - especially when it is made with big batch (though tedious i know) Would be helpful to have from Jesse:
|
Summary of the PSA process above from what i understoodInput:
Process:
Tools and Sources:
|
MQZ strong motion periods (delta/fdsnwebservice: https://service.geonet.org.nz/fdsnws/station/1/query?network=NZ&station=MQZ&level=channel&format=text&channel=?NZ)
Periods of identified Strong Motion default in quality: Today: Does this affect Computation on the event traces ? With regards to the comparison with the broadband HH It looks like the mount of the HH is old stable and performing since 2009:
|
The procedure is as follows: After the raw mseed files are downloaded, they are then evaluated with a ground-motion classifier to determine whether the event meets certain quality criteria. High quality events are then pre-processed for intensity measures. In pre-processing, I first demean the data and pad the data for five seconds on either end. I then remove instrument sensitivity and differentiate any velocity data into acceleration. The data are then rotated to ZNE components and trimmed back to their original window length. Finally, the data are low-pass filtered at a corner frequency of 0.05 Hz. The pre-processed data is used to compute intensity measures (PGA, PGV, pSAs, etc.) for horizontal, vertical, rotd100, and rotd50 components. The list of M5 events used for MQZ are as follows (note that this analysis has only been performed between HN and HH channels): |
thanks for this description:
From the Broadband side of the process: MQZ broadband had a fairly stable sensor and datalogger since 2009 to now: so let s focus on the most recent and 5 events first. |
MQZ is located in Christchurch
Out of 5, the 3 latest and closest have some reasonable data to compare with for a start |
@SquirrelKnight In order to focus on the most relevant data sets: I guess also it would be interesting to get the raw PSA data derived from HH and HN ( as a text file) of the method to be able to compare the values for a least the events: 2020p475488, 2020p606562 , 2020p201743 |
thanks a lot @SquirrelKnight okay thanks for the distance relationship ! cheers |
As I mentioned above, I do compute IMs for detected arrivals as well. We will be providing a pared down version of the database that excises any IMs outside of this distance relationship, but I've made it an objective to supply as much data as possible! Looking at 2019p927023, the signal appears quite strong (these figures are both unfiltered with no instrument correction). |
|
--- Summary (strong motion parameters - reprocessed as in the strong motion tools - using response)
location of the instruments are not exactly the same. SM is more tightly coupled to the ground. Output on the Strong motion HN are consistent with the strong motion tools output for this event. |
Here is a plot of the event 2020p201743 (M5 distance: 100km) derived Strong motion PSA Left: PSA graphs (HHZ and HNZ) 3 components | Right: PSA Ratio of the respectives components with tthe different instrumentations [ Left x: period in second; right x:period in second y:Ratio %g_psaHH/%g_psaHN ]
Derived data avaiable here (PSA for the 3 components and different instruments. ) Will check these assumptions again and track other source of errors with the next relevant event. |
---- Summary results: --- MQZ and MLZ data are available and comparable (here below recomputed locally )
MLZ: Derived summary data are consistent between HH and HN (all components) |
Here is a plot of the event 2020p475488 M5.9 derived Strong motion PSA
parameters for MQZ HH and HN ( distance: 400km)
For both events above the comparaison between HH and HN is relevant at leasts on the Vertical component Data available at 20200624_2020p475488_PsaHH_HN.tar.gz |
---- Summary results: --- MQZ and MLZ data are available and comparable ( when recomputed locally ) (upon threshold SNR on
same observations as before : MLZ okay - MQZ Horizontals have the most noticeable differences between HH/HN |
Hi @SquirrelKnight
Further investigation: Get the closest dual instrumented station, a set of most significant though fairly distant events (Say Max ~400km). Compare Results with regards to local effects. cheers! |
Assume (only) Part of the problem may come from a "potential" component reversal on one of the instruments: --> investigation in instrument orientation on going |
update: @SquirrelKnight field check about to confirm Strong motion orientation (and misleading component naming) . When enacted would you check while rotating the horizontal signals. (hence shifting the metadata azimuth) ? |
FYI @mnaguit - probably can be useful for some strong motion derived data sets |
@SquirrelKnight Second stage will be : fix the metadata and rename the data component properly in the 12Z system FYI @elidana |
Great. Thanks for digging in deep!
…On Sun, Oct 17, 2021 at 7:29 PM jerry ***@***.***> wrote:
@SquirrelKnight <https://github.com/SquirrelKnight>
first iteration of change for the station MQZ strong:
1- Legacy site code change (20 to 21) (location of instrument)
2-Correction of the orientation at least from Mid 2019 to oreination of N
to azimuth 270
*Warning: Just noticed that it may contain a bug into the metadata built
for historical data: orientation of the strong is considered 270 deg since
the start of the Strong motio)* as in
https://service.geonet.org.nz/fdsnws/station/1/query?network=NZ&station=MQZ&level=channel&format=text&channel=HN
?
Second stage will be : fix the metadata and rename the data component
properly in the 12Z system
FYI @elidana <https://github.com/elidana>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#84 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ5LPP44MTPVW6N2UYE5QV3UHOBB3ANCNFSM5EUZ5ZVQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Addendum (due to confusing naming...)
Actions: |
The 2016 orientation is deemed correct ENZ, based on photos of the site from that period.
from the comment above, then the assumption is that the cabling/configuration 2016-2019 was perhaps messed up but with an install put away since 2019, Only testing data will bring a some ideas / and fix. |
For checking the above assumption (or similar consequence)
As opposed to #84 (comment) So several things here (still to be solidified) @elidana @SquirrelKnight 1 - HN strong motion Horizontal components are most likely Inverted HNE is confirmed actually HNN! (and HNN is HNE) Hence badly named and orientated component chanels are a nightmare to deal with overtime. |
2017p795065 psa comparison between BN and HH is consistent (does not mean that oreintation are fully matching ...:)) FYi @elidana |
--- Summary ----
-Data from 2017 with similar instrumentation do not show major critical difference between both instrumentations derived parameters.
FYI @elidana @SquirrelKnight @mnaguit @ozym et al ... |
summary broadband data need to be corrected:
|
@SquirrelKnight @elidana @mnaguit FYI @ozym The later being: Has been modified on the field ~10:30 on 23/02/2022 NZT. (and will be updated in Delta asap)
upon completion close this painful ticket!! :) cheers |
Jesse Hutchinson (University of Canterbury) has noted an issue with MQZ seismic data when comparing data from the broadband and strong motion sensors installed at the station.
His method calculates the difference of the natural log values of PGAStrong from PGABroadband instruments, for all M>5 events recorded by the station.
A plot he provided is showing a consistent discrepancy for all events recorded between ~2014 and ~2020.
Further investigation to understand the cause are needed
The text was updated successfully, but these errors were encountered: