Query on the SpecFEM3D Cartesian Moment Tensor Convention and the Real World Examples using CMTSOLUTIONs from the USGS Finite Fault Models

[dsgf-tough]

Good day,

I am writing here to ask about the moment tensor convention used in the CMTSOLUTION input for SpecFEM3D Cartesian, as well as the Real World examples using CMTSOLUTIONs from USGS Finite Fault Models.
I’ll note the manual, previous discussions, some checks that we ran, and the codebase handling the CMT in this discussion.
(Apologies in advance for the long text.)

Documentation:

• Based on the documentation, the GCMT / Harvard / RTP convention is used for CMTSOLUTION files. In the version 4.1 of the user manual (January 10, 2024), page 41 indicates that the CMTSOLUTION file from GCMT can be used directly:

• Furthermore, figure 5.1 in the following page goes into detail on the file format used, showing the RTP convention:

• In appendix A, the manual also mentions the difference among the GCMT convention, the Aki and Richards (1980) North-East-down XYZ convention and the cartesian XYZ convention.

Discussion:

• In several discussions in the Issues section of the repository, it is highlighted that the CMTSOLUTION always uses the RTP convention. The conversion between the RTP and the cartesian XYZ conventions is also given by danielpeter.

#1439

#1453

• In an older discussion, this is also the case, as such Aki and Richards (1980) convention should be converted into the GCMT convention as per komatits:

#977

Checking Examples (A):

For further checking, the examples under specfem3d/EXAMPLES/real_world/ can be consulted.

• For Mendocino_Mw7.0, the USGS entry for the earthquake in California (2024-12-05 18:44Z) is linked. It shows a strike-slip fault plane solution appropriate for the transform faulting present in the Mendocino Triple Junction.

• The finite fault solution represented by multiple CMTSOLUTION points can be downloaded from its corresponding USGS FF page. Comparing with the CMTSOLUTION file in the DATA folder of the Mendocino example, the content is the same. At first glance, each of the 240 sub-fault entry follows the CMTSOLUTION format, including labels that indicate the use of the RTP convention:

• However, plotting the moment tensors shown (in RTP), the resulting plots and strike-dip-rake tables indicate a vertical dip-slip mechanism, not the strike-slip that is expected for the event:

• For comparison, the GCMT moment tensor for the same event is shown below:

• As it can be seen the moment tensor is very different, as evidenced by the location of the positive and negative signs. The GCMT moment tensor produces the correct plot and strike-dip-rake values:

• Going back to the USGS Finite Fault solution, if it is assumed that the CMTSOLUTION file is actually in the Aki and Richards (1980) North-East-Down convention (despite the RTP labels), following the Mnn, Mee, Mdd, Mne, Mnd, Med order (which can also be expressed as Mxx, Myy, Mzz, Mxy, Mxz, Myz; as Aki and Richards’ x = north, y = east, z = down), like so:

• Then apply the conversion from Aki and Richards (1980) to get the correct RTP components, using the established formulae in the CMTSOLUTION_toAkiRichards.c script in utils/CMTs:

• Then finally reorder the resulting components based on the CMTSOLUTION RTP sequence (Mrr, Mtt, Mpp, Mrt, Mrp, Mtp), the resulting plots become consistent with the expected mechanism for this event:

• Note that the conversion and the sequence change steps above can be simplified as shown by the code in the all-in-one CMT conversion tool in utils/CMT:

• And as illustrated below:

Checking Examples (B):

• To verify if this is not an isolated case, another example can be checked, the Myanmar_Mw7.7 event under the EXAMPLES/real_world, the USGS page for the 2025-03-28 06:21Z earthquake shows another strike-slip event:

• The USGS Finite Fault page for the event is given in this link

• Comparing with the CMTSOLUTION file in the DATA folder of the simulation, the file in the USGS page has been updated, with nearly twice the sub-fault entries:

• Regardless, plotting either one of them also hints at a North-East-down convention instead of the GCMT convention as the plots and strike-dip-rake values indicate a vertical dip-slip mechanism instead of the expected strike-slip faulting. Latest USGS FF:

SpecFEM3D-Archived USGS FF:

• Like before, if the CMTSOLUTIONs from the USGS Finite Fault Model are assumed to actually be in North-East-down convention, and applying the appropriate conversions to the RTP convention, the resulting files produce apt plots and strike-dip-rake values. Converted Latest USGS FF:

Converted SpecFEM3D-Archived USGS FF:

• The GCMT solution for reference:

• Subjected to the same plotting script:

Own Test Case:

• When we performed our own simulations, we used an available multi-point CMTSOLUTION from the USGS Finite Fault Model. The finite fault page is given in this link. However, observations have led us to the same conclusion regarding the moment tensor convention used. The USGS entry for the 2022 July Northwestern Luzon, Philippines earthquake (2022-07-27T00:43) shows reverse faulting:

• The resulting plots and strike-dip-rake values for the CMTSOLUTION from the USGS Finite Fault Model, without conversion:

- Wavefield snapshot (Z component), clearly showing a NW-SE trending nodal plane:

• The resulting plots and strike-dip-rake values for the same CMTSOLUTION but now subjected to NEd to RTP conversion:

- Wavefield snapshot (Z component), showing the NE-SW trending nodal plane, apt for the event:

• The resulting plots and strike-dip-rake values for the GCMT solution, for reference:

• Putting all of these together, it would appear that the CMTSOLUTIONs from the USGS Finite Fault Models are likely using the Aki and Richards (1980) North-East-down convention, and not the RTP convention. This is a major hurdle as the examples in the real_world directory that do use double-couple CMTSOLUTIONs from past earthquakes use the USGS Finite Fault solution, making it difficult to determine what is the correct CMT convention for SpecFEM3D inputs. Meanwhile, examples from other folders appear to use “test” CMTSOLUTIONS without counterparts from past events to compare them to.

Codebase:

• Looking at the source code, the get_cmt.f90 routine appears to parse the CMTSOLUTION with the GCMT convention as evidenced by units in dyne-cm and presence of RTP components:

• Furthermore, there in another routine, locate_source.f90, a conversion from the RTP to the cartesian XYZ convention is made:

• Like the documentation and past discussions, these indicate that the CMTSOLUTION inputs do use the RTP convention.

Queries:

Given these, I would like to verify if my understanding is correct:

1. That CMTSOLUTION inputs should use the Harvard / GCMT / RTP convention, with moment tensor components in order: Mrr, Mtt, Mpp, Mrt, Mrp, Mtp
2. That SpecFEM3D internally handles the conversions of the moment tensor components to the cartesian XYZ reference frame, and the necessary re-ordering of components

Furthermore, I'd like to ask:
3. If SpecFEM3D handles multi-point CMTSOLUTIONS differently, or if they too should conform to the convention as in 1.
4. If anyone else can check if the USGS Finite Fault solutions are actually using the Aki and Richards (1980) / North-East-Down convention, or if they do match the RTP convention

• According to the finite fault page of USGS, the CMT Solution is a

Full CMT solution for every point in the finite-fault region, in CMTSOLUTION ASCII text format (Dziewonski, Chou, & Woodhouse, 1981; http://globalcmt.org)

• This would explain the file format appearing like in GCMT, including the RTP labels, but not the moment tensor differences shown earlier. I currently can't find any documentation explicitly mentioning the moment tensor convention used for the CMTSOLUTION files from the USGS Finite Fault Models.

Many thanks.

Sincerely,
Dan

[danielpeter]

hi Dan, thanks a lot for your report and diligence in checking the CMT solutions!

regarding your understanding, both point 1 and 2 are correct. for point 3, the finite-fault CMTSOLUTION files (multi-point as you call it) use the same Harvard convention. there is no special handling between single or multiple CMTs.

so far, SPECFEM3D expects the Harvard (globalCMT) convention as input. that means I need to fix the USGS CMT examples... when setting up the real world examples, I assumed that the USGS solutions would be provided in this format. however, as you point out above, it seems more like they used the Aki&Richards convention - thus, i fell again into one of these convention traps :(

i'll check and update the examples accordingly. it would probably be easiest by just adding a parameter flag in the Par_file to point out that the CMT is using the USGS (Aki&Richards) convention. that way, we could use the original finite-fault files provided by USGS as inputs.

thanks for pointing out!

[dsgf-tough]

Thanks for the answer, danielpeter,
Glad to help

We definitely had our head-scratching moments when we first used the USGS FiniteFault CMTSOLUTION files in our study areas
As for handling various CMTSOLUTIONs, I agree that having that flag in the Par_file would be a clean solution

[danielpeter]

This is just to confirm your suspicions of the finite-fault CMT convention: the USGS finite-fault CMTSOLUTION files currently use the North-East-Down ('NED' which is Aki & Richards) convention. this stems from their use of the obspy mopad script default setting when creating a MomentTensor object.

Emanuele (@casarotti) recently noticed a similar inconsistency, did some detective work and asked USGS about it. He was pointed to this routine responsible for the USGS finite-fault CMTSOLUTION output:
https://code.usgs.gov/ghsc/neic/algorithms/neic-finitefault/-/blob/main/src/ffm/eventpage_downloads.py?ref_type=heads#L206

Emanuele noticed in particular the lines

MT = mopad.MomentTensor([STRIKE[ksubf], DIP[ksubf], RAKE[ksubf]])
MT = array(MT.get_M())

which creates the moment tensor MT using the 'NED' (North-East-Down) convention by default. the Harvard convention would be 'USE' (Up-South-East) instead and require

MT = array(MT.get_M(system='USE'))

Unless the USGS is willing to change this for their finite-fault products, it looks like we have to live with the finite-fault solutions be given in the Aki & Richards convention.

[danielpeter]

addressed by PR #1877

[dsgf-tough]

Thank you for this addition, danielpeter
I think all of my queries for this discussion are all addressed
Much appreciated

[rintaro-enomoto]

My name is Rintaro Enomoto, and I am a graduate student at Kyoto University. I have been using SPECFEM in my research and greatly appreciate the efforts of everyone involved in developing and maintaining this valuable software.

I would like to follow up on the discussion above. In pull request #1877, it appears that DATA/Par_file was not updated. I tried adding the following line to DATA/Par_file:

CMT_CONVENTION_FORMAT = NED

With this addition, I think the code worked as expected.

I am also wondering whether a corresponding update could be made to SPECFEM3D_GLOBE, as other users may also wish to use finite-fault files provided by the USGS.

Thank you,
Rintaro