NCSS Wiki

TMTS (Trinet Moment Tensor System, although it was created long after the Trinet project had expired) is the AQMS software for computing moment tensors and moment magnitude (M_w). In addition to this real-time application, there is a web based TMTS system for computing moment tensors interactively. There is a lot of similarity between these two systems, as well as numerous differences. They also share a lot of C++ code and utility programs.

TMTS is by far the most complicated of all the AQMS programs. It has lots of things to do, and it invokes several utility programs along the way. This page will try to outline this complexity.

The program described here is tmts, located in /home/ncss/run/bin/tmts.

Note that like most AQMS programs, tmts writes (quite verbose) diagnostic output to two places. It writes a log file with the path and name prefix specified by the LogFile configuration parameter. And it also writes to stdout and stderr. Both of these streams need to be studied to analyze tmts behavior.

The configuration file /home/ncss/run/params/tmts.conf has lots of comments in it to assist you. Reading this file is encouraged. Some of it is duplicated here.

Besides running tmts in automatic mode as a CMS client, tmts can also be run manually for single events. This is useful for testing and tuning. Set up a configuration file for this with a name or directory that will not be confused with the automatic tmts on the RT system. In the configuration file, set Mode to offline. Specify an event ID on the command line:

tmts <configuration file> [event id]

This will cause tmts to perform all its operations on the specified event ID, leaving its intermediate and final results in the directory specified with the ResultDir parameter in the configuration file. No CMS signals will be sent by tmts in offline mode. If the moment tensor solution meets the quality rules in the configuration, it WILL write its solution to the database. You can avoid this by setting configuration parameters to minVRforAutoSave and minVRforAutoPrefMec to 100 for testing.

To run tmts in automatic mode, the command is:

tmts tmts.conf

When properly configured, tmts will create its log file; open a connection to CMS; and subscribe to the configured EventSubject subject. When a CMS message of this subject arrives, it will be decoded for an event ID. The following actions will occur:

• Query the database for event time, latitude, longitude, depth, azimuthal gap, preferred magnitude, its type, uncertainty and number of contributing stations. If there is no preferred magnitude, or if the preferred magnitude does not meet the rules configured by one or more MinMag parameters, this fact is logged, a TMTS Done message is sent to CMS, and tmts goes back to listening for the next CMS message.

• Set up the list of eligible list of wave servers from the configured WSloc parameters. The eligible list contains servers for which the event age limits are met.

• Setup the result directory structure:

  <ResultDir>/
       <eventID>/            copies of Green's function files, logs from prepdata
            mseed/           raw miniSEED files
            processed_sac/   sac files from each processing step
            pz/              gain-pole-zero files
            sac/             raw sac files converted from miniSEED
            tmp/             output from tdmt, plot files

• Query the database for the list of channels in the AppChannels table for the configured DBProgramName. Query the database for instrument response (gain, poles, zeros) for each of these channels. Group channels (SNCLs, really) by station since they will be handled that way from now on.

• Remove from the station list those stations outside the distance limits computed from the event magnitude and the configured with parameters MinDistAtZeroMag, MinDistPerMag, MaxDistAtZeroMag, MaxDistPerMag. These rules select stations whose waveforms are likely not to be clipped (too close) and will likely contain sufficient event signal (not too distant).

• Remove stations listed in the configured StaFilterFile, the so-called Station Black List. Note that this station filter file is read only at startup. If the file is changed, tmts must be restarted in order to see the changes.

• Compute the time at which waveforms containing event information are expected to be ready. The comments in the configuration file explain this:

# The following ASCII diagram shows the various Waveform times.
# The time axis is vertical with increasing time upward
# On the left are the various points of time.
# On the right are various time intervals
# Waveforms can be requested after the end of the interval
# called latency_time.
# The request for waveforms will cover the time from
# prelimDataStartTime to prelimDataEndTime. This waveform segment will
# be presented to SAC for processing. By the end of the SAC processing
# the waveform will be truncated to the interval between dataStartTime
# and dataEndTime. This truncation is used to cut off any transients
# that may be induced by the SAC processing.
#
# All of the time intervals must be non-negative.
# data_dur is normally 300 seconds.
# The other values can be adjusted for optimal performance.
#
#
# code variables               configuration parameters
# --------------               ------------------------
#                       |
#                       |
#                       |--|
#                       |  |-- latency_time
#                       |  |
# prelimDataEndTime     |--|----|
#                       |       |--postProcessTime
# dataEndTime           |--|----|
#                       |  |
#                       |  |-- data_dur
#                       |  |
# originTime            |--|--|
#                       |  |  |-- pre_event_time
# dataStartTime         |--|--|
#                       |
# noiseEndTime          |----|
#                       |    |
#                       |    |
#                       |    |
#                       |    |
#                       |    |
#                       |    |
# noiseStartTime        |----|--|
#                       |       |--preProcessTime
# prelimDataStartTime   |-------|
#                       |
#                       |

• If waveforms are not ready yet (current time has not reached the end if the interval labeled latency_time in the diagram), tmts sleeps until this time has expired.

• When sufficient time has passed so that waveforms are expected to be ready, proceed with the solution search loop, actually several nested loops. The outer most loop iterates over each of the configured QualityRule parameters. If the event magnitude is less than configured MinMagForTopQuality, the first QualityRule is skipped.

• As described in the configuration file, each quality rule consists of the following parameters:
  1. Quality Label: a single upper case letter to identify the Quality Rule
  2. Quality Value: number between 0.0 and 1.0 associated with this Quality Rule, to be stored in database Mec table.
  3. minTVR: minimum total percent variance reduction covered by this Quality Rule, between 0 and 100.
  4. minSta: minimum number of stations required by this Quality Rule.
  5. minIVR: minimum percent variance reduction for individual station.
  6. spreadAZ: flag to indicate (1) stations selected to achieve a spread of azimuth values; or (0) stations selected without regard to azimuth.

• If the current quality rule requires azimuthal spread for station selections, the following steps are performed:
  • Start with the number of azimuth sectors equal to the number of stations required by the quality rule.
  • Try to find one station per sector with good data: if there are more than one station, choose the one with best VR (from previous iteration), or choose the one closest to 60 km (no explanation in code for this distance).
  • Get and process waveform data for selected stations:
    • Select Green's Functions, using filter band for event magnitude, and the closest distance to that of the station.
    • Write the station's pole-zero file.
    • Get miniSEED data from selected wave servers, writing out miniSEED files for each channels.
    • Convert data to SAC format using ms2sac.
    • Check that the SAC file is readable and has start and end times covering the configured time span. Trim the file if necessary, and update SAC header times.
    • Check SAC data to see if it exceeds configured clipThreshold.
    • Check channel orientation: must have 1 vertical channel, and a total of three mutually orthogonal channels.
    • Run tmts_prepdata script: remove mean, remove instrument response using pole-zero file, integrate to displacement, rotate horizontal components to radial and transverse, cut waveforms to dataStart and dataEnd times and optionally a segment from noiseStart to noiseEnd times, run optional SNR test, convert SAC data files to Helmberger format, move them to processed_sac directory.
  • And station that fails any of these steps gets marked have having INVALIDDATA, and will not be used again for this event.
  • If can't find enough stations with good data, increment number of sectors and try again. At 80 sectors, give up on this quality rule and try the next one.
  • When there are enough stations with good data, compute moment tensor at each of the Green's Function depths:
    • Write input file tmp/mt_inv.in, containing the list of station data files and Green's Function files.
    • Run “tdmt_inv_iso 2> tdmt.err”. Output of tdmt_inv_iso is collected in tmp/mt_inv.out for each of the depths. tdmt_inv_iso will also write a data file plot_dDEPTH.dat which contains both the actual and synthetic waveforms used for the inversion.
  • Read mt_inv.out to find best depth: the one with the largest VarRed (Variance Reduction).
  • Reject stations whose individual VR does not meet Quality Rule's IVR limit.
  • For events where the origin's azimuthal gap is less than configured MaxGapForZcorrRule, remove stations whose Zcorr is more than expZcorrTol from expected Zcorr: dist * 0.13 + 1.42 * preEventTime.
  • If total VR meets the TVR limit for this Quality Rule, make plots of VR vs depth, VP vs depth, and waveform mechanism plots, using the data files generated by tdmt_inv_iso.
  • If stations were dropped, try station selection again at the same number of sectors.
  • If no stations are dropped and total variance reduction meets the current Quality Rule, break out of loops.
• If the total variance reduction meets the configured minVRforAutoSave, save the moment tensor and magnitude to the database. This includes some data files and the prepared text of email. Note that this step DOES NOT set the moment tensor to be the preferred mechanism for this event. Send a CMS message with the configured MagSubject for the Mw magnitude.
• If the total variance reduction meets the configured minVRforAutoPrefMec, set the saved mechanism to be the preferred mechanism for the event. Send a CMS message with the configured MecSubject for the moment tensor mechanism.
• For all events, send the TMTS Done message to CMS with the configured DoneSubject.

There are several parameters in the tmts configuration file having to do with Green's Function files used by tmts. For NCSS, Doug Dreger has computed Green's Function files using three different velocity models appropriate for regions of California. The Green's Functions are computed at 14 depth values ranging from 1.5 to 39.0 km; and for 174 distance values: 30 to 895 km at 5 km intervals. The Green's Function files are filtered at three different filter bands, appropriate for magnitude ranges. The Green's Function files are stored in three directories named for the filter bands.

• GFDir Directory where Green's Function files are stored.

• GFRegions Green's Functions region file's full path. This file includes the name of the velocity model, the geographic coordinates of the region for which it is applicable, and the name of the file listing the distances available for that model. The exact text of the velocity model name, and the depth values are parts of the name of each Green's Function file.

• GFDepths Green's Functions depth tile's full path. This file lists the depths for which the Green's Functions have been computed.

• BandFile The name of the Green's Function filter bands file, to be found within GFDir. This file lists the name of the filter band, the largest magnitude for which the filter band is to be used, the low and high corner frequencies in hz, and the correlation length to be used with the filter band.

• BandDir It is possible, but rarely used, to configure tmts to use this configured filter band instead of selecting the band based on event magnitude. This might be used for off-line testing of tmts with specified Green's Functions.

An example of a Green's Function file is gil7_30d14.0.bin. The first part of this name comes from the velocity model “gil7_”. The distance is “30”; the depth is “14.0”. The “bin” suffix indicates that the file has be converted from ASCII format to binary format, so save disk space and speed up reading the file.

The current set of Green's Function files were computed by Doug Dreger in August, 2017. A copy of the package that he provided is on rodgers.geo.berkeley.edu, in /home/ncss/run/tmts/iso-synth/BSL_MT_GFS.

There is a collection of tmts utility programs in the /home/ncss/run/tmts/bin directory on each system running tmts. Many of the programs are run directly by tmts. A few others are used by the alarm action scripts used for publishing moment tensor results. The program “gfa2b” is used to read ASCII Green's Function files and write binary format. It reads from stdin and writes to stdout.