Choosing Between HMTK and MBTK for Gridded Seismicity Smoothing

[Fatahillah Surya Yudha]

Dear OpenQuake users,

I’m currently working on a project that involves analyzing historical earthquake data by modeling it as gridded seismicity within OpenQuake. After reading through some documentation and discussions, I’ve come across two tools that can be used for seismicity smoothing: HMTK and MBTK.

I would like to ask for your advice or experience on the following points:

1. Which tool (HMTK vs. MBTK) is more suitable for implementing spatial smoothing of historical earthquake catalogs in the context of gridded seismicity modeling?

2. What are the main differences between the two tools, both in methodology and compatibility with OpenQuake’s source model input format?

3. I also plan to run a comparative analysis using hazgridxnga2 from the NSHMP-USGS (Fortran) suite to see how the results compare. Would it be reasonable to use that as a benchmark, or are there compatibility or conceptual differences I should be aware of?

I appreciate any guidance, references, or shared experiences from those who have worked with these tools or have performed similar comparisons.

Thank you in advance!

Best regards,
Fatahillah Surya Yudha

[Marco Pagani]

The tools in the MBTK are more updated and used on a regular basis by the hazard team.
Kirsty, should be able to share with you some more details.

--
You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openquake-users/3854612c-4b23-4547-81f1-a78bd9bab52bn%40googlegroups.com.

[Fatahillah Surya Yudha]

Thank you Mr. Marco for the information. That’s helpful to know. I’ll also get in touch with Kirsty for further details as suggested.

Appreciate your guidance!

To view this discussion visit https://groups.google.com/d/msgid/openquake-users/F8ECC529-5E67-4CC1-8C72-D7D4FA209890%40globalquakemodel.org.

[Kirsty Bayliss]

Hi Fatahillah, 

As Marco says, the MBTK contains the most up-to-date tools for building seismic source models for OpenQuake. The MBTK builds upon the older HMTK, adding new approaches and improvements, and is the tool used regularly by the seismic hazard team.  You can find details of the methods available in the MBTK and how to use them here. Many of the functions in the MBTK are designed to be used in a workflow that goes all the way to making the OpenQuake sources, we are still updating the documentation, so let me know if things are unclear.

The HMTK smoothing tools are no longer regularly used by the hazard team, and as such it is difficult for us to offer support with errors or issues. There is some documentation available for the hmtk here with the caveat that these are a bit old now and some functions have been updated. I think the smoothing documentation is still correct, though I would suggest using the MBTK smoothing tools instead.

I'm not familiar enough with hazgridxnga2 to comment on any differences in approaches, but there can be some tricky differences in alternative approaches for gridded seismicity, e.g. using cumulative or incremental rates in the MFD, that you should be careful of. 

Hope this helps,

Kirsty

[Fatahillah Surya Yudha]

Dear Kirsty,

Thank you very much for your detailed response — that clarifies a lot, and I appreciate your offer to help further if anything in the documentation is unclear.

As a follow-up, I’d like to ask about declustering. Does the MBTK currently include tools for declustering earthquake catalogues? For my current work, I’ve been using the declustering functionality from HMTK (specifically the Gardner and Knopoff method), which reduced my catalogue from around 85,000 to 22,000 events. However, when I tried using other software such as ZMAP v7 with the same method, the results differed significantly (reducing the events to around 35,000).

I’m trying to understand whether MBTK has built-in or recommended tools for declustering, and whether there is a preferred or consistent method the OpenQuake team uses for this step — especially when the results can vary quite a bit across tools.

[Kirsty Bayliss]

Currently, we are still using the declustering tools within the HMTK. The documentation from the link above does have a typo for the Gruenthal windows (an extra squared term for the magnitudes), but the code is correct. 
The HMTK declustering implementations have identical windows to those in ZMAP for each of the three window options (Gardner and Knopoff, Gruenthal and Uhrhammer) so I'm not sure why you would get such different results across the two approaches (and a bit surprised!). 
One thing worth checking is the fs_time_prop in the HMTK declust_config which is designed to remove foreshocks. If this is set to 1 then the foreshock and aftershock time windows are identical, while reducing this to a lower value means that the time windows for identifying foreshocks before large events are smaller. I prefer to set this much lower (maybe  ~ 0.2 lower depending on the region) because in regions with very large earthquakes this can remove a lot of events that I would not necessarily consider foreshocks. 
This still seems like a huge difference in the number of events. It might be interesting to compare the different windows across both options. I get a bit confused looking at the zmap code because it seems case 1 is using a table and not the GK74 equations directly, but since I'm not a zmap user my experience is a bit limited. 

[Fatahillah Surya Yudha]

Yeah I think comparing two different software implementations can get quite tricky.

By the way, circling back to the earlier topic — I’ve also been experimenting with the HMTK smoothing tools, and I encountered something that seems like a bug. Specifically, I noticed that certain locations with no earthquakes in the input catalogue still appear to receive smoothed seismicity rates.

To illustrate this, I’ve attached (or: "please see the image below") a map where cyan dots represent the original earthquake locations, and maroon dots indicate the smoothed outputs. You can see that several maroon points appear in areas with no nearby seismicity in the original data.

Do you have any thoughts on why this might be happening? Could this be related to the way spatial kernels are applied in HMTK, or perhaps an issue with the grid resolution?

Thanks again for your insights — I really appreciate your time.

[Fatahillah Surya Yudha]

I came back again, I think there is a critical issue in the latitude indexing calculation used in the smoothed_seismicity.py script. The use of:
dlat = fabs(ymax - latitude) / yspc

results in systematic spatial misplacement of smoothed seismicity values, especially in regions that span both the northern and southern hemispheres, such as Indonesia. 

However, when we modify that part of the code, it may cause a domino effect on other parts of the script — for example, when generating coordinate arrays (such as gridy) and related calculations  

[Kirsty Bayliss]

There is certainly something strange going on here, but as I said yesterday the HMTK smoothing code is no longer used in the hazard team, and as such we don't test it regularly with different machines and dependencies. It is mostly here for legacy purposes.  
The MBTK uses a completely different smoothing code which uses spatial indexing and is much more widely tested. 

[Fatahillah Surya Yudha]

Dear Kirsty,

Thank you for the clarification —

Given that the HMTK smoothing code is no longer actively maintained or tested, I completely understand the recommendation to switch. I’ll proceed with using the MBTK tools for my smoothing workflow going forward.

That said, I’m still quite new to MBTK. From what I’ve seen so far (especially smoothing), it appears to be written in Julia and makes use of .toml configuration files, which is quite different approach I’m more familiar with in HMTK. It may take me a bit of time to get used to the new workflow and setup.

I really appreciate your time and all the helpful insights you've shared. If I run into anything while setting up MBTK, I’ll be sure to follow up.

Thanks again!

--

You received this message because you are subscribed to the Google Groups "OpenQuake Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openquake-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openquake-users/cef879b9-6bd5-4f40-b0fe-1f62a2b0b702n%40googlegroups.com.

[Fatahillah Surya Yudha]

Dear OpenQuake team,

I’d like to report a bug I found in the smoothing.jl script of the oq-mbtk workflow. The script fails with the following error: KeyError: key "kernel_maximum_distance" not found Even though I already declared kernel_maximum_distance under the [smoothing] section in my config.toml.

After checking the source code in smoothing.jl, it seems that the kernel_maximum_distance is incorrectly read from the root level of the TOML instead of from the [smoothing] section. This may be the cause of the KeyError.

[Kirsty Bayliss]

Dear Fatahillah, 

Thanks for bringing this to our attention. 

This is an inconsistency that I introduced by adding the 'smoothing' section to the toml when I added the adaptive smoothing options without updating the julia functions. Currently, the parameters for the Gaussian fixed kernel smoothing should be in the top level of the toml as you say, and the parameters for the adaptive smoothing should be in the 'smoothing' section, which is confusing and I will update this to be more consistent. 

Many thanks,

Kirsty

[Fatahillah Surya Yudha]

Thank you Kirsty for the clarification, I’d like to report a series of issues I encountered while running the oq-mbtk workflow (wkf),

1. Output Naming in wkf_smoothing.jl

The script wkf_smoothing.jl always outputs a file with the fixed name "smooth" (without .csv extension), regardless of the input source name. This causes downstream problems because wkf_rates_distribute.jl expects files like 1.csv, matched with [sources.1] in the TOML config.

2. KeyError: tectonic_region_type Missing

When running oqm create_nrml_sources, the workflow crashes if the key tectonic_region_type is missing in [sources.<id>]. It seems that tectonic_region_type is required in each [sources.<id>] block in the config TOML, but this is not documented or validated early in the workflow. Even though, i have written in [default]

[Kirsty Bayliss]

Thanks Fatahillah. 

Yes,  you are right that the tectonic_regions need to be specified for each source. The documentation is missing the step with the set_trt function (https://github.com/GEMScienceTools/oq-mbtk/blob/master/openquake/mbi/wkf/set_trt.py). A TRT is necessary for each source in order to make a valid OQ xml file, and the workflow does not take these directly from default.

So in the workflow example within a notebook it would be: cmd = f"oqm wkf set_trt {config} \"*\" \"Active Shallow Crust\"" to set all sources (indicated with the *) to 'Active Shallow Crust'. Sorry for the confusion, I will add this to the documentation.

On the first point, I don't think this is quite correct. The output of wkf_smoothing.jl is a file with name specified by fname_smoothing in the function call. If you are following the example in the documentation you will indeed get a file called 'smooth' with no .csv extension. I should update this because it's a bad file name, but it doesn't break the workflow because the next step (necessary for both smoothing approaches) is the 'create_smoothing_per_zone' function which will take all of the smoothed values in 'fname_smoothing' (in this case the 'smooth' file) and make individual csv files relating to each source in the specified 'fname_smoothing_source' folder. 'wkf_rates_distribute.jl' is then expecting to receive the 'fname_smoothing_source' folder rather than the output of 'wkf_smoothing.jl' directly. 

I understand that this is confusing, but there is logic to it because the smoothing should be carried out ignoring the source boundaries and then mapped back to our individual sources so we can make the source xmls.

Hope this helps and sorry for the confusion, 

Kirsty 

[Fatahillah Surya Yudha]

Hi Kirsty,

Thank you very much for your detailed clarification — it helped me better understand the logic behind the smoothing workflow and the need to explicitly assign tectonic region types (TRTs) using set_trt.py. I appreciate your quick response and explanation. Apologies if there was any earlier confusion from my side. While following the workflow, I noticed a few minor issues and inconsistencies in the documentation that may be worth reviewing:
1. The command oqm wkf create_smoothing_per_zone uses use and skip as positional arguments, but in the documentation they are written with flags (e.g., --use), which results in parsing errors (unrecognized arguments). This could be clarified to help new users avoid errors.
2. There is some inconsistency in the output naming between smoothing methods. For example, the Gaussian smoothing example generates a file named smooth (without .csv), while the Adaptive smoothing example outputs adapsmooth_nv5.csv.
3. In the boxcounting workflow, the documentation refers to a variable BIND. However, in practice, the correct variable name appears to be BIND1.
4. When using the -m "counting" method in set_gr_params, the config does include agr_counting, rmag_counting, and rmag_rate_counting, but the value for bgr_counting is not set as expected (i.e., the bgr value is missing or remains unchanged).

In addition to that, there’s something I’d like to clarify regarding a comparison I made between smoothing results. I visualized the output using both HMTK and MBTK, and used colors to distinguish them. The smoothed seismicity results using HMTK are shown in orange, those from MBTK in yellow, and the original earthquake catalog data in green. Here are the configurations I used:

HMTK Configuration:
# Assuming a b- value of 1.0
smooth_seis = SmoothedSeismicity (grid_limits ,use_3d = True ,bvalue =1.0)
# Set up config (e.g. 50 km band width , up to 3 bandwidths )
config = {'Length_Limit': 3.,'BandWidth' : 50. ,'increment': False}

MBTK Configuration:
[smoothing]
smoothing_method = "Gaussian"
kernel_maximum_distance = 150.0
kernel_smoothing = [ [ 1.0, 50.0,],]

However, I noticed a difference in the size (spatial spread) of the smoothed seismicity patterns produced by HMTK and MBTK — despite using seemingly similar Gaussian parameters. Would this be expected behavior due to implementation differences? or is it okay? Hopefully this helps provide clarity and feedback from a user’s perspective. Once again, thank you for maintaining and supporting this valuable toolkit for seismic source modeling.

Best regards,
Fatahillah