Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - elhaddad

Pages: 1 [2]
This is now possible by setting the Aftershock parameter to true, as follows:

"GMPE": {
      "Type": "Chiou & Youngs (2008)",
         "Aftershock": true

It is supported by the latest preview version:

This issue is now fixed in the latest preview release.

We improved error handling for typos in IMR or ERF names.
For unhandled exception, the program will print the call stack, which can help debugging in the future.
We also plan to add more logging in the next release and allow user to change logging verbosity.

This is now implemented, it is available in the latest preview release (v1.1.1) here:

This is a direct download link to the jar file:

To exclude background seismicity you need to specify a parameter to the ERF as follows:

   "EqRupture": {
      "Type": "ERF",
      "RuptureForecast": "...",
         "Background Seismicity": "Exclude"

Other possible values for this parameter are "Include" which is the default or "Only Background".

Let me know if this does not work as expected or does not satisfy your requirements.

It seems that there is an aftershock parameter in CY2008, it defaults to false.
I will see if we can allow adjusting it.

We are developing a new API for regional analysis that allows you to directly interface to the Java code using python.
It is also possible to do that using other programming languages.
The benefit is that it gives you more control over the logic and the results, while avoiding using the command line interface and saving the intermediate results files.
It will allow you to run many sites and also as many scenarios as you want.
Currently, we only support UCERF3, other ERFs can be added easily.
If you are interested in this I can share a sample with you here.
We will also make the sample available in the next preview release.

We started implementing this feature, it will be available in the next preview version in the next few days.
Just to confirm we satisfy your requirements, we will change the ERF export code to sort the sources based on proximity to the provided site and export the sources in that order.
We will also provide a way to control background seismicity, either by including it, excluding it or only process background sources.

 I forgot to mention in OpenSHA website, there is some description of the magnitude area relationships, in this page:

We started looking into implementing these features. I found that in OpenSHA UCERF implementations the magnitude interval is not one of the adjustable parameters.

For instance you can check here:

line 68 shows that the variable DELTA_MAG is declared as final, which means its value cannot be changed for UCERF2.

Selecting the magnitude area relationship is possible.
The possible values are:
Ellsworth-A (WGCEP, 2002, Eq 4.5a)
Ellsworth-B (WGCEP, 2002, Eq 4.5b)
Hanks & Bakun (2002)
Somerville (2006)
WGCEP (2007) power law
Shaw (2007)

Wells and Coppersmith 1994 model is not one of the allowed models for UCERF2.

Specifying the magnitude area relationship is not possible using the current Mean UCERF2 model.
But it is possible to add the adjustable UCERF2 model as a possible input.
Just wanted to confirm with you that this is the feature you are looking for before implementing it.

Thanks for reporting this issue. We currently do not validate the input so any mistake in the input gets reported as an unhandled exception, which in this case return a -ve error code (-2).
We will add input validation and error codes for incorrect GMPE or ERF in the next release, with distinct error codes values.

Thanks for the feature requests!
We will consider them in the near future and will keep you posted on any progress.

Thanks for posting your question!
You are correct, the current version of EQHazard scans the sources in the ERF using the source index as defined in OpenSHA.
The resulting ruptures won't be ordered based on closest distance to the site.
To be able to implement that, it will require calculating distances for all the ruptures, which may hinder performance as the distance calculation is more time consuming.
If a combination of increasing the number of sources to a higher value and reducing the distance achieves the purpose then we may leave the current implementation as it is.

Pages: 1 [2]