This page contains the latest distribution of the complete mloc package. The archive unpacks into a directory structure containing all necessary source codes, compiler directions and data files. The distribution is served in a zipped archive.
The /mloc_distribution/ directory structure contained in the archive may be installed anywhere in the user’s file system, but it is strongly recommended that none of the directory or file names be changed until and unless the user has a thorough understanding of the mloc ecosystem.
The full version history of development of mloc is contained in the text file mloc_version_history.txt in the directory mloc_directory/mloc_src/. Recent entries are reproduced here, in reverse chronological order, along with any notes about changes to other elements of the distribution.
2020/10/7: Still having trouble with assigning the correct station coordinates to readings from ComCat. Even using operational epoch, too many duplicates are created that have to be sorted out. I’m trying a new strategy: finding the correct entry from neic_stn.dat as each reading is processed in mlocio_mnf.f90, using network/deployment code, station code, location code, channel code and operational epoch. This is only done if the command “nsmd” is turned on and, as before, it only writes a potential supplemental station file in the ~.log file. The user must still set up the actual supplemental station file for subsequent runs and reference it in the command file.
2020/9/29: I added support for operational epoch to the NEIC (isstn=5) supplemental station format. I also added reading of the location and channel fields for this format but they are not being used for associating station coordinates (yet).
2020/9/10: I wanted a way to efficiently change phase IDs for depth phases based on the analysis in subroutine rdp_depth_test (in mloclib_tt.f90). I wanted to reduce the problem of having viable (but incorrectly named) depth phases flagged as outliers by the normal cleaning process. The method is similar to the utility codes LRES or XDAT: create an output file listing the records that need to be changed in some way and read it with the utility, which first reads the corresponding MNF file into a buffer, makes the change to the appropriate record in the buffer, then replaces the MNF file with one written from the buffer. The new output file (written in rdp_depth_test) is called ~.dpnc (Depth Phase Name Change) and the utility code is also called “dpnc”. These name changes are subject to revision from run to run because of two main factors: (1) if phase re-identification is enabled the initial phase ID may be changed due to small changes in location, and (2) The action of dpnc is based on the results of the depth phase analysis but that does not necessarily correspond with the depth set for an event in the relocation. For example, actual depth used in relocation might be based on the DEPN or DEPL command. Then the actual residuals for a given depth phase will be different from the theoretically optimal ones calculated in the depth test. So this is not a full solution to the problem, but it may reduce it.
2020/9/8: I tried increasing the value of the parameter NTMAX1 from 40,000 to 80,000 because Ezgi was getting a compiler error in gfortran (with an old version) when she tried to do this for an especially reading-rich cluster. There was no difficulty under the Absoft compiler or gfortran v9.2.0 but I did run into a problem in mlocout_ttsprd.f90 because I was sloppy in the way I dimensioned a big array there. I was setting it to 200xNTMAX1 and this did lead to a segmentation fault, but there is no need to keep every instance of a given phase because the data are passed to the subroutine croux for analysis of the spread and it only uses the first 1000 samples. I also don’t need 200 possible phases. I never see more than 40-50 in the output file, so I reduced that to 100. For the standard distribution I am reducing NTMAX1 back to 50,000.
2020/8/21: I added the “cvid” command to permit an expansion or contraction of the entire cluster by a fixed amount. The need for this came up in the Gosht cluster in Iran, which covers an unusually large area (about 600 km across) and can only be calibrated indirectly using calibration events on the western and eastern edges. The misfit suggested that a slight expansion (~1.7%) was needed. This is presumably due to inadequacies of the theoretical TT model. I’ve never encountered a need for this before, but it might become more common if one is trying to calibrate (to some modest level) a large region between two calibrated clusters.
2020/8/19 (v10.5.2): I brought the logical function ‘phase_ok’ that was used in the conversion program ‘isc_ims2mnf’ into mloc (in mloclib_phases.f90), in order to deal with the problem of irrelevant phases (mostly magnitude-related) more effectively. Now this is checked for each phase record when it is read by the routine ‘read_mnf_13’ in mlocio_mnf.f90. I took the database of irrelevant phases out of the code and put them in a text file named ‘junk_phases.dat’ in a new /tables/phases directory. It is read on start-up, which makes it easier to edit the list. I added some minor sanity checks related to the new “full-range” depth tests and related plots.
2020/8/6: Some new output in ~.depth_phases to help analysis.
2020/8/3/: Fixed a bug in subroutine tt_rdp_summary (mlocout_gmt.f90) related to the recent rewrite of that routine. It was caused by zero-depth events, just a problem finding the plot boundaries. I also made some changes to the logging under command vlog to reduce the size of the output file and make it easier to find stuff that’s likely to be of importance.
2020/7/30: I rewrote the code (in mloclib_tt.f90) related to doing analysis of relative depth phases to handle focal depths over the full range 0-760 km. I also rewrote the plotting codes that deal with focal depths to handle the full depth range.
2020/7/18: I upgraded my gfortran from 4.9.2 to 9.2.0 and was presented with quite a few warnings and a few errors. The most serious ones were ancient code structures in libtau.f90, such as “arithmetic if”, “computed go to” and having a do loop end on an executable statement are now causing compiler errors. In the process of fixing those I went through the entire module and cleaned up the coding style a bit so it’s more readable now. I tested to make sure the new version of libtau.f90 yields the same results in a cluster as before, using both the Absoft and gfortran compiler versions. After working so much on the tau-p code I added the command “tlog” to carry out extensive logging of the tau-p calculations; it would only be needed for testing and debugging the tau-p code (libtau.f90). I also removed the “libtau.inc” include file from the project. It was left over from an earlier attempt to simplify the tau-p code, and was not actually used anywhere. Using the flags in the standard makefile for mloc, gfortran v9.2.0 now issues no warnings or errors. In late testing I discovered a bug in the routine topo_corr in mloclib_tt.f90 that screwed up the topographic correction for events in the ocean. It would return zero correction for both crust and water layer.
2020/7/14: A new user reported compile errors under gfortran (v10) for two routines in mloclib.f90 that simply change the case of a string to lower case or upper case. The problem was related to the use of “pure function” call, which is not necessary. However, neither routine is actually called so I simply removed them. However this raised the issue of mloc not being entirely compatible with recent versions of gfortran. I’ve been using a much older version (4.9.2) from around 2013.
2020/6/30: Fixed a couple bugs related to the routine “check_station” in mloclib_stations.f90. The stations that moved without changing station code were not being handled correctly.
2020/6/27 (v10.5.1): I removed several commands that have become obsolete: cvou, fplt, mdou, mech, puke. I added a command “ngmt” to be able to turn off all plotting in a case where GMT is not available.
2020/6/24: I added some logic in mloc.f90 to handle the case of a missing mloc.conf file more gracefully, and also added a mechanism to try to ensure that new users edit the sample file before running mloc. There’s a new keyword “SAMPLE” in the first line of the example file, with a reminder to edit the other keywords. mloc won’t run unless that line is deleted.
2020/4/22: Getting a segmentation fault with a cluster that had a lot of events with stations right on top of them. I think it was the section in subroutine delaz (mloclib_geog.f90) that handled zero epicentral distance. I was setting delta=0. when it got to be less than about 50 m. Setting the distance to a very small number (but non-zero) fixed the problem.
2020/4/10: In the Iwaki cluster I ran into a bug in mlocout_ttsprd.f90 where the number of P readings exceeded the hard-wired limit of 30,000. This didn’t break anything but produced a large number of warnings. I just set the limit of those arrays to be equal to the parameter that sets the limit for number of readings used (ntmax1).
2019/12/18: I changed the functioning of the RADF command, so that reading (and using) agency and deployment fields to resolve station code conflicts is restricted to specified station codes, not universal. In practice there are seldom more than a couple cases in any given cluster where agency and deployment codes are needed. Making sure that the entire dataset had correct specification of agency and deployment (to match whatever was in the station files) when you only need it for a couple readings from a single station was a nightmare. In fact, the code now uses the agency and deployment fields along with the station code for every comparison, but in most cases the fields are simply blank. RADF just specifies that those fields, both for station files and phase readings, will actually be read for certain station codes.
2019/12/5 (v10.5.0): Major changes in plotting, related to the adoption of GMT6, which has a nice new option for handling plotting of topography using the “@earth_relief_rru” option in grdcut. I was also running into trouble with the old .grd files when using GMTv6. Some of the GLOBE tiles were ill-constituted and are now breaking stricter requirements. Rather than try to fix my old .grd files I decided to abandon GLOBE and GINA as options and use ETOPO1 (the “01m” option from the GMT server) as the sole option for dem1. The new system also supports high-rez DEMs from SRTM but I have not yet experimented with that. ETOPO1 has a little less resolution than GLOBE but it still works well for basic plotting, and it will be easier to support since I don’t need to serve the data file. The argument to the command “dem1” is simply “on” or “off” now. It appears that the current plotting code will still work in GMT5 (with one exception) so that is still permitted. The exception is the call to grdcut, and for that there is a special loop for GMT5 there, referencing the old ETOPO1 file in /tables/gmt/dem/ETOPO. I also fixed a long-time annoyance with the .kml file. The symbols only displayed correctly if the directory is still in the working directory, so it could find the image files in the tables/kml directory. Now each cluster directory acquires a directory called “_kml” containing the necessary images and the .kml file refers to those, so it displays correctly as long as the .kml file is in the same folder with the _kml directory.