The second version of this page is available here: Validation source perturbation (Source uncertainties) V2


To maintain compatibility with current workflows while adding additional functionality to the workflow, we intend to change the way perturbed source parameters are passed to the components of the slurm ground motion workflow.

Proposed workflow change

It has been proposed that srf generation will be split into two steps: perturbation and srf generation.

This will split the current two workflow steps (gcmt2srf, nhm2srf) to generate srfs into three (gcmt2srfparams, nhm2srfparams, srfparams2srf).

There will be an intermediary file containing all the parameters to generate the srf, allowing users to manually modify these files if they choose to do so.

This will be able to be integrated into the automated workflow by making each step work on a single realisation, with a multi process wrapper to allow it to also be used as a stand alone step. The automated workflow step would not allow time for the user to modify the intermediary file.

User input

All parameters to be perturbed are to be included in the source_uncertainty.yaml file. Any additional parameters must also have nominal values provided.

The nominal values and perturbation settings for each of these parameters will have to be given in the source uncertainties yaml (as passed to gcmt2srf).

Each parameter that is given in the CMT solutions csv file will be at the top level, while each additional parameter will be nested inside the relevant process.

Each parameter will have at least two associated pieces of information, being the nominal value (mean) of the parameter, and the distribution. If the distribution requires any random variables, these must also be given.

An example is available below:

mw:
    distribution: uniform
    half_range: 0.05
hf:
    sdrop: 
        mean: 50
        half_range: 5
        distribution: uniform
    rvfac: 
        mean: 0.8
        std_dev: 0.01
        distribution: normal
    rvfac_shallow:
        mean: 0.7
        distribution: none
bb:
    fmin: 
        mean: 0.2
        distribution: uniform_relative
        scale_factor: 0.05
emod3d:
    fmin:
        mean: 0.01
        std_dev: 0.001
        distribution: normal

Currently available distributions

Distribution nameDistribution variableNotes
noneN/AUses the value as given.
uniformhalf_rangemean is the median (middle) value, and half_range half the difference between the highest and lowest value.
normalstd_devRegular normal distribution.
uniform_relativescale_factorA normal distribution where the highest and lowest possible value are mean* (1+scale_factor) and mean* (1-scale_factor) respectively. Scale factor to be given as a decimal.
log_normal

std_dev

Regular log_nromal distribution.
weibullk, scale_factor

Does not take a mean value. Equivalent to scale_factor*(-ln((U))1/a where U is the uniform distribution over [0, 1).

truncated_normalstd_dev, std_dev_limitSimilar to normal distribution, except all values fall within [std_dev_limit] standard deviations of the mean. std_dev_limit has a default value of 2.
truncated_log_normalstd_dev, std_dev_limitSimilar to log normal distribution, except all values of the underlying normal distribution fall within [std_dev_limit] standard deviations of the mean. std_dev_limit has a default value of 2. Mean must be given as a string of the form "log(x)" where x is the unmodified value of the mean.
duplicatetargets (must be a list of strings, even if only 1 target)Copies the given target perturbated variable. The perturbate_parameters function must include functionality to handle cases where the target is perturbated after the current variable.

A note on emod3d

Any variable found in the e3d.par file may be placed in the emod3d section of source_uncertainty.yaml, and will be carried over. Any non numeric entries must have the distribution 'none'.

Internal changes

In order to simplify the implementation of this, we have chosen to have every parameter added to the slurm script and passed as an argument to the simulation script, which will then discard any parameters it does not recognize.

Parameters for srf generation

These parameters have a mean specified via other methods and do not need one in the source uncertainty file. If a mean is provided in the source uncertainty file it will take precedence


ParameterType 1Type 2Type 3Type 4
depth

mw (magnitude) (mag0)
mom

(mom0)
strike (stk)
rake (rak)
dip
vs


rho


rise_time


rvfac
OptionalOptionalOptional
rough
OptionalOptionalOptional
slip_cov
OptionalOptionalOptional
flen
Calculated, but can be given/perturbated
dlen
Calculated, but can be given/perturbated
fwid
Calculated, but can be given/perturbated
dwid
Calculated, but can be given/perturbated
dtop
Calculated, but can be given/perturbated
shypo
Calculated, but can be given/perturbated
dhypo
Calculated, but can be given/perturbated


rvfac vs rvfrac

Genslip takes the parameter rvfrac while HF takes the parameter rvfac, however scientifically these are the same value.

This different spelling allows the two to be perturbated independently. With the current perturbation implementation a challenge arises when it is to be perturbated and used for both.

The currently proposed solution is that:

  1. If neither are given via command line or in the source uncertainties file, the defaults will be used.
  2. If rvfrac is given in the source uncertainties file (and rvfac is not provided any where), it is perturbated and then copied to rvfac.
  3. If rvfac is given via command line to gcmt2srf or in the source uncertainties file (and rvfrac is not given), it is perturbated and then copied to rvfrac.
  4. If both are given, either via command line or the source uncertainties file, they are perturbated and used separately.


Parameters for each component

The parameters for each component are as follows:


hfbb
flo
fmin
fmidbot
lfvsref
sim_bin
t-sec
sdrop
rayset
seed
duration
dt
fmax
kappa
qfexp
rvfac
rvfac_shallow
rvfac_deep
czero
calpha
mom
rupv
velocity-model
site-vm-dir
vs-moho
fa_sig1
fa_sig2
rv_sig1
hf_path_dur