CMTSOLUTION parsing does not interpret dates correctly (issue with formatting/whitespace handling)

[amkearns-usgs]

Avoid duplicates

• I searched existing issues

Bug Summary

Reading in some CMTSOLUTION files in obspy produces errors where the full date is not parsed in correctly. This appears to be an issue with how obspy expects the first CMTSOLUTION file's line to have its whitespace formatted, leading it to miss the first digit of the year in certain cases, and thus leading to, ex., 2022 only having 022 parsed in, thus claiming the correct year is 22.

An example of a CMTSOLUTION first line that produces this issue is this one:
PDE 2022 12 04 19 24 15.20 -15.40 -172.97 36.0 0.0 6.7
The problem appears to originate from the first field, which here is 3 characters, as the code in obspy appears to expect a 4-character value only, per the first few lines of _internal_read_single_cmtsolution:

obspy/obspy/io/cmtsolution/core.py

Lines 145 to 158 in 9659cf3

	def _internal_read_single_cmtsolution(buf):
	"""
	Reads a single CMTSOLUTION file to a :class:`~obspy.core.event.Catalog`
	object.
	:param buf: File to read.
	:type buf: open file or file-like object
	"""
	# The first line encodes the preliminary epicenter.
	line = buf.readline()
	hypocenter_catalog = line[:5].strip().decode()
	origin_time = line[5:].strip().split()[:6]

I'm willing to fix this issue myself, as it should be a simple task, mainly rewriting that method to perform the string split() method before doing anything else on the line, and then dealing with each of the fields as necessary.

Code to Reproduce

No response

Error Traceback

No response

ObsPy Version?

1.4.0

Operating System?

tested on Ubuntu and MacOS (but should be an issue in any version)

Python Version?

3.9.16

Installation Method?

conda

[aringler-usgs]

Here is an example for @amkearns-usgs bug.

import obspy
cat = obspy.read_events("CMTSOLUTION")[0]
print(cat)

Here is the relevant output:
Event: 0021-01-03T12:38:52.070000Z | +51.120, -179.780 | 6.04 mw

Here is the file: (CMTSOLUTION.TXT)

[QuLogic]

The format is fixed field width, not space separated, as defined in https://www.ldeo.columbia.edu/~gcmt/projects/CMT/catalog/allorder.ndk_explained Unless there is some new standard, those files are invalid, and ObsPy is parsing it "correctly" (or rather, as best it can.)

[aringler-usgs]

@QuLogic Thanks for your help. The link appears to be for ndk format and not CMTSOLUTION format (CMTSOLUTION format is the one we are having issues with). Or are we missing something?

[QuLogic]

That's true. Looking back at the history, there's not much of a formal definition and that's really the only reference we have. We can't just split on space as there are files with the first field that aligns up to the next field: #1479.

Our only other reference is SPECFEM3D, and it looks like while they previously used a fixed field width, they've had to move to some complicated heuristic which I guess we'll have to replicate.
https://github.com/SPECFEM/specfem3d/blob/7ab2414052ea4f35752821a1e137ac94c9aa7b59/src/specfem3D/get_cmt.f90#L105-L115

[megies]

they've had to move to some complicated heuristic which I guess we'll have to replicate.

🙈

I'm willing to fix this issue myself

Feel free to go ahead and make a PR 👍