mchedr2db [-v] [-A] [-p pf] [-a auth] [-f file] db
This script was tested on the USGS mine and explosion data, but should work on any mchedr format data. See ftp://hazards.cr.usgs.gov/mineblast/read_me for additional information on this particular bulletin.
Files are retrieved from the remote ftp site and stored locally. When this script is run, file update times on the remote ftp site are checked against the files that have been recovered and stored locally. If the remote update time is newer than the stored file, the file is retrieved (replacing the previous copy) and converted.
This is a new script that has not been rigorously tested. I recommend that you treat it as experimental and note that it may have problems that have not been uncovered in my simple testing. Use at your own risk! However, if you find it useful and have suggestions for improvement, let me know and I will consider incorporating them in my next round of changes.
# mkhedr2db.pf account # fill in with your email address, someone@somewhere.edu bulletins &Arr{ current_exp &Arr{ file mchedrexp.dat remote_host hazards.cr.usgs.gov remote_dir explosions local_dir /raid/bulletins/mine_files author NEIC_mines arrivals no } monthly_exp &Arr{ file ex.dat remote_host hazards.cr.usgs.gov remote_dir mineblast local_dir /raid/bulletins/mine_files author NEIC_mines arrivals yes } }
The user must define the type of bulletin they are collecting by naming the instance of mchedr files to collect. Each instance (i.e. current_exp and monthly_exp above) must have the following parameters defined:
an origin and arrival table.
% mchedr2db -A -f mchedr0801ex.dat jan_mines
mchedr_mines.pf file.
% mchedr2db -p mchedr_mines mines
bulletin2orb(1) pde2origin(1) qed2origin(1) scec2db(1)
Please consider using the bulletin2orb program instead of this one! bulletin2orb actually uses the netmag table.
This program has not been tested on any data other than the USGS mines and explosion data. I suspect it will work on other mchedr data files, but I have not confirmed this.
This program is more verbose than necessary.
I have many stray in-house blah2db programs that I am trying to consolidate into a useful framework. This program may disappear in the future as I move toward a unified approach to bulletin collection.
When creating arrivals, there are assumptions about the phase and what channel it was picked on. The mchedr does not specify a channel, so I impose the following mapping. All "P" picks are mapped to "BHZ"; "S" picks are mapped to "BHN"; "LG" picks are mapped to "BHN"; all others map to BHZ.
Magnitudes. Sigh. If the reported magnitude is ML or MB, the mapping is obvious. If the reported magnitude is LG, I chose to map this as an "mb" magnitude in the origin table. For reported "MD" magnitudes I force the origin table to use "ml". Other magnitude types are not translated, but you might get an error message. I have also seen events in the mchedr files that have no reported magnitudes. These are noted with a message like: "Can't parse magtypes: or ". I should probably broaden the possible mapping of magnitudes or allow this to be customizable in the pf.