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 consist of well-formed JSON. Why JSON?

Model Initialization Parameters

Model initialization parameters must be supplied.

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

Calculation Configuration Parameters

Calculation configuration paraeters 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	see Notes (1)
gmmUncertainty	Boolean	see Notes (2)
deagg	Object	see Notes (3)	Deagg
sites	Object	see Notes (4)	Site

Notes

---

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 dis/enable this feature.

(3) 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
  }

(4) The "sites" field is mapped to a Site container and can specify an array of sites:

"sites": [
    {
    "name": "Test Site 1",
    "location": [-111.9, 40.75],
    "vs30": 760,
    "vsInf": true
    },
    {
    "name": "Test Site 2",
    "location": [-111.9, 40.75],
    "vs30": 760,
    "vsInf": true
    }
  ]

or a region:

  "sites": {  
    "region": {
      "name": "Test Map",
      "spacing": 0.1,
      "border": [  
        [-111, 40],
        [-110, 41],
        [-109, 40]
      ],
      "vs30": 459,
      "vsInf": true,
      "z1p0": 0.48,
      "z2p5": 1.62
    }
  }

A "border" element must specify at least two [lon, lat] coordinates. In the case of 2 coordinates, the coordinates are used as the corners of a rectangular lon-lat region. In the case of 3 or more coordinates, the coordinates are used to define the border of a polygonal region.

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.