check stage 1 input units against instrument code

[crotwell]

Potentially useful to have a rule that the Stage 1 input units for a channel with instrument code of H or L should be m/s and for instrument code N to be m/s**2, so input units for a velocity seismometer should be velocity, and accelerometer should be acceleration?

Also apply similar to InstrumentSensitivity input units.

Similarly output units of last stage should be count.

Other instrument codes might also have similar input unit rules.

[metempleton]

Some networks used L for accelerometers before the N instrument code was added to the SEED channel descriptions. Older temporary experiments would show this. (My $.02.)

…

--Mary

On Jan 30, 2020, at 6:31 PM, Philip Crotwell ***@***.***> wrote: Potentially useful to have a rule that the Stage 1 input units for a channel with instrument code of H or L should be m/s and for instrument code N to be m/s**2, so input units for a velocity seismometer should be velocity, and accelerometer should be acceleration? Also apply similar to InstrumentSensitivity input units. Similarly output units of last stage should be count. Other instrument codes might also have similar input unit rules. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[chad-earthscope]

That would disallow using centimeters, millimeters, micrometers, nanometers. They are not common, but do we want to error-out on them? Hmm. It would be good to catch the expected time dimension for sure.

[crotwell]

Point take, but a rule saying BHZ should have input units of some kind of velocity, ie convertible to m/s, would be good.

For old L instrument code accelerometers, the rule could be to allow either velocity or acceleration, but would error on displacement, or temperature or...

[timronan]

This seems like these rules would be too restrictive as errors and should be potentially included as warnings. The rules could be something similar too:

| Rule ID | Description | Type |

| 406 | IF Channel:Code == ("?H?" OR "?L?") AND (Stage[1]:InputUnit != ?m/s OR Stage[Last]:OutputUnits != count?) THEN FAIL | Warning |

| 407 | IF Channel:Code == "?N?" AND (Stage[1]:InputUnit != (?m/s OR ?m/s**2) OR Stage[Last]:OutputUnits != count?) THEN FAIL | Warning |

Are there any objections to including these?

[rcasey-earthscope]

Warning level notices might be okay. The main thing is we don't want to tighten these down too much until we know just how conformant future XML authors are going to be with instrument code to units. These are just two examples....if we start this, do we want to handle all of the units? -Rob

…

On Feb 3, 2020, at 5:02 PM, timronan ***@***.***> wrote: This seems like these rules would be too restrictive as errors and should be potentially included as warnings. The rules could be something similar too: | Rule ID | Description | Type | | 406 | IF Channel:Code == ("?H?" OR "?L?") AND (Stage[1]:InputUnit != ?m/s OR Stage[Last]:OutputUnits != count?) THEN FAIL | Warning | | 407 | IF Channel:Code == "?N?" AND (Stage[1]:InputUnit != (?m/s OR ?m/s**2) OR Stage[Last]:OutputUnits != count?) THEN FAIL | Warning | Are there any objections to including these? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#96?email_source=notifications&email_token=AFL4VN4LYOX6KUQ66NKPCX3RBC5BLA5CNFSM4KN74OLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKV67UA#issuecomment-581693392>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VN7666HBPZ35ZHUP7T3RBC5BLANCNFSM4KN74OLA>.

[timronan]

Should this warning be added? Have we come to a consensus?

[metempleton]

I’m ok with those warnings. (I wouldn’t be ok with errors.) Just for background, it’s not really an error to submit a displacement response for a velocity transducer, or a velocity response for an accelerometer. IM used to submit displacement responses for all of their instruments. We’d _prefer_ the response units to match the transducer type, but it’s not an error (in my opinion) if it doesn’t. (Note that a response type that doesn’t match the transducer type won’t show a flat passband unless the instrument is a hybrid.) cheers, Mary

…

On Apr 8, 2020, at 3:42 PM, timronan ***@***.***> wrote: Should this warning be added? Have we come to a consensus? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[timronan]

Thanks Mary, I will add this rule as a warning.

[timronan]

This issue has been addressed by rule:

321: If Channel:Code[2] == (H | L | M | N) then Stage[1]:InputUnit must equal m/s AND Stage[Last]:OutputUnits must equal count*

Validator version stationxml-validator-1.7.0-RC-01, available on the Validator's releases page, includes this rule.

Please verify this function works satisfactorily and report or close the issue based on your findings.

[metempleton]

We need to omit “M” from this - mass position input units are usually either V or M/S**2. (There’s never been consensus on which description to use.) cheers, Mary

…

On Apr 27, 2020, at 4:29 PM, timronan ***@***.***> wrote: This issue has been addressed by rule: 321: If Channel:Code[2] == (H | L | M | N) then Stage[1]:InputUnit must equal m/s AND Stage[Last]:OutputUnits must equal count* Validator version stationxml-validator-1.7.0-RC-01, available on the Validator's releases page, includes this rule. Please verify this function works satisfactorily and report or close the issue based on your findings. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[timronan]

We will omit M in this next RC. Thanks for catching this.