search

PIC-IRIS / PH5

Library of PH5 clients, apis, and utilities
Other
15 stars 9 forks source link

[BUG] segdtoph5 creating multiple array table entries for each station #476

Closed ascire-pic closed 2 years ago

ascire-pic commented 3 years ago

segdtoph5 is creating an array table entry for every file instead of creating one entry that covers the entire deployment of that Smartsolo.

For example: station 2060 (SmartSolo serial number 5477) was deployed from Sept 28 through Oct 8. The array tables has entries with the following deploy and pickup times for channels 1,2,3 (this is just a selection, there are more): Deploy: Tue Sep 29 16:23:45 2020 Pickup: Wed Sep 30 16:23:45 2020 Deploy: Wed Sep 30 16:23:45 2020 Pickup: Thu Oct 1 16:23:45 2020 Deploy: Thu Oct 1 16:23:45 2020 Pickup: Fri Oct 2 16:23:45 2020

Data files added to ph5 using segdtoph5 (again, subset of the list): 453005477.2.2020.09.29.16.23.45.000.N.segd 453005477.3.2020.09.30.16.23.45.000.N.segd 453005477.4.2020.10.01.16.23.45.000.N.segd 453005477.5.2020.10.02.16.23.45.000.N.segd

Version: 2021.159 Usage: segdtoph5 [options]

Sample archive using 2 stations on ph5 server in: /external/ph5/Working/HC_Seismic/array-table-issue

Station 2060 (SmartSolo 5477) should have one array table entry for each channel: Deploy: Mon Sep 28 20:39:24 2020 Pickup: Thu Oct 8 19:53:45 2020

If a second SmartSolo was deployed at this same station (station 2060, SmartSolo ????), a second set of array table entries for that station for each channel should exist with the appropriate deploy and pickup times.

timronan commented 2 years ago

@ascire-pic has this issue been resolved?

If a second SmartSolo was deployed at this same station (station 2060, SmartSolo ????), a second set of array table entries for that station for each channel should exist with the appropriate deploy and pickup times.

I am fairly positive the quote above will lead to invalid stationxml being output from the PH5 experiment. It seems like this issue breaks stationxml validation rule 111:

Station:Epoch cannot be partly concurrent with any other Station:Epoch encompassed in parent Network:Epoch.

ascire-pic commented 2 years ago

@ascire-pic has this issue been resolved?

If a second SmartSolo was deployed at this same station (station 2060, SmartSolo ????), a second set of array table entries for that station for each channel should exist with the appropriate deploy and pickup times.

I am fairly positive the quote above will lead to invalid stationxml being output from the PH5 experiment. It seems like this issue breaks stationxml validation rule 111:

Station:Epoch cannot be partly concurrent with any other Station:Epoch encompassed in parent Network:Epoch.

Sorry, I wasn't clear in my description. If a second SmartSolo is deployed at that station location during a different time period (for example, the first SmartSolo is turned off and removed and is replaced by a new instrument with a full battery). You are correct that having two entries in the array table for the same station that overlap would throw a flag when validating the XML. If that happens we should catch it during validation and resolve the problem. The manufacturer's software should also catch it and should not allow this sort of overlap, but if it slips through we will catch it when we write out the stationXML and validate it.

ascire-pic commented 2 years ago

Issue resolved in PR 479 which is merged.