search

iris-edu / stationxml-seed-converter

Station XML/Seed converter
GNU General Public License v3.0
16 stars 12 forks source link

Converter appears to be stripping out or mixing up response data components #16

Closed amkearns-usgs closed 5 years ago

amkearns-usgs commented 5 years ago

One example of this is the case attached. Got data from a single channel epoch via FDSN MDA http query. ("ANMO-one-epoch.xml") Converted to dataless and then back into station XML. Station XML was compared via diff to be missing some unit descriptions in the response. This appears to have also been the case for the intermediate dataless file (ANMO-one-epoch.dataless) based on running it through rdseed. The second XML file ("ANMO-one-epoch.converted.xml") lacks inputunits and outputunits field for its response.

We have done similar tests with this kind of circular conversion using obspy to test equality of generated fields. We find that dataless components that match inventory object fields in obspy are correct through multiple conversions (i.e, from dataless to xml back to dataless). We find in comparing XML files (since these can be compared using a more simple diff) that there are several cases in larger files where unit fields still exist but have been populated with the wrong components (see the case for this same epoch -- ANMO LWD from 2002-11-19 to 2008-06-30 in the FDSN-generated "ANMO.one.xml" vs. the cyclically converted "ANMO.two.xml" (one round of XML to seed back to XML) and "ANMO.three.xml" (a second round of this conversion), which has some fields that should be from degrees (inputunits) to degrees (outputunits) replaced with Teslas (input) to digital counts (output). I was informed there may also be cases where an entire response is pointed to by the wrong channel (i.e., expecting a pole-zero response but finding a polynomial response or vice-versa), though I do not know of a specific channel/epoch where this has occurred; looking at it from a diff suggests no response polynomial or pole-zero is lost or duplicated outside of the unit dictionaries.

We do not notice any inconsistencies with dates or other common metadata parameters like elevation, orientation, etc. All issues appear to be related to responses.

ANMO dataless error examples.zip

amkearns-usgs commented 5 years ago

In the case of the files that only have ANMO-LWD epochs, some test cases I have written suggest that the issue originates when saving an XML file from dataless. The input/output units are included on the initial read-in of XML, show up when loaded from the dataless file, but do not exist in the data from the XML file converted from dataless.

yazan-iris commented 5 years ago

This is not a bug, your xml is incomplete. Remember, seed stage 0 [B058] does not have input/output unit info. When converting back from seed to xml, the information is derived from stage 1 and the last stage of the response. When the response does not exist as in your case, such information is lost. I am closing this issue.

ghost commented 5 years ago

Who should we talk to at IRIS about the FDSN server generating incomplete stationxml? All our original test stationxml was pulled from https://service.iris.edu/fdsnws/station/docs/1/builder/

ghost commented 5 years ago

Maybe I am misunderstanding the scope of this tool or we have built this project thing incorrectly.

The majority of our testing is sending IRIS produced station xml (with response data) into the converter, sending the output dataless back into the converter, and comparing the final outputted xml with the original.

Doing this we have seen these problems:

  1. Stage 0 has disappeared entirely. But the rest of the stages remained.

  2. Response units have changed, in one case from degrees into teslas.

  3. Polynomial responses have turned into pole-zero responses

Unfortunately, I have only witnessed these issues when converting network level metadata. When I narrow inputs to individual channels or responses, the problems disappear.

Our base assumptions are:

  1. That we could convert 1 to 1 from xml to dataless and back.
  2. That it would accept fdsn ws produced stationxml as input.
timronan commented 5 years ago

It seems like the input stationXML used in the test above was generated from the IRIS FDSN station service using a request similar to:

https://service.iris.edu/fdsnws/station/1/query?net=IU&sta=ANMO&loc=00&cha=LWD&starttime=2002-11-20T21:07:00.000&endtime=2008-06-30T20:00:00.000&level=channel&format=xml&includecomments=true&nodata=404

which is truncated at the channel level. To make an accurate conversion one must provide a complete stationXML, one that is truncated at the response level, to the stationxml-seed-converter. Please try the test again with a request similar to:

https://service.iris.edu/fdsnws/station/1/query?net=IU&sta=ANMO&loc=00&cha=LWD&starttime=2002-11-20T21:07:00.000&endtime=2008-06-30T20:00:00.000&level=response&format=xml&includecomments=true&nodata=404.

Seed fundamentally does not have Net, Sta, Cha, Resp levels like StationXML so we have to use the lowest level of StationXML when converting. Otherwise the conversion will be lossy. When making a station services request, make sure to change the "Level" drop list to "response". If the error persist please repost/reopen the issue.

amkearns-usgs commented 5 years ago

We believe we're following the right construction for response-level XML files. Here is what we did to produce data with a discrepancy in one epoch between the input and output units, both the initial FDSN query and the actual running of the program.

image

When we run the curl command we get the following excerpt in the stationXML (ANMO.one.xml):

<Channel code="LWD" endDate="2008-06-30T00:00:00" locationCode="00" restrictedStatus="open" startDate="2002-11-19T21:07:00">
    <Latitude>34.945911</Latitude>
    <Longitude>-106.457199</Longitude>
    <Elevation>1820.7</Elevation>
    <Depth>0</Depth>
    <Azimuth>0</Azimuth>
    <Dip>0</Dip>
    <Type>CONTINUOUS</Type>
    <Type>WEATHER</Type>
    <SampleRate>1E00</SampleRate>
    <ClockDrift>0E00</ClockDrift>
    <Sensor>
     <Description>Handar model 425A wind direction indicator</Description>
    </Sensor>
    <Response>
     <InstrumentSensitivity>
      <Value>1E0</Value>
      <Frequency>1E0</Frequency>
      <InputUnits>
       <Name>D</Name>
       <Description>Degrees 0-360 (direction)</Description>
      </InputUnits>
      <OutputUnits>
       <Name>D</Name>
       <Description>Degrees 0-360 (direction)</Description>
      </OutputUnits>
     </InstrumentSensitivity>
     <Stage number="1">
      <PolesZeros>
       <InputUnits>
        <Name>D</Name>
        <Description>Degrees 0-360 (direction)</Description>
       </InputUnits>
       <OutputUnits>
        <Name>D</Name>
        <Description>Degrees 0-360 (direction)</Description>
       </OutputUnits>
       <PzTransferFunctionType>LAPLACE (RADIANS/SECOND)</PzTransferFunctionType>
       <NormalizationFactor>1.0</NormalizationFactor>
       <NormalizationFrequency>1.00000</NormalizationFrequency>
      </PolesZeros>
      <StageGain>
       <Value>1.0</Value>
       <Frequency>1.0</Frequency>
      </StageGain>
     </Stage>
    </Response>
   </Channel>

Stage 1 has degrees as input and output units.

When we run the converter to get ANMO.two.xml this is what we get for the corresponding epoch (again, excerpted). Note that the units now go Teslas to counts:

<Channel code="LWD" startDate="2002-11-19T21:07:00.000Z" endDate="2008-06-30T00:00:00.000Z" locationCode="00">
                <Latitude plusError="0.0" minusError="0.0">34.945911</Latitude>
                <Longitude plusError="0.0" minusError="0.0">-106.457199</Longitude>
                <Elevation plusError="0.0" minusError="0.0">1820.7</Elevation>
                <Depth plusError="0.0" minusError="0.0">0.0</Depth>
                <Azimuth plusError="0.0" minusError="0.0">0.0</Azimuth>
                <Dip plusError="0.0" minusError="0.0">0.0</Dip>
                <Type>CONTINUOUS</Type>
                <Type>WEATHER</Type>
                <SampleRate plusError="0.0" minusError="0.0">1.0</SampleRate>
                <ClockDrift plusError="0.0" minusError="0.0">0.0</ClockDrift>
                <Sensor>
                    <Description>Handar model 425A wind direction indicator</Description>
                </Sensor>
                <Response>
                    <InstrumentSensitivity>
                        <Value>1.0</Value>
                        <Frequency>1.0</Frequency>
                        <InputUnits>
                            <Name>D</Name>
                            <Description>Degrees 0-360 (direction)</Description>
                        </InputUnits>
                        <OutputUnits>
                            <Name>D</Name>
                            <Description>Degrees 0-360 (direction)</Description>
                        </OutputUnits>
                        <FrequencyStart>0.0</FrequencyStart>
                        <FrequencyEnd>0.0</FrequencyEnd>
                        <FrequencyDBVariation>0.0</FrequencyDBVariation>
                    </InstrumentSensitivity>
                    <Stage number="1">
                        <PolesZeros>
                            <InputUnits>
<Name>T</Name>
<Description>Magnetic Flux Density in Teslas</Description>
                            </InputUnits>
                            <OutputUnits>
<Name>COUNTS</Name>
<Description>Digital Counts</Description>
                            </OutputUnits>
                            <PzTransferFunctionType>LAPLACE (RADIANS/SECOND)</PzTransferFunctionType>
                            <NormalizationFactor>1.0</NormalizationFactor>
                            <NormalizationFrequency plusError="0.0" minusError="0.0">1.0</NormalizationFrequency>
                            <Zero number="0">
<Real plusError="0.0" minusError="0.0">0.0</Real>
<Imaginary plusError="0.0" minusError="0.0">0.0</Imaginary>
                            </Zero>
                            <Pole number="1">
<Real plusError="0.0" minusError="0.0">0.0</Real>
<Imaginary plusError="0.0" minusError="0.0">0.0</Imaginary>
                            </Pole>
                        </PolesZeros>
                        <StageGain>
                            <Value>1.0E7</Value>
                            <Frequency>0.4</Frequency>
                        </StageGain>
                    </Stage>
                </Response>
            </Channel>

We can attach the full files if you would like but they are rather large.

amkearns-usgs commented 5 years ago

The curl command from the screenshot above:

curl -L -o ANMO.one.xml "https://service.iris.edu/fdsnws/station/1/query?net=IU&sta=ANMO&level=response&format=xml&includecomments=true&nodata=404"
yazan-iris commented 5 years ago

I am reopening this issue based on the new input. The files provided for the test case are incomplete and cannot be used for testing this usecase. Files generated from curl -L -o ANMO.one.xml "https://service.iris.edu/fdsnws/station/1/query?net=IU&sta=ANMO&level=response&format=xml&includecomments=true&nodata=404" are more appropriate.

yazan-iris commented 5 years ago

Generating files and running test case, will update soon.

rcasey-earthscope commented 5 years ago 
I'd like to jump in with a couple of observations while the troubleshooting is taking place.

Firstly, 'D' is not a viable unit name.  The recommended unit names are 'degree', 'degrees', or 'deg'.  I don't think this is necessarily causing a bug to be expressed, since it did pass through the conversion process, but I think it will be good to adjust this name in the source StationXML or it will not pass through the validator when we get that into the process.

Secondly, the anomalous stage 1 with teslas seems to be grabbed from either the LFZ, VFZ, or UFZ channels that ANMO has.  I suspect it to be from LFZ, if only because it comes before the LWD channel.  Somehow, the LFZ Stage1 is being held over and then re-copied to LWD stage 1.  Actually, it will be good to look at the full output of ANMO.two.xml and see if LFZ, VFZ, or UFZ is magically missing its stage 1.  It could be a bug in the associations getting jumbled up.

-Rob

On Dec 7, 2018, at 8:49 AM, yazan-iris notifications@github.com wrote:

Generating files and running test case, will update soon.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iris-edu/stationxml-seed-converter/issues/16#issuecomment-445293606, or mute the thread https://github.com/notifications/unsubscribe-auth/AVfKt0fKZrzYO5JbU7WJk9uVFpTo8WDEks5u2pwygaJpZM4Y8nfs.

amkearns-usgs commented 5 years ago

Here is a zip file containing both the input and output XML files. I have not looked at the other channels to see what if anything might be missing from their responses. ANMO.xmls.zip

yazan-iris commented 5 years ago

This is a confirmed bug, it has been fixed and waiting for testing. Will update this issue later in the day.

timronan commented 5 years ago

It seems like the bug is fixed and we are releasing stationxml-seed-converter-2.0.1-SNAPSHOT. jar.

Using the curl command described above the station service returns:

    <Channel code="LWD" endDate="2008-06-30T00:00:00" locationCode="00" restrictedStatus="open" startDate="2002-11-19T21:07:00">
     <Latitude>34.945911</Latitude>
     <Longitude>-106.457199</Longitude>
     <Elevation>1820.7</Elevation>
     <Depth>0</Depth>
     <Azimuth>0</Azimuth>
     <Dip>0</Dip>
     <Type>CONTINUOUS</Type>
     <Type>WEATHER</Type>
     <SampleRate>1E00</SampleRate>
     <ClockDrift>0E00</ClockDrift>
     <Sensor>
      <Description>Handar model 425A wind direction indicator</Description>
     </Sensor>
     <Response>
      <InstrumentSensitivity>
       <Value>1E0</Value>
       <Frequency>1E0</Frequency>
       <InputUnits>
        <Name>D</Name>
        <Description>Degrees 0-360 (direction)</Description>
       </InputUnits>
       <OutputUnits>
        <Name>D</Name>
        <Description>Degrees 0-360 (direction)</Description>
       </OutputUnits>
      </InstrumentSensitivity>
      <Stage number="1">
       <PolesZeros>
        <InputUnits>
         <Name>D</Name>
         <Description>Degrees 0-360 (direction)</Description>
        </InputUnits>
        <OutputUnits>
         <Name>D</Name>
         <Description>Degrees 0-360 (direction)</Description>
        </OutputUnits>
        <PzTransferFunctionType>LAPLACE (RADIANS/SECOND)</PzTransferFunctionType>
        <NormalizationFactor>1.0</NormalizationFactor>
        <NormalizationFrequency>1.00000</NormalizationFrequency>
       </PolesZeros>
       <StageGain>
        <Value>1.0</Value>
        <Frequency>1.0</Frequency>
       </StageGain>
      </Stage>
     </Response>
    </Channel>

then convertering xml->dataless->xml the converter outputs :

 <Channel code="LWD" startDate="2002-11-19T21:07:00.000Z" endDate="2008-06-30T00:00:00.000Z" locationCode="00">
     <Latitude plusError="0.0" minusError="0.0">34.945911</Latitude>
     <Longitude plusError="0.0" minusError="0.0">-106.457199</Longitude>
     <Elevation plusError="0.0" minusError="0.0">1820.7</Elevation>
     <Depth plusError="0.0" minusError="0.0">0.0</Depth>
     <Azimuth plusError="0.0" minusError="0.0">0.0</Azimuth>
     <Dip plusError="0.0" minusError="0.0">0.0</Dip>
     <Type>CONTINUOUS</Type>
     <Type>WEATHER</Type>
     <SampleRate plusError="0.0" minusError="0.0">1.0</SampleRate>
     <ClockDrift plusError="0.0" minusError="0.0">0.0</ClockDrift>
     <Sensor>
         <Description>Handar model 425A wind direction indicator</Description>
     </Sensor>    
     <Response>   
         <InstrumentSensitivity>
             <Value>1.0</Value>
             <Frequency>1.0</Frequency>
             <InputUnits> 
                 <Name>D</Name>
                 <Description>Degrees 0-360 (direction)</Description>
             </InputUnits>
             <OutputUnits>
                 <Name>D</Name>
                 <Description>Degrees 0-360 (direction)</Description>
             </OutputUnits>
             <FrequencyStart>0.0</FrequencyStart>
             <FrequencyEnd>0.0</FrequencyEnd>
             <FrequencyDBVariation>0.0</FrequencyDBVariation>
         </InstrumentSensitivity>
         <Stage number="1">
             <PolesZeros> 
                 <InputUnits> 
                 <Name>D</Name>
                 <Description>Degrees 0-360 (direction)</Description>
                 </InputUnits>
                 <OutputUnits>
                 <Name>D</Name>
                 <Description>Degrees 0-360 (direction)</Description>
                 </OutputUnits>
                 <PzTransferFunctionType>LAPLACE (RADIANS/SECOND)</PzTransferFunctionType>
                 <NormalizationFactor>1.0</NormalizationFactor>
                 <NormalizationFrequency plusError="0.0" minusError="0.0">1.0</NormalizationFrequency>
             </PolesZeros>
             <StageGain>  
                 <Value>1.0</Value>
                 <Frequency>1.0</Frequency>
             </StageGain> 
         </Stage>     
     </Response>  
 </Channel>

Please pull the 2.0.1 release to verify the accuracy of this bug fix and close the issue if satisfied. Also please be aware that the station xml used for this test does not pass the StationXML-Validator . Although the stationxml-seed-converter is not dependent upon a station xml's ability to validate, the converter may produce results that need close inspection. Thanks for helping us test and debug.

amkearns-usgs commented 5 years ago

OK. This issue looks fixed from our testing, so we'll close it.