Scrtdd - workflow suggetsions

1

I have started a workflow on a research seiscomp system tied to a production system. On the research system I’ve got scrtdd operating, and am very happy with it. I’m trying to decide the best option moving forward for keeping an to date base DD catalog for performing real time single event relocations.

This research system receives events from a production system. The production system has automated solutions that are reviewed by analysts, as well as analyst derived events. These get passed to my research system as xml files, and then are dispatched into my research system’s database.

For a specific region, I have an scrtdd profile. Events within this region, I want to relocate with scrtdd.

I have created by base catalog by using the multi-event mode of 20 years worth of past events in this area. This input catalog, complete to 2025-10-31 was used to make my base DD catalog. I am now wanting to relocate in real time new events that fall in that region.

I have pointed the scrtdd profile for this region to the CSV triple (reloc-event, reloc-phase, reloc-stations). It is working, and relocating the new events since 2025-11-01 in real time. It is configured that these relocations get added as new, preferred origins, to the corresponding event in the database, and I can see all this in scolv.

My question is now specifically, what is the reasonable way to update my DD base catalog periodically. My reasoning would have been to use sclistorg to update my original list of originIDs to make the base catalog, with all new originIDs that fall in the same region. However, for all the new events coming into the seiscomp system, the originIDs that will be found by sclistorg will be the real-time scrtdd origin, rather than the analyst origin, as was used in the original DD base catalog.

In this regard, does it matter that going forwards I would be re-creating my base catalog using the rtdd origins produced by single event relocation on new events, or should I instead be consistent and always derive my “base catalog” from the preferred “analyst origins”?

@luca.scarabello, I’m curious your take on this question, if you have the time. I didn’t put this on the GitHub page, as it isn’t a code issue at all. I have gone through the GitHub pages and documentation, and wasn’t sure if there was a suggested approach here.

I suppose one option is that I don’t add the single event relocations into the main seiscomp database at all, and instead I just dump them into xml files for external plotting. It is quite nice to be able to see this in seiscomp though.

Perhaps another option is to put the scrtdd single event relocation solutions into a separate seiscomp database?

Thanks for any insights on this, and big thanks for such a great and well configured tool!

2

Forgot one detail to add here.

The way I found to keep my list with only manual solutions was to add
—org-type last —manual-only
To my sclistorg command, and this would skip any of my rtdd solutions for the last (ie, most recent) manual analyst solution.

My bigger picture query, is rather, is it ``better’’ (subjective I know) to update the original DD base catalog (created using only analyst origins) using the new analyst origins, or, use the preferred origin, for which all origins starting after the creation of the first base catalog will be rtdd origins.

3

Your current approach of periodically updating the background/reference catalog using sclistorg --org-type last --manual-only makes sense and is a valid choice.

Now, on the more subjective side: At SED, we decided not to set scrtdd origins as preferred. The scrtdd origins are part of the event, but they’re not marked as preferred. They can be visualized in our internal web map as an alternative to the traditional absolute catalog. We also build the scrtdd background/reference catalog by always starting from manually reviewed events (the preferred ones).

Had we chosen to set scrtdd solutions as preferred, we would have created inconsistencies between how the earthquake catalog has been generated in the past and how we now use scrtdd. In this way, the real-time catalog generated by scrtdd becomes an additional product that complements the traditional absolute location catalog (which uses NonLinLoc).

Another minor issue with setting scrtdd solutions as preferred is that, as soon as you compute the next background/reference catalog, these real-time single-event scrtdd solutions become outdated. In my view, the scrtdd catalog is a dynamic catalog that is better used as a complementary resource.

By the way, I use this script to run the periodic update of the background/reference catalog, in case you haven’t seen it: generate-background-catalog.sh.

4

Thanks @luca.scarabello , this was exactly the advice I was looking for.

I am essentially creating a copy of the formal catalog (NRCan Canadian Database) on my local research machine. So while backwards compatibility and consistency is not quite as important, I would still prefer to maintain consistency with the official catalog.

Even if I am assigning my relocated solutions as preferred, at least I can still pull the latest manual orgin using that combination of flags with sclistorg.

I like the idea of how you sort your solutions, especially in the circumstance where multiple rtdd origins exist for a single event. What is your workflow for adding the scrtdd solutions into the catalog? As far s I can see in the scrtdd configuration files, there is no explicit option of disabling setting the rtdd solution as preferred.

How do you handle automatically adding the rtdd solutions into your database automatically, but then not setting them as the preferred origin? Do you use configuration settings in scevent instead to control keeping manual solutions preferred over automatic ones, so even when a new RTDD solution comes in, either with a “A” evaluation or a RTDD method (as oposed to LOCSAT or NonLinLoc)?

Thanks very much for your help and quick reply.

I have seen your script, and I am looking to implement it within my own system. I’m also looking at the internal map web page addition.

Thanks,
Andrew

5

We use the scevent configuration to prevent scrtdd solutions from being set as preferred. Specifically, we rely on the authors option, where scrtdd has lower priority than the other locators, and on the agencies option, where scrtdd uses a different agency string with lower priority. (This is somewhat redundant, but my colleagues prefer having a separate agency ID for scrtdd for other purposes.)

To give you the rest of the picture: we currently rebuild the background/reference catalog on a weekly basis. On our internal webpage that displays the scrtdd solutions, we show the latest background catalog plus the last week of real-time scrtdd solutions, which are not yet included in the background catalog. One week later, those same real-time events are displayed using the background catalog data, since they become part of the next relocation cycle.

Because our internal webpage works with a database rather than flat files, and because the real-time scrtdd solutions are already in the database while the background catalog is not, we decided to upload the background catalog to a dedicated SeisComP database separate from the production one. This database contains the weekly relocations of all events, which are used by our internal web map and can also be used to analyze the evolution of event relocations.