Browse Source

doc: optimiser, review method

whitelist
miili 2 years ago
parent
commit
7cd87d2ffa
7 changed files with 271 additions and 181 deletions
  1. +15
    -39
      docs/source/config/analysers/index.rst
  2. +2
    -2
      docs/source/config/dataset/index.rst
  3. +22
    -0
      docs/source/config/index.rst
  4. +101
    -2
      docs/source/config/optimisers/index.rst
  5. +107
    -127
      docs/source/config/problems/index.rst
  6. +8
    -6
      docs/source/method/index.rst
  7. +16
    -5
      src/optimisers/highscore/optimiser.py

+ 15
- 39
docs/source/config/analysers/index.rst View File

@ -11,25 +11,11 @@ TODO: review, link to the reference, link to papers?
There are two analysers implemented so far, which work on waveform targets:
``TargetBalancingAnalyser``:
This analyser balances, based on estimated signal amplitudes, the waveform
target contributions to the misfit.
This is done with synthetic waveforms from random source models drawn from
the model space defined in the problem configuration. Waveforms from
stations that are far away from the source will on average have small
signal strengths, while targets of stations close to the sources will have
larger signal amplitudes. To balance the importance of waveforms the
inverse of the mean signal strength is used as a ``balancing_weight``.
Like this the effect of simple geometrical spreading or through the
radiation pattern is lessened in the misfit evaluation.
This analyser balances, based on estimated signal amplitudes, the waveform target contributions to the misfit. This is done with synthetic waveforms from random source models drawn from the model space defined in the problem configuration. Waveforms from stations that are far away from the source will on average have small signal strengths, while targets of stations close to the sources will have larger signal amplitudes. To balance the importance of waveforms the inverse of the mean signal strength is used as a ``balancing_weight``. Like this the effect of simple geometrical spreading or through the radiation pattern is lessened in the misfit evaluation.
``NoiseAnalyser``:
This analyser evaluates the pre-event noise for the waveform targets to
form empirical target weights. High pre-event noise variance leads to a
small target weight for the corresponding target in the misfit calculation.
It is assumed that the pre-event noise is random background noise and
stationary in the time from the first pre-event sample to the last analysed
phase sample. A check for significant earthquakes in the critical time
This analyser evaluates the pre-event noise for the waveform targets to form empirical target weights. High pre-event noise variance leads to a small target weight for the corresponding target in the misfit calculation. It is assumed that the pre-event noise is random background noise and stationary in the time from the first pre-event sample to the last analysed phase sample. A check for significant earthquakes in the critical time
frame can be enabled.
@ -40,15 +26,8 @@ The balancing of target is problem-dependent. This means the configuration of
the problem also configures the ``target_balancing``. The only extra parameter
needed is
``niterations``: an integer number that defines how many random waveform
predictions the target-balancing weights are based.
A meaningful number will depepend on the problem. Large model spaces
(loose model parameter bounds) may require a larger number of predicitons
for more stable average values. For more tightly constrained problems the
signal strength at the targets for the not-so-different source models,
which are drawn from a small model space, may not vary much. A smaller
number may suffice. Of course, the computional effort increases linearly
with the number of ``niterations``.
``niterations``
an integer number that defines how many random waveform predictions the target-balancing weights are based. A meaningful number will depepend on the problem. Large model spaces (loose model parameter bounds) may require a larger number of predicitons for more stable average values. For more tightly constrained problems the signal strength at the targets for the not-so-different source models, which are drawn from a small model space, may not vary much. A smaller number may suffice. Of course, the computional effort increases linearly with the number of ``niterations``.
.. code-block :: sh
@ -60,24 +39,21 @@ needed is
``NoiseAnalyser`` configuration
-------------------------------
This analyser is not strongly model-independent. Only the reference time given
in 'event.txt' is used to estimate the phase arrivals. These phase arrivals
define what `pre-event` is.
This analyser is not strongly model-independent. Only the reference time given in 'event.txt' is used to estimate the phase arrivals. These phase arrivals define what `pre-event` is.
``nwindows``: is an integer number. It gives the number of sub-windows in which
the noise trace of duration ``pre_event_noise_duration`` is split. If
larger than ``1``, the noise variance is in each sub-window and the average
noise variance is returned.
.. glossary ::
``pre_event_noise_duration``: defines how long (in seconds) the pre-event noise
trace is.
``nwindows``
is an integer number. It gives the number of sub-windows in which the noise trace of duration ``pre_event_noise_duration`` is split. If larger than ``1``, the noise variance is in each sub-window and the average noise variance is returned.
``check_events``: is a boolean value. If ``True`` the iris global earthquake
catalog is looked up to find if phase arrivals of other events may disturb
the statistics of the noise.
``pre_event_noise_duration``
defines how long the pre-event noise trace is in seconds.
``phase_def``: is a string that defines the reference phase for the pre-event
time window.
``check_events``
is a boolean value. If ``True`` the iris global earthquake catalog is looked up to find if phase arrivals of other events may disturb the statistics of the noise.
``phase_def``
is a string that defines the reference phase for the pre-event time window.
.. code-block :: sh


+ 2
- 2
docs/source/config/dataset/index.rst View File

@ -7,8 +7,8 @@ The :term:`dataset` configuration section is the core of data input and data con
:language: yaml
:caption: A basic dataset section of a Grond configuration file (``gronf``).
Basic configuration and templating
----------------------------------
General configuration and templating
------------------------------------
All folder and file paths in the dataset support templating and prefixing:


+ 22
- 0
docs/source/config/index.rst View File

@ -4,6 +4,7 @@ Configuration
Grond is configured by YAML text files. Read on :doc:`structure` to get started with the configuration.
.. toctree::
:caption: Contents
:name: Contents
structure
@ -12,3 +13,24 @@ Grond is configured by YAML text files. Read on :doc:`structure` to get started
problems/index
analysers/index
optimisers/index
.. rubric:: Glossary
.. glossary ::
``Dataset``
The core of data input, selection and data configuration.
``Targets``
are the observable (seismic or surface displacements) whos misfit is minimised.
``Problem``
is specific source modell (CMT, rectangular fault), which is optimised.
``Analysers``
are responisble for data analysis before the optimisation.
``Optimiser``
deliver the optimisation strategy.

+ 101
- 2
docs/source/config/optimisers/index.rst View File

@ -1,6 +1,105 @@
Optimisers
==========
.. todo ::
The optimiser is the heart of the inversion, it samples the model space striving to lower the :term:`target's <target>` misfit.
add textual description of the optimiser(s) implemented in Grond, possibly with some examples and some background how these can be tuned. Technical details can be moved to the library reference, the theoretical concept should be put to method/optimiser subsection.
Bayesian Bootstrap Optimiser (BABO)
-----------------------------------
BABO allows for a source optimisation while providing the full information in the results for a fully Bayesian analysis. BABO is based on Direct Search where model parameters are drawn in a randomised way from the defined model space. Those models are then calculated and compared with the :term:`target's <target>` observed data. This needs no assumptions on the topology of the misfit space and is appropriate also for highly non-linear problems.
BABO can be configured for a simple Monte-Carlo random direct search. It can also resemble a simulated annealing optimisation approach. Ultimately BABO enables fully probabilistic bootstrapping of the optimisation results.
See the :doc:`/method/index` documentation for detailed information about the :ref:`optimisation <optimisation>`.
Example Configuration
~~~~~~~~~~~~~~~~~~~~~
Basic configuration section for the BABO optimiser:
.. code-block :: yaml
optimiser_config: !grond.HighScoreOptimiserConfig
# Number of bootstrap realisations to be tracked simultaneously in the
# optimisation
nbootstrap: 100
# stages of the sampler. Start with uniform sampling of the model space
# (!grond.UniformSamplerPhase), then narrow down to the interesting regions
# (!grond.DirectedSamplerPhase).
sampler_phases:
- !grond.UniformSamplerPhase
# Number of iterations
niterations: 1000
- !grond.DirectedSamplerPhase
# Number of iterations
niterations: 20000
# Multiplicator for width of sampler distribution at start of this phase
scatter_scale_begin: 2.0
# Multiplicator for width of sampler distribution at end of this phase
scatter_scale_end: 0.5
General configuration
~~~~~~~~~~~~~~~~~~~~~
General parameters are:
``nbootstrap``
Number of bootstrap realisations to be tracked simultaneously during the optimisation.
``sampler_phase``
List of sampling stages: Start with uniform sampling of the model model space and narrow down through directed sampling.
``UniformSamplerPhase`` configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the beginning of the optimisation this sampler phase explores the solution space uniformly. A configurable number of models are drawn randomly from the entire model space based on a uniform distribution.
``niterations``
Number of iterations for this phase.
``DirectedSamplerPhase`` configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This sampler is used for the second phase and follows any of starting samplers above: Using existing models of the current `highscore` models the `directed` sampler draws a configurable number of new models. Like this convergence to low-misfit regions is enabled. There are quite some noteworthy configureable details to this sampler phase:
.. glossary ::
``niterations``
Number of iterations for this phase.
``sampling_distributions``
New models are drawn from normal distribution. The standard deviations are derived from the `highscore` models parameter's standard deviation and scaled by ``scatter_scale`` (see below). Optionally, the covariance of model parameters is taken into account by configuring when ``multivariate_normal`` is enabled (default is ``normal`` distribution). The distribution is centered around
1. ``mean`` of the `highscore` model parameter distributions
2. a ``random`` model from the `highscore` list or
3. an ``excentricity_compensated`` draw (see below).
``scatter_scale``
This scales search radius around the current `highscore` models. With a scatter scale of 2 the search for new models has a distribution with twice the standard deviation as estimated from the current `highscore` list. It is possible to define a beginning scatter scale and an ending scatter scale. This leads to a confining directed search. In other words, the sampling evolves from being more explorative to being more exploitive in the end.
``starting_point``
This method tunes to the center value of the sampler distribution: This option, will increase the likelihood to draw a `highscore` member model off-center to the mean value. The probability of drawing a model from the `highscore` list is derived from distances the `highscore` models have to other `highscore` models in the model parameter space. Excentricity is therefore compensated, because models with few neighbours at larger distances have an increased likelihood to be drawn.
What's the use? Convergence is slowed down, yes, but to the benefit of low-misfit region represented by only a few models drawn up to the current point.
Let's assume there are two separated groups of low-misfit models in our `highscore` list, with one group forming the 75% majority. In the directed sampler phase the choices of a mean center point for the distribution as well as a random starting point for the sampler distribution would favour new samples in the region of the `highscore` model majority. Models in the low-misfit region may be dying out in the `highscore` list due to favorism and related sparse sampling. `excentricity compensations` can help is these cases and keep models with not significantly higher misfits in the game and in sight.
``InjectionSamplerPhase`` configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This starting phase allows to inject pre-defined models at the start of the optimisation. These models could originate from a previous optimisation.
``xs_inject``
Array with the reference model.
TODO: correct? too many explanations? Sebastian, here is the perfect place for one of your movies.

+ 107
- 127
docs/source/config/problems/index.rst View File

@ -1,25 +1,19 @@
Problems
========
A problem in Grond is a task to optimise a specific source model in Grond given certain conditions.
These conditions can be configured rather flexibly. So far defined problems in Grond are the optimisations
of different source types, which are derived from `Pyrocko Sources`_.
The problem is the optimisation task - the specific :term:`source` model we invert.
The search ranges and inversion conditions can be configured flexibly. So far defined problems in Grond are the optimisations of different source types, which are derived from `Pyrocko Sources`_.
These problems are in short (more details in the corresponding sections below):
These problems are:
* ``CMTProblem``:
A problem that solves for a centroid moment tensor point source (derived from ``CMTSource``). This
problem fits the very general earthquake source analysis based on far-field seismic waveforms.
* ``CMTProblem``
A problem that solves for a centroid moment tensor point source (derived from Pyrocko's ``CMTSource``). This problem fits the very general earthquake source analysis based on far-field seismic waveforms.
* ``DoubleDCProblem``:
A problem that solves for two double-couple point sources (derived from ``DoubleDCSource``). This
problem can be used to solve for somewhat complex, segmented earthquake sources to better fit
far-field seismic data.
* ``DoubleDCProblem``
A problem that solves for two double-couple point sources (derived from ``DoubleDCSource``). This problem can be used to solve for somewhat complex, *segmented earthquake sources* to better fit far-field seismic data.
* ``RectangularProblem``:
A problem that solves for a rectangular finite source (derived from ``RectangularSource``). This
problem fits well to large earthquakes and/or problems for which near-field data (InSAR, GNSS, etc.)
are available.
* ``RectangularProblem``
A problem that solves for a rectangular finite source (derived from Pyrocko's ``RectangularSource``). This problem fits well to large earthquakes and/or problems for which near-field surface displacement data (InSAR, GNSS, etc.) are available.
To define and configure a problem the part called ``problem_config`` in the configuration is set up.
@ -30,18 +24,17 @@ General configuration
The following problem parameters are shared by all problems and are part of all
problem configurations:
``name_template``: can be any string and provides a stem for the result folders
`runs` and `reports` to identify different optimisations.
Meaningful is to use short event and problem identifications
in this string.
.. glossary::
``norm_exponent``: defines the norm of combining several `normalization_family` in the
global misfit. This integer value is 1 or larger. Please find here
more information on the global `misfit calculation in Grond`_.
``name_template``
can be any string and provides a stem for the result folders `runs` and `reports` to identify different optimisations. Meaningful is to use short event and problem identifications in this string.
``norm_exponent``
defines the norm of combining several `normalization_family` in the global misfit. This integer value is 1 or larger. Please find here more information on the global `misfit calculation in Grond`_.
``ranges``
defines the bounds of individual and specific source model parameters. See the details for the source ranges of different problems in the sections below.
``ranges``: defines the bounds of individual and specific source model parameters.
See the details for the source ranges of different problems in the sections below.
An example for the configuration of a rectangular fault problem is given here:
.. code-block :: yaml
@ -76,45 +69,48 @@ particularly for the ``CMTProblem``.
**Non-general problem parameters**:
``distance_min``: is a minimum target distance to the source used to exclude targets closer than this.
Tailored to the problem, too close targets will not be considered in the misfit evaluation.
Finite-rupture effects on near targets may be excluded efficiently with a meaning setting
.. glossary::
``distance_min``
is a minimum target distance to the source used to exclude targets closer than this. Tailored to the problem, too close targets will not be considered in the misfit evaluation. Finite-rupture effects on near targets may be excluded efficiently with a meaning setting
for this parameter.
``distance_max``: is a maximum target distance to the source used to exclude targets farther than this.
Tailored to the problem, too far away targets will not be considered in the misfit evaluation.
Like this certain phase interferences may be efficiently excluded.
``distance_max``
is a maximum target distance to the source used to exclude targets farther than this. Tailored to the problem, too far away targets will not be considered in the misfit evaluation. Like this certain phase interferences may be efficiently excluded.
``mt_type``: configures the type of moment tensor. The source model can be set to be a full moment tensor
(`` mt_type: full``) or can be constrained to a deviatoric moment tensor (``mt_type: deviatoric``) or
even to a pure double couple source (``mt_type: dc``).
``mt_type``
configures the type of moment tensor. The source model can be set to be a full moment tensor (`` mt_type: full``) or can be constrained to a deviatoric moment tensor (``mt_type: deviatoric``) or even to a pure double couple source (``mt_type: dc``).
**Source parameters**:
(Please check for more details the description of the `Pyrocko Sources`_.)
``ranges``:
``east_shift`` is a relative position in east direction to the reference location
given in 'event.txt'. It is given in meters.
.. rubric :: ``ranges``:
.. glossary::
``north_shift`` is a relative position in north direction to the reference location
given in 'event.txt'. It is given in meters.
``east_shift``
is a relative position in east direction to the reference location given in :file:`event.txt`. It is given in meters.
``depth``: is the depth of the point source in meters.
``north_shift``
is a relative position in north direction to the reference location given in 'event.txt'. It is given in meters.
``time``: is the relative time to the origin time given in 'event.txt' in seconds.
``depth``
is the depth of the point source in meters.
``magnitude``: is the earthquake moment magnitude.
``time``
is the relative time to the origin time given in 'event.txt' in seconds.
``magnitude``
is the earthquake moment magnitude.
``rmnn`` &
``rmee`` &
``rmdd`` &
``rmne`` &
``rmnd`` &
``rmed`` & are the moment tensor components.
``duration``: is the duration of the source time function in seconds.
``rmnn`` & ``rmee`` & ``rmdd`` & ``rmne`` & ``rmnd`` & ``rmed``
are the moment tensor components.
``duration``
is the duration of the source time function in seconds.
**Example configuration**:
@ -155,55 +151,55 @@ particularly for the ``DoubleDCProblem``.
**Non-general problem parameters**:
``distance_min``: is a minimum target distance to the source used to exclude targets closer than this.
Tailored to the problem, too close targets will not be considered in the misfit evaluation.
Finite-rupture effects on near targets may be excluded efficiently with a meaning setting
for this parameter.
``distance_min``
is a minimum target distance to the source used to exclude targets closer than this. Tailored to the problem, too close targets will not be considered in the misfit evaluation. Finite-rupture effects on near targets may be excluded efficiently with a meaning setting for this parameter.
**Source parameters**:
(Please check for more details the description of the `Pyrocko Sources`_.)
``ranges``:
``east_shift``: is a relative position in east direction to the reference location
given in 'event.txt'. It is given in meters.
.. rubric :: ``ranges``:
``north_shift``: is a relative position in north direction to the reference location
given in 'event.txt'. It is given in meters.
.. glossary ::
``east_shift``
is a relative position in east direction to the reference location given in 'event.txt'. It is given in meters.
``depth``: is the depth of the starting point source in meters.
``north_shift``
is a relative position in north direction to the reference location given in 'event.txt'. It is given in meters.
``depth``
is the depth of the starting point source in meters.
``time``: is the relative time to the origin time given in 'event.txt' in seconds.
``time``
is the relative time to the origin time given in 'event.txt' in seconds.
``magnitude``: is the total earthquake moment magnitude.
``magnitude``
is the total earthquake moment magnitude.
``strike1`` &
``dip1`` &
``rake1`` constrain the mechanism of the first double-couple source.
``strike1`` & ``dip1`` & ``rake1``
constrain the mechanism of the first double-couple source.
``strike2`` &
``dip2`` &
``rake2`` constrain the mechanism of the second double-couple source.
``strike2`` & ``dip2`` & ``rake2``
constrain the mechanism of the second double-couple source.
``delta_time``: is the time difference between the two sources in seconds. Needs to be larger
than zero to separate the sources in time and to make source 2 the later source.
``delta_time``
is the time difference between the two sources in seconds. Needs to be larger than zero to separate the sources in time and to make source 2 the later source.
``delta_depth``: is the depth difference of the two sources in meters.
``delta_depth``
is the depth difference of the two sources in meters.
``azimuth``: the azimuth of source 2 with respect to source 1 (clockwise from north) in degrees.
``azimuth``
the azimuth of source 2 with respect to source 1 (clockwise from north) in degrees.
``distance``: is the distance between the two sources in meters. Needs to be larger than
zero to separate the sources in space.
``distance``
is the distance between the two sources in meters. Needs to be larger than zero to separate the sources in space.
``mix``: is a value between ``0`` and ``1`` that defines the relative moment contributions of the sources to the
total moment. In the extreme, with ``mix=0`` all the moment is in the first source and none in the second or else
``mix=1`` put all moment in the second source which leaves none for the first source. ``mix=0.25`` defines three
quarters of the total moment on the first source and one quarter on the second, while obviously ``mix=0.5`` gives
two sources of the same strength.
``mix``
is a value between ``0`` and ``1`` that defines the relative moment contributions of the sources to the total moment. In the extreme, with ``mix=0`` all the moment is in the first source and none in the second or else ``mix=1`` put all moment in the second source which leaves none for the first source. ``mix=0.25`` defines three quarters of the total moment on the first source and one quarter on the second, while obviously ``mix=0.5`` gives two sources of the same strength.
``duration1`` & ``duration2``: are the durations of the first and second source's source time functions,
respectively, in seconds.
``duration1`` & ``duration2``
are the durations of the first and second source's source time functions, respectively, in seconds.
**Example configuration**:
@ -237,75 +233,59 @@ particularly for the ``DoubleDCProblem``.
``RectangularProblem`` configuration
------------------------------------
The rectangular source is a simple finite source model with a rectangular shape and uniform moment or
slip across the rupture plane. It resembles the source model defined by `Haskell (1964)`_, but has a nucleation point
from which spreads a circular rupture. The position of the nucleation point on the rupture plane can
be part of the problem. Uniform and bilateral ruptures are therefore possible. With the ``RectangularProblem``
also directivity effects in the observations of large earthquake may be predicted.
The rectangular source is a simple finite source model with a rectangular shape and uniform moment or slip across the rupture plane. It resembles the source model defined by `Haskell (1964)`_, but has a nucleation point from which spreads a circular rupture. The position of the nucleation point on the rupture plane can be part of the problem. Uniform and bilateral ruptures are therefore possible. With the ``RectangularProblem`` also directivity effects in the observations of large earthquake may be predicted.
The static rectangular source is very similar to the analytical rectangular dislocation source as
described by `Okada (1985)`_, which is embedded in an isotropic elastic half-space. The ``RectangularProblem`` is
therefore well suited to predict near-field static surface displacements observed at GNSS stations or with InSAR.
For a joint optimisation of seismic waveforms and near-field static surface displacements a ``RectangularProblem``
is the appropriate choice.
The static rectangular source is very similar to the analytical rectangular dislocation source as described by `Okada (1985)`_, which is embedded in an isotropic elastic half-space. The ``RectangularProblem`` is therefore well suited to predict near-field static surface displacements observed at GNSS stations or with InSAR. For a joint optimisation of seismic waveforms and near-field static surface displacements a ``RectangularProblem`` is the appropriate choice.
Configuration parameters that common for all problems are listed above and following are parameters
particularly for the ``RectangularProblem``.
Configuration parameters that common for all problems are listed above and following are parameters particularly for the ``RectangularProblem``.
**Non-general problem parameters**:
``decimation_factor``: is only valid for finite sources. It defines a reduced number
of sub-sources that build the finite source rectangle. A reduced
number speeds up the forward modelling but may lead to artefacts
in the source near-field. Default is no decimation
(``decimation_factor: 1``)
``decimation_factor``
is only valid for finite sources. It defines a reduced number of sub-sources that build the finite source rectangle. A reduced number speeds up the forward modelling but may lead to artefacts in the source near-field. Default is no decimation (``decimation_factor: 1``)
**Source parameters**:
(Please check for more details the description of the `Pyrocko Sources`_.)
For the source parameter configuration, please note that the
last three parameters
``nucleation_x``, ``nucleation_y`` and ``time`` are needed
to define the Rectangular Source for the forward modelling
of seismic waveforms. If they are missing waveform targets are
ignored in the optimisation. If only static targets are
defined, the source parameters for the nucleation point and
origin time, if given,
are ignored.
For the source parameter configuration, please note that the last three parameters ``nucleation_x``, ``nucleation_y`` and ``time`` are needed to define the Rectangular Source for the forward modelling of seismic waveforms. If they are missing waveform targets are ignored in the optimisation. If only static targets are defined, the source parameters for the nucleation point and origin time, if given, are ignored.
``ranges``:
``east_shift`` is a relative position in east direction to the reference location
given in 'event.txt'. It is given in meters.
``north_shift`` is a relative position in north direction to the reference location
given in 'event.txt'. It is given in meters.
.. glossary ::
``east_shift``
is a relative position in east direction to the reference location given in :file:`event.txt`. It is given in meters.
``north_shift``
is a relative position in north direction to the reference location given in 'event.txt'. It is given in meters.
``depth``: is the depth of upper fault edge (not centroid!) in meters.
``depth``
is the depth of upper fault edge (not centroid!) in meters.
``length``: is the along-strike length of the fault in meters.
``length``
is the along-strike length of the fault in meters.
``width``: is the along-dip width of the fault in meters.
``width``
is the along-dip width of the fault in meters.
``strike``: is the strike angle of fault against north in degrees.
``strike``
is the strike angle of fault against north in degrees.
``dip``: is the dip angle of fault against horizontal in degrees.
``dip``
is the dip angle of fault against horizontal in degrees.
``rake``: is the rake angle of slip in degrees.
``rake``
is the rake angle of slip in degrees.
``time``: is the relative time to the origin time given in 'event.txt' in seconds.
``time``
is the relative time to the origin time given in 'event.txt' in seconds.
``nucleation_x``: relative horizontal position of the rupture nucleation point
on the fault to the centre location. This parameter may range from -1 to 1.
With 0 being in the centre, -1 being at the left-side fault edge, 1 at the
right-side fault edge, and 0.5 is half-way between centroid and right-side
fault edge.
``nucleation_x``
relative horizontal position of the rupture nucleation point on the fault to the centre location. This parameter may range from -1 to 1. With 0 being in the centre, -1 being at the left-side fault edge, 1 at the right-side fault edge, and 0.5 is half-way between centroid and right-side fault edge.
``nucleation_y``: relative along-dip position of the rupture nucleation point
on the fault to the centre location. This parameter may range from -1 to 1.
With 0 being in the centre, -1 being at the top fault edge, 1 at the bottom
fault edge, and 0.5 is half-way between centroid and bottom fault edge.
``nucleation_y``
relative along-dip position of the rupture nucleation point on the fault to the centre location. This parameter may range from -1 to 1. With 0 being in the centre, -1 being at the top fault edge, 1 at the bottom fault edge, and 0.5 is half-way between centroid and bottom fault edge.
**Example configuration**:


+ 8
- 6
docs/source/method/index.rst View File

@ -272,7 +272,7 @@ The bootstrap method
`Bootstrapping` in Grond (see also `Bootstrapping (Wikipedia) <https://en.wikipedia.org/wiki/Bootstrapping_(statistics)>`_) enables to suppress some types of bias in the optimization results. Observations that are affected by other signals or noise often show large misfits. Also insufficient media models for the forward model can result in high misfit values. Already a few high misfit values may pull the optimisation to a biased optimum. With bootstrapping techinques we can better estimate model parameter uncertainties in an efficient way. These include the propagation of the data error, but also the assessment of modelling errors to some extent.
In Grond the bootstrapping is applied in a number of parallel `bootstrapping chains` where individual bootstrap weights and bootstrap noise is applied to the model misfits. Technically each bootstrap chain carries out its optimization. Find more detail below, at :ref:`babo-optimizer`. (What is an :term:`optimiser`?)
In Grond the bootstrapping is applied in a number of parallel `bootstrapping chains` where individual bootstrap weights and bootstrap noise is applied to the model misfits. Technically each bootstrap chain carries out its optimization. Find more detail below, at :ref:`babo_optimiser`. (What is an :term:`optimiser`?)
In Grond **two** different bootstrapping methods are implemented:
@ -335,19 +335,21 @@ To generate random noise we use functions of the `Kite`_ module. From the noise
**Figure 5**: Residual bootstrap realisation of InSAR surface displacement data in Grond. (A) From data noise we (B) synthesise random correlated data noise, which is then (C) subsampled exactly as the observed data. These perturbation are then added as bootstrap residuals.
.. _optimisation:
Optimisation
============
Grond's modular framework is open for different optimisation schemes, the native optimisation schemes is the so-called `Bayesian Bootstrap Optimisation` (BABO). The :term:`Optimiser` defines the particular :term:`objective function` or objective functions and options for them. The optimiser also defines the model space sampling schemes. Multiple objective functions are realized in parallel running optimisation chains - the bootstrap chains (see below).
.. _babo-optimizer:
.. _babo_optimiser:
The BABO optimiser
------------------
Bayesian Bootstrap Optimisation (BABO)
--------------------------------------
BABO stands for `Bayesian Bootstrap Optimisation` that is done if the optimiser is configured to the full extent. As the name says, `BABO <https://de.wikipedia.org/wiki/Babo_(Jugendsprache)>`_ allows for a source optimisation while providing the full information in the results for a fully Bayesian analysis. BABO is based on `Direct Search`, meaning model parameters are drawn in a randomised way from the defined model space and synthetic data are then calculated to be compared with the observed data. This needs no assumptions on the topology of the misfit space and is appropriate also for highly non-linear problems.
Bayesian bootstrap optimisation `BABO <https://de.wikipedia.org/wiki/Babo_(Jugendsprache)>`_ allows for earthquake source optimisation whilst providing the complete information for a fully Bayesian analysis. BABO is based on `Direct Search`, where random model parameters are drawn from a defined model space. Those synthetic models are then calculated and compared with the :term:`target's <target>` observed data. This needs no assumptions on the topology of the misfit space and is appropriate for highly non-linear problems.
BABO can turn into a simple Monte-Carlo random direct search if some options are switched off. It can also resemble a simulated annealing optimisation approach using a certain problem configuration. Last but not least BABO enables fully probabilistic bootstrapping of the optimisation results. This is realised in parallel with optimisation chains to which bootstrapping weights are applied.
BABO can be configured for a simple Monte-Carlo random direct search. It can also resemble a simulated annealing optimisation approach. Last but not least BABO enables fully probabilistic bootstrapping of the optimisation results. This is realised in parallel with optimisation chains to which bootstrapping weights are applied.
Note:
*Weights* are explained above. The specific weighting is configured with the `targets config`_ used and also with the `problem`_. The *model space* in which the optimisation takes place is defined with the `problem`_. Here described is the sampling and in the context of the multiple objective functions given by the bootstrapping.


+ 16
- 5
src/optimisers/highscore/optimiser.py View File

@ -69,8 +69,11 @@ class BootstrapTypeChoice(StringChoice):
class SamplerPhase(Object):
niterations = Int.T()
ntries_preconstrain_limit = Int.T(default=1000)
niterations = Int.T(
help='Number of iteration for this phase.')
ntries_preconstrain_limit = Int.T(
default=1000,
help='Tries to find a valid preconstrained sample.')
def get_raw_sample(self, problem, iiter, chains):
raise NotImplementedError
@ -620,9 +623,17 @@ class HighScoreOptimiserConfig(OptimiserConfig):
sampler_phases = List.T(
SamplerPhase.T(),
default=[UniformSamplerPhase(niterations=1000),
DirectedSamplerPhase(niterations=5000)])
chain_length_factor = Float.T(default=8.)
nbootstrap = Int.T(default=100)
DirectedSamplerPhase(niterations=5000)],
help='Stages of the sampler. Start with uniform sampling of the model'
' model space and narrow down through directed sampling.')
chain_length_factor = Float.T(
default=8.,
help='Controls the length of each chain: '
'chain_length_factor * nparameters + 1')
nbootstrap = Int.T(
default=100,
help='Number of bootstrap realisations to be tracked simultaneously in'
' the optimisation.')
def get_optimiser(self):
return HighScoreOptimiser(


Loading…
Cancel
Save