PH5 StationTXT is missing some information

[nick-falco]

Can we add the following information to the ObsPy Inventory returned by ph5tostationxml.py? StationTXT is incomplete without this information.

Channel level StationTXT Missing: Azimuth|Dip|SensorDescription|Scale|ScaleFreq|ScaleUnits

Network level StationTXT Missing: TotalStations

Examples about how these fields should be labeled/added may be found in the ObsPy StationTXT tests file (test_station_text_parsing.py).

[nick-falco]

As requested, @rsdeazevedo @derick-hess please find a short description of the missing fields below. Full descriptions for azimuth and dip are available in the SEED manual.

Azimuth - The azimuth of the instrument in degrees from north, clockwise. (e.g. 0.0) Dip - The dip of the instrument in degrees, down from horizontal. (e.g. -90.0) SensorDescription - The type of sensor used. (e.g. Guralp CMG3ESP_60sec/Reftek 130 Datalogger) Scale - Instrument scaling factor for the sensor. (e.g. 1.27318E9) ScaleFreq - Instrument scaling frequency for the sensor. (e.g. 0.3) ScaleUnits - Units of the instrument scaling factor.(e.g. M/S)

TotalStations - Total number of stations in a given network.

For more examples, please feel free to make requests to the FDSN Station Service. e.g. https://service.iris.edu/fdsnws/station/1/query?format=text&level=channel&network=IU&station=ANMO

[nick-falco]

@derick-hess I think this would be the equivalent relationship:

• Scale = Response_t -> Gain
• ScaleFreq = SEED Manual Blockette 58 Note 5
  • The frequency (fs) at which the Gain is correct.
• ScaleUnits = Response_t -> units_s

[derick-hess]

hmm not sure gain would be correct. Gain is an int value usually between 1 and 32

[derick-hess]

i think that might be in rsponse_t under bit_weight but that is usually in volts/count. Which can be converted to m/s with more known info about the sensor so I think that should be okay to put in station txt. ScaleFreq not sure though I'll have to research a bit more

[nick-falco]

I think you're correct about Scale/ScaleUnits. What we need is the equivalent to instrument sensitivity, so I had incorrectly assumed that it was the gain.

I'm certain that ScaleFreq is what is defined in SEED blockette 58. How this fits into PH5, I don't know.

[derick-hess]

Well as I was driving home for lunch I just thought about it and converting volts/count isn't that easy. Volt/count is actually the result after you have take the initial voltage/displacement of the sensor and digitized it with the data logger applying the sample rate and data longer gain.

I think all of this information will be in the RESP files for a given sensor though and easily readable. I'll talk to someone from the sensors group today to confirm this and the best way to go about getting this info.

[nick-falco]

Sounds good. Let me know what you find out.

[derick-hess]

Azimuth and dip are now in obs_channel.azimuth and obs_channel.dip

[nick-falco]

Thanks for this. I'll test it to make sure everything shows up in the StationTXT output.

[nick-falco]

In my local testing with 4C and 8A, self.ph5.Das_t always returns an empty dictionary so azimuth and dip values are never added.

Also we will need to only add the azimuth and dip if the das exists. Otherwise a key error occurs when you try to access an item from the dictionary that doesn't exist. See line 375.

[derick-hess]

I'll fix that but when I run it on 4C i get the falling returned for obs_channel

Channel 'DPZ', Location '' Time range: 2015-08-04 16:30:00 - 2015-08-05 19:30:00 Latitude: 46.24, Longitude: -122.14, Elevation: 1289.0 m, Local Depth: 0.0 m Azimuth: 0.00 degrees from north, clockwise Dip: 90.00 degrees down from horizontal Sampling Rate: 250.00 Hz Sensor (Description): ()

Channel 'DPZ', Location '' Time range: 2015-08-04 16:30:00 - 2015-08-05 19:30:00 Latitude: 46.24, Longitude: -122.15, Elevation: 1276.0 m, Local Depth: 0.0 m Azimuth: 0.00 degrees from north, clockwise Dip: 90.00 degrees down from horizontal Sampling Rate: 250.00 Hz Sensor (Description): ()

Channel 'DPZ', Location '' Time range: 2015-08-04 16:30:00 - 2015-08-05 19:30:00 Latitude: 46.23, Longitude: -123.15, Elevation: 1244.0 m, Local Depth: 0.0 m Azimuth: 0.00 degrees from north, clockwise Dip: 90.00 degrees down from horizontal Sampling Rate: 250.00 Hz Sensor (Description): ()

Channel 'DPZ', Location '' Time range: 2015-08-04 16:30:00 - 2015-08-05 19:30:00 Latitude: 46.23, Longitude: -122.15, Elevation: 1257.0 m, Local Depth: 0.0 m Azimuth: 0.00 degrees from north, clockwise Dip: 90.00 degrees down from horizontal Sampling Rate: 250.00 Hz Sensor (Description): ()

Channel 'DPZ', Location '' Time range: 2015-08-04 16:30:00 - 2015-08-05 19:30:00 Latitude: 46.23, Longitude: -122.15, Elevation: 1240.0 m, Local Depth: 0.0 m Azimuth: 0.00 degrees from north, clockwise Dip: 90.00 degrees down from horizontal Sampling Rate: 250.00 Hz Sensor (Description): ()

[nick-falco]

What was the request that you ran exactly?

[derick-hess]

I just ran it from the command line on 4C and had it print the obs_cha. self.ph5.Das_t shouldn't return anything. It should be saved in Das_t after ph5API.filter_das_t is ran.

[derick-hess]

Also I need to do an enhancement on this for speed. I need to grab the start time and just grab 1 second or so from the das table instead of the entire table for each das. We only need a single entry from the das table for each das to grab the correct value from the receiver_t

[nick-falco]

Ahh I got it now. I was checking self.ph5.Das_t before calling read_das_t. The following seems to work:

       # add azimuth and dip
        self.ph5.read_das_t(das, reread=False)
        if self.ph5.Das_t.get(das):
            Das_t = ph5API.filter_das_t(self.ph5.Das_t[das]['rows'],
                                        station_list[deployment][0][
                                            'channel_number_i'])        
            Receiver_t=self.ph5.get_receiver_t (Das_t, by_n_i=True)

            obs_channel.azimuth=Receiver_t['orientation/azimuth/value_f']
            obs_channel.dip=Receiver_t['orientation/dip/value_f']

[derick-hess]

yeah that is exactly what i just did. I'll push that change

[nick-falco]

That speed enhancement sounds like a good idea. We probably should move these changes to a separate branch, instead of working on master, since it is going to require some more work/testing. I can reset master to an older commit and create a new pull request with these changes.

What do you think?

[nick-falco]

I moved these commits to a branch called _missing_stationtxtfields. Lets continue working on that branch so that we don't corrupt the mostly stable master branch.