Configuration

A config.json file resides at the root of every source model.

This file supplies model initialization and default calculation configuration parameters; see the examples directory, or any USGS model, for examples. The file must be composed of well-formed JSON. Why JSON?

Model Initialization Parameters

Model initialization parameters must be supplied; there are no default values. In addition, these parameters may not be overridden.

Parameter	Type	See
name	String
surfaceSpacing	Double
ruptureFloating	String	RuptureFloating
ruptureVariability	Boolean
pointSourceType	String	PointSourceType
areaGridScaling	String	AreaSource.GridScaling

Calculation Configuration Parameters

Calculation configuration parameters are optional (i.e. defaults are used for missing values) and overridable. Please see building and running for details on how to override a calculation configuration.

Parameter	Type	Default	See
exceedanceModel	String	"TRUNCATION_UPPER_ONLY"	ExceedanceModel
truncationLevel	Double	3.0
imts	String[]	["PGA", "SAOP2", "SA1P0"]	Imt
defaultImls	Double[]	[0.0025, 0.0045, 0.0075, 0.0113, 0.0169, 0.0253, 0.0380, 0.0570, 0.0854, 0.128, 0.192, 0.288, 0.432, 0.649, 0.973, 1.46, 2.19, 3.28, 4.92, 7.38]
customImls	Map<String, Double[]>	empty	example model
optimizeGrids	Boolean	1️⃣
gmmUncertainty	Boolean	2️⃣
deagg	Object	3️⃣	Deagg

1️⃣ optimizeGrids

Grid optimizations are currently implemented for any non-fixed strike grid source. For any site, rates across all azimuths are aggregated in tables of distance and magnitude.

2️⃣ gmmUncertainty

If values for additional epistemic uncertainty on ground motion have been defined, this value en/disables this feature.

3️⃣ deagg

The deagg field is mapped to a data container that specifies the following default values:

"deagg": {
    "rMin": 0.0,
    "rMax": 100.0,
    "Δr": 10.0,
    "mMin": 5.0,
    "mMax": 7.0,
    "Δm": 0.1,
    "εMin": -3.0,
    "εMax": 3.0,
    "Δε": 0.5
  }

Why Use JSON?

Whereas sources are defined using XML, configuration files use JSON. Although one or the other formats could be used exclusively, each has unique characteristics and benefits. For instance, for long files, XML is somewhat more readable than JSON. It also permits comments inline, whereas JSON does not. Java has a built in support for writing highly performant XML parsers, and as there is not a 1:1 relationship between source model XML and resultant Java objects in nshmp-haz, it is a bit easier to work with. XML also permits a formal structure to be imposed, and although XML schema are not presently used, they may be in the future.

JSON, on the other hand, is a very simple data exchange format designed with the web in mind. The values that govern calculation settings are most likely to be exposed via web services and the job of exchanging such data is much more straightforward using a format that maps natively to Javascript objects.

Next: Site Specification