===== TMTS in the NCSS Real-Time Systems ===== 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 (Mw). In addition to this real-time application, there is a [[postproc:tmts|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. == TMTS manual, offline operation == 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 [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. == TMTS automatic operation == 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: / / 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 [[rtem:appchan|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). {{rtem:tmts_dist.png}} * 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: - Quality Label: a single upper case letter to identify the Quality Rule - Quality Value: number between 0.0 and 1.0 associated with this Quality Rule, to be stored in database Mec table. - minTVR: minimum total percent variance reduction covered by this Quality Rule, between 0 and 100. - minSta: minimum number of stations required by this Quality Rule. - minIVR: minimum percent variance reduction for individual station. - 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//. === Configuration Parameters for Green's Functions === 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 [[rtem: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//.