band code and sampling rate should correspond

[crotwell]

Channel band codes in SEED have (approximate) numerical ranges associated with them. Would be useful to have at least a warning for channels with band codes that differ significantly from the corresponding ranges.

Probably this should be a warning instead of an error as there are cases where either the SEED bands are not well defined, or there isn't a band code that matches. And of course, state of health channels often make a mockery of the rules...

For the codes that do not have ranges, L V U, give them a wide range, perhaps: L ~1 so .1 < sample rate < 10 V ~.1 so .01 < sample rate < 1 U ~.01 so .001 < sample rate < .1 although there isn't a band between U at 0.01 and R at 0.0001, so allowing U to be .0001 < sample rate < .1 might be as good as can be done.

Band code to sample rate table is in appendix A of the SEED manual, p124.

[timronan]

The list of Band Codes described in this issue is not comprehensive and leaves out many overlapping bands. It is possible to have multiple codes that describe the same frequency band, for example, H and E describe the same frequency band ≥ 80 to < 250 but different corner periods. How would we deal with corner period? If we were going to make this into a warning it would at least have to be comprehensive for all of the band codes listed in the SEED manual.

Once again, I am kind of worried this rule would throw a number of false positives and may slightly discredit the validator.

[crotwell]

Not sure I understand how there would be false positives with this. The rule would be "if band code is H then sample rate must be ≥ 80 to < 250." Corner frequency is not important for this direction.

I am NOT proposing the reverse, ie, if sample rate is 100 then it must be H. That would be much more complex, you would need to know corner frequency, and would generate false positives.

Yes, I was intending this to include all the band codes in the seed manual, just didn't want to type them all into the issue.

[timronan]

This is a good rule, it gives users a quick outline for band code naming conventions. I was asked about these yesterday, and as the SEED manual becomes less ubiquitous we need to find a new band code documentation scheme. This rule would fulfill that issue. This rule needs to be a warning and is a switch.

The rule would read

Warning 330:

        switch (Channel:Code[1]) (
            case 'F':  Channel:SampleRate must be assigned (>=1000 and <5000) 
            case 'G':  Channel:SampleRate must be assigned (>=1000 and <5000)  
            case 'D':  Channel:SampleRate must be assigned (>=250 and <1000)   
            case 'C':  Channel:SampleRate must be assigned (>=250 and <1000)
            case 'E':  Channel:SampleRate must be assigned (>=80 and <250)
            case 'H':  Channel:SampleRate must be assigned (>=80 and <250)
            case 'S':  Channel:SampleRate must be assigned (>=10 and <80) 
            case 'B':  Channel:SampleRate must be assigned (>=10 and <80)
            case 'M':  Channel:SampleRate must be assigned (>=1 and <10) 
            case 'L':  Channel:SampleRate must be assigned (>=0.1 and <10)
            case 'V':  Channel:SampleRate must be assigned (>=0.01 and <1)
            case 'U':  Channel:SampleRate must be assigned (>=0.001 and <0.1)
            case 'R':  Channel:SampleRate must be assigned (>=0.0001 and <0.001) 
            case 'P':  Channel:SampleRate must be assigned (>=0.00001 and <0.0001) 
            case 'T':  Channel:SampleRate must be assigned (>=0.000001 and <0.00001) 
            case 'Q':  Channel:SampleRate must be  < 0.000001 
            default: PASS
       )

If the warning is thrown only the individual switch case would be printed. There would be a print statement for each case in the code switch:

Example.

case 'F':   Channel:SampleRate must be assigned (>=1000 and <5000) 
     if(1000<=Channel:Code[1]<5000){
         return(pass)
     }else{
         return(warning(Frequency Band Channel:Code[1]  must have a sample rate assigned between >=1000 and <5000))
     }

[crotwell]

Last case should be Q, not T. Otherwise looks good.

[timronan]

Thanks for the catch, that was a typo.