No data for MKAZ and KBAZ for Jan 2016

[carolinelittle]

A user has emailed to say they can't retrieve waveform data from FDSNW or CWB for stations MKAZ and KBAZ for Jan and Feb 2016.

I've had a look at request tracker, and MKAZ's spotty reception might explain some loss (or not). But there's nothing there that would explain KBAZ.

@quiffman, can you get someone take a look?

[ozym]

Didn't a tree fall on it?

[carolinelittle]

It did! but that was 2 years ago

[rumachan]

But no KBAZ for all of 2016.

[carolinelittle]

@rumachan Thanks for the answer re KBAZ.

Do you know if there are lost data for MKAZ from the spotty reception?

[filefolder]

hi there- i am the aforementioned user trying to access data for these sites.

does anyone know if KBAZ and MKAZ are currently recording data (as of right now) that will eventually (~next few months) be available online? or are they not recording at all? just checked again, nothing online for either.

we are planning a small temporary array in the greater Hauraki rift / Coromandel area but without those sites recording we may wait.

thanks

[rumachan]

MKAZ = yes, KBAZ = no

I can see MKAZ data, don't know why you can't. All data are available as they come in, there is no 'eventually available online'

[filefolder]

thanks, ok. is there an ETA on KBAZ's return?

as far as MKAZ, finally got it to work after many attempts. i suspect i am having a formatting issue with the CWB utility.

according to the CWB directions on geonet using the -s "NZMKAZ" flag will download all data in NZ/MKAZ but that doesn't work for any sites, the -s flag string is quite particular.

for example, site ABAZ which works fine (IF the search string is padded to the full length of NZSSSSSCCCLL)

$ java -jar /installed/GeoNetCWBQuery-4.2.0-bin.jar -d 1d -b "2016,270-13:00:00" -t ms -s "NZABAZ....10" Using default logging configuration. 22:50:33.370Z Query on NZABAZ EHE10 014574 mini-seed blks 2016 270:12:59:56.9083 2016 271:13:00:01.468 ns=8640457 22:50:34.382Z Query on NZABAZ EHN10 014791 mini-seed blks 2016 270:12:59:58.7483 2016 271:13:00:03.498 ns=8640476 22:50:35.483Z Query on NZABAZ EHZ10 014997 mini-seed blks 2016 270:12:59:55.1783 2016 271:13:00:04.098 ns=8640893 44362 Total blocks transferred in 4077 ms 10881 b/s 0 #dups=0

but same query for MKAZ, nope

$ java -jar /installed/GeoNetCWBQuery-4.2.0-bin.jar -d 1d -b "2016,270-13:00:00" -t ms -s "NZMKAZ....10" Using default logging configuration. *\ Unexpected EOF Found

limit the search to channel Z, still no

$ java -jar /installed/GeoNetCWBQuery-4.2.0-bin.jar -d 1d -b "2016,270-13:00:00" -t ms -s "NZMKAZ...Z10" Using default logging configuration. *\ Unexpected EOF Found

but if now limit to channel *HZ, it works

$ java -jar /installed/GeoNetCWBQuery-4.2.0-bin.jar -d 1d -b "2016,270-13:00:00" -t ms -s "NZMKAZ..HZ10" Using default logging configuration. 22:52:28.172Z Query on NZMKAZ HHZ10 014163 mini-seed blks 2016 270:12:59:55.8083 2016 271:13:00:06.588 ns=8641079 22:52:28.500Z Query on NZMKAZ LHZ10 000340 mini-seed blks 2016 270:12:59:33.0695 2016 271:13:04:40.070 ns=86708 14503 Total blocks transferred in 1829 ms 7929 b/s 0 #dups=0

not sure why? but i can obviously work around it

[rumachan]

Have asked about KBAZ ETA. It has been down a long time so there might be a particular reason, not just that no one has got round to it.

[carolinelittle]

I think the hold up with KBAZ is that we require a new permit with Auckland Council to build a new cabinet...

[rumachan]

The repair to KBAZ has been put on hold while the technical team concentrate on a big project upgrading the cGPS receivers around the country. It was 'destroyed' when part of a tree fell on the site, if I recall correctly. If we decide to prioritise the work, then it would still take a few months as, as @carolinelittle points out, a new permit from Auckland Council is required because we intend to alter the housing of the gear at the site.

What are the time constraints on your temporary array?

[filefolder]

the array will be up for a year give or take; if the KBAZ repair was going to take a ~month we might have waited but it's not a large issue.

the larger issue was MKAZ; luckily it is back up as that site is in a valuable location.

thanks all!

[ozym]

The CWB error message: *** Unexpected EOF Found was indicating a fault with the server (most like a memory issue, or a number of files open problem). The server has been restarted so these queries should now work, I've tested one and its giving me data.