[installation] Change to nightly

This commit is contained in:
2025-10-30 12:04:59 +01:00
parent 2ff097f9d1
commit a31bc45cce
1441 changed files with 60368 additions and 56360 deletions

View File

@ -0,0 +1,528 @@
.. _tutorials_magnitude-region-aliases:
***************************************************
Amplitudes/Magnitudes: Regionalization, Aliases, Mw
***************************************************
You will ...
* Regionalize magnitudes.
* Create new amplitude and magnitude types as aliases from other amplitudes and
magnitudes.
* Map magnitudes to the moment magnitude, Mw.
:Pre-requisites for this tutorial:
* Read the :ref:`concepts section on magnitudes <concepts_magnitudes>`.
* Real-time data for the station must be available locally.
See :ref:`tutorials_waveforms` or :ref:`tutorials_geofon_waveforms`.
* Inventory must be loaded locally.
:Afterwards/Results/Outcomes:
* Regionalized amplitudes and magnitudes
* New amplitude and magnitude types as aliases
* Moment magnitudes
:Time range estimate:
* 60 minutes
-----------
Regionalization
===============
By regionalization, amplitudes and magnitudes can be computed depending on the
region of the source or source-receiver pairs.
Regions are defined by polygons in BNA or GeoJSON files which must be known to
|scname|.
.. _tutorials_amplitudes-region:
Amplitudes
----------
Measuring amplitudes only for sources or pairs of sources and stations in
specific regions is possible by regionalization. The region polygons are defined
by :ref:`magnitude regionalization <tutorials_magnitude-region>`. In
order to use the feature, regionalized amplitudes and magnitudes must have the
same type (name) and regionalization must be activated per amplitude type in
amplitude-type profiles of global bindings.
.. _tutorials_magnitude-region:
Magnitudes
----------
With regionalization magnitudes can be computed with region-dependent parameters.
If magnitude regionalization is configured but a source or source-station pairs
are not considered, no magnitude of the corresponding type is computed.
Setup
~~~~~
The procedure to set up magnitude regionalization is:
#. Create one file which contains the polygons surrounding the regions within
which magnitude parameters shall apply. The polygon files are provided in
:ref:`BNA <sec-gui_layers-vector-format-bna>` or
:ref:`GeoJSON format <sec-gui_layers-vector-format-geojson>` and located as
set out in the :ref:`documentation of map layers <sec-gui_layers>`. The file
can be created from any |scname| GUI application providing maps, e.g.,
:ref:`scmv`.
#. For the desired magnitude type create a magnitude-type profile in global
module configuration. The name of the profile matches the name of the
magnitude, e.g., *MLc* for the :ref:`MLc magnitude <global_mlc>`.
#. Configure the :confval:`magnitudes.MLc.regionFile` parameter with the full
path and name of the polygon file created above.
#. Within the magnitude-type profile create one or more magnitude-region
profile(s) for defining the regionalized parameters applied to the region(s).
The name of a profile corresponds to the name of the polygon contained in the
polygon file to which the parameters shall apply. Use *world* for all regions
not covered by any polygon.
#. Configure the regionalized magnitude parameters of the magnitude-region
profile. Activate the *enable* parameter if you wish to apply this profile.
#. Restart the data processing:
.. code-block:: sh
seiscomp restart
or execute a GUI module.
.. important::
* Parameters which can be configured along with regionalization assume
defaults from global binding parameters but override global bindings
parameters when configured.
* Once regionalization is active, magnitudes for events outside the
defined region(s) will not be computed. For considering such events add
another magnitude-region profile with the name "*world*".
Magnitudes for events outside any other magnitude-region profile will then
be computed according to this profile.
Setup: station corrections
~~~~~~~~~~~~~~~~~~~~~~~~~~
:ref:`Magnitude station corrections <concepts-magnitudes-correction>` can also
be applied in case of reBy regionalization, magnitudes can be computed with region-dependent properties.
Regions are defined by polygons in BNA or GeoJSON files which must be known to
|scname|.gionalization. Simply add the names of the
magnitude-region profile along with the correction parameter to the original
parameter in global module configuration, :file:`global.cfg`, for the respective
magnitude type and station. Use comma separation for multiple regions and colon
for separating the region name from the value.
Example for correcting MLv computed at station GE.UGM:
.. code-block:: properties
module.trunk.GE.UGM.magnitudes.MLv.offset = 0.1, europe:0.2, asia:-0.1
.. note::
The configuration of parameters starting with *module.trunk.* is not
supported by :ref:`scconfig`. All corresponding configurations must be done
by directly editing the configuration file, e.g.,
:file:`seiscomp/etc/global.cfg`.
Application
~~~~~~~~~~~
When configured, regionalization is automatically applied when computing
magnitudes in :ref:`scmag` or :ref:`scolv`.
.. _tutorials_mags_regionalize_testing:
Testing
~~~~~~~
* Regionalization:
#. Start :ref:`scolv` with the option :option:`--debug` and load an event of
interest
.. code-block:: sh
scolv --debug
#. Relocate the event for generating a new origin.
#. Compute magnitudes selecting the magnitude of interest.
#. Inspect the computed magnitudes in the
:ref:`Magnitude tab of scolv <scolv-sec-magnitude-tab>` or read the
debug output listing the considered magnitudes and stations along with
the regionalized parameters.
.. _tutorials_amplitude-aliases:
Amplitude Aliases
=================
Amplitude aliases are new amplitude types based original ones. Such aliases
allow their specific configuration and computation. They can be created and
independent of magnitudes by :ref:`scautopick` and :ref:`scamp` and used for
:ref:`magnitude aliases <tutorials_magnitude-aliases>`.
.. note::
Amplitude aliases make use of the same parameter structure as the initial
amplitude but the parameters must be configured independently.
Setup
-----
#. Global module configuration: Define the alias name in :confval:`amplitudes.aliases`.
Format and example:
.. code-block:: properties
amplitudes.aliases = alias:original amplitude type
amplitudes.aliases = MLc01:MLc
#. Configure the amplitude bindings parameters. The parameters are identical to
those of the original amplitude type except that the name of the original
magnitude must be replaced by the name of the alias. You may thus first
configure the original amplitude and then replace the name.
**Example binding configuration** for MLc01 derived from MLc:
.. code-block:: properties
amplitudes.MLc01.preFilter = BW(3,0.5,12)
amplitudes.MLc01.applyWoodAnderson = true
...
amplitudes.MLc01.enable = true
amplitudes.MLc01.enableResponses = false
amplitudes.MLc01.minSNR = 1.5
amplitudes.MLc01.signalBegin = -1
amplitudes.MLc01.signalEnd = min(tt(S) + 10, 150)
...
amplitudes.MLc01.maxDepth = 50
Repeat the action for all applicable binding profiles.
Instead of adjusting the bindings profiles you may add the configuration to
global or any other module configuration by prepending
*module.trunk.[module]* where *[module]* is to be replaced by the name of the
module including *global*.
**Example global module configuration** in :file:`global.cfg`:
.. code-block:: properties
module.trunk.global.amplitudes.MLc01.preFilter = BW(3,0.5,12)
module.trunk.global.amplitudes.MLc01.applyWoodAnderson = true
...
module.trunk.global.amplitudes.MLc01.enable = true
module.trunk.global.amplitudes.MLc01.enableResponses = false
module.trunk.global.amplitudes.MLc01.minSNR = 1.5
module.trunk.global.amplitudes.MLc01.signalBegin = -1
module.trunk.global.amplitudes.MLc01.signalEnd = min(tt(S) + 10, 150)
...
module.trunk.global.amplitudes.MLc01.maxDepth = 50
Configuration of bindings profiles has the advantage that the parameters are
available on any client connected to the messaging including external
SeisComP systems. Writing to global module configuration may be more simple
than maintaining multiple bindings profiles but the configuration is not
available to clients in external computers/SeisComP systems.
Application
-----------
* For automatic measurement by :ref:`scautopick` or :ref:`scamp` add the alias
name to the list of measured amplitudes in the corresponding module
configuration.
* For using the measured amplitude value with magnitudes, create a
:ref:`magnitude alias <tutorials_magnitude-aliases>`.
Testing
-------
Compute amplitudes with :ref:`scamp` or by magnitude aliases in :ref:`scolv` and
read the debug log output as when testing
:ref:`magnitude aliases <tutorials_mags_aliases_testing>`.
.. _tutorials_magnitude-aliases:
Magnitude Aliases
=================
Magnitude aliases are new magnitude types based original ones. Such aliases
allow their specific configuration and computation. They can be created from
magnitude and amplitude types native in |scname| or from
:ref:`amplitude aliases <tutorials_amplitude-aliases>` which must be defined
first. Unless specified explicitly, the amplitude type
is the base amplitude of the original magnitude.
Other amplitude types or amplitude aliases must be defined first and given
explicitly.
.. note::
Magnitude aliases make use of the same parameter structure as the initial
magnitude but the parameters must be configured independently.
Setup
-----
#. Create a magnitude alias in :file:`global.cfg` by configuring
:confval:`magnitudes.aliases`.
Format:
.. code-block:: properties
magnitudes.aliases = alias:original magnitude type[:amplitude type]
The amplitude type is optional and can be omitted when equal to the type of
the original magnitude.
Example for an alias magnitude, MLc1, derived from the MLc magnitude and
amplitude. Since initial amplitudes and magnitudes are identical, the
amplitude type can be dropped:
.. code-block:: properties
magnitudes.aliases = MLc01:MLc:MLc
magnitudes.aliases = MLc01:MLc
Example for an alias magnitude, MLc1, derived from the MLc magnitude and
amplitude. Since initial amplitudes and magnitudes are different, the
amplitude type must be given and
:ref:`configured independently <tutorials_amplitude-aliases>`
.. code-block:: properties
magnitudes.aliases = MLc01:MLc:MLc01
#. Configure the alias amplitude if any is used.
#. Configure the alias magnitude in **either** way:
* **Adjust binding profiles:** Configure global bindings parameters by
directly adjusting binding profiles.
Parameters of original magnitudes which are supported by magnitude-type
profiles can be set for the magnitude alias in :ref:`scconfig` by creating
a new magnitude-type profile having the name of the magnitude alias.
All other parameters must be written to the binding parameter files using
an external text editor:
#. Read the relevant parameter names of the original magnitude from global
binding, e.g., in :ref:`scconfig` or the binding parameter file.
Parameter names must include the full hierarchy including all sections.
Example for parameter name of original magnitude:
.. code-block:: properties
magnitudes.MLc.parametric.c1
#. Edit all relevant binding parameter files, e.g.,
:file:`seiscomp/etc/key/global/profile_HHZ` in a text editor and set the
values for the alias magnitude. For default values, the parameters do not
need to be set.
Example of resulting parameter for alias magnitude MLc01:
.. code-block:: properties
magnitudes.MLc01.parametric.c1 = 0.6
* **Regionalization:** Set up by :ref:`regionalization <tutorials_magnitude-region>`.
* Consider the tutorial above on
:ref:`magnitude regionalization <tutorials_magnitude-region>`.
* For the name of new magnitude-type profiles now use the new alias name.
.. hint::
When initially configuring amplitude and magnitude aliases, :ref:`scconfig`
does not know which original amplitude and magnitude types are considered and
the corresponding parameters may not be accessible.
The full list of parameters of the alias can, however, be derived from
original types:
#. Open scconfig and configure the original amplitude and magnitude
referenced by the alias.
#. Close scconfig.
#. Open the binding or module configuration file, e.g.,
:file:`seiscomp/etc/key/global/profile_HHZ` or :file:`global.cfg`.
#. Copy or rename the name of the referenced amplitude or magnitude in the
parameters to the name of the alias.
#. Open scconfig. The new parameters are now visible along with the
original one and can be adjusted. You may now remove all
irrelevant parameters of the original magnitude.
This procedure applies to the adjustment of binding profiles and to
regionalization except that regionalization only supports magnitudes.
* **Write bindings parameters to global module configuration:** Manually
adjust the module configuration file, e.g., :file:`global.cfg`. The
operation is not supported by :ref:`scconfig`.
#. Read the relevant parameter names of the original magnitude from global
binding, e.g., in :ref:`scconfig`. The names must include the full
hierarchy including all sections. Example:
.. code-block:: properties
magnitudes.MLc01.parametric.c1
#. Open the module configuration file, e.g.,
:file:`seiscomp/etc/global.cfg` in a text editor.
#. Prepend *module.trunk.global.* to the parameter name and add it along with
its value to the configuration file for all networks and stations.
Example:
.. code-block:: properties
module.trunk.global.magnitudes.MLc01.parametric.c1 = 0.7
For a given network or network and station replace *global* by the
*network* or the *network* and the *station* code. Example for network
CX and station PB01:
.. code-block:: properties
module.trunk.CX.PB01.magnitudes.MLc01.parametric.c1 = 0.7
module.trunk.CX.magnitudes.MLc01.parametric.c1 = 0.7
#. Add the new magnitude name to the configuration of all relevant modules,
e.g., :ref:`scamp`, :ref:`scmag`, :ref:`scevent`, :ref:`scolv`.
.. note::
The parameters starting with *module.trunk.* are not available for
configuration in :ref:`scconfig`.
.. warning::
Binding parameters configured in global module configuration should only
be considered exceptionally. These parameters will
* Override the corresponding parameters configured by regionalization
using the region *world*.
* Not be written to the database and cannot be accessed by SeisComP
modules running on other computers.
Application
-----------
* For automatic computation by :ref:`scmag` add the alias name to the list of
measured magnitudes in the corresponding module configuration.
* For interactive computation choose the magnitude alias name in :ref:`scolv`
when computing magnitudes. The alias may be added to the default magnitudes in
the scolv module configuration.
.. _tutorials_mags_aliases_testing:
Testing
-------
#. Start :ref:`scolv` with the option :option:`--debug` and load an event of
interest
.. code-block:: sh
scolv --debug
#. Relocate the event for generating a new origin.
#. Compute magnitudes selecting the magnitude of interest including the new
alias.
#. Inspect the computed magnitudes in the
:ref:`Magnitude tab of scolv <scolv-sec-magnitude-tab>` or read the
debug output listing the considered magnitude names and aliases along with
the considered parameters and their values. Example where MLc1 is derived
from MLc with a modified maximum depth:
.. code-block:: sh
...
13:30:46 [debug] GE.UGM: MLc1: effective correction (no locale) = 1.00:0.00
13:30:46 [debug] Parameters for magnitude MLc1
13:30:46 [debug] + maximum depth: 50.000 km
13:30:46 [debug] + distance mode: hypocentral
13:30:46 [debug] + minimum distance: -1.000 km
13:30:46 [debug] + maximum distance: 889.561 km
...
.. _tutorials_mags_moment:
Moment Magnitudes
=================
All magnitudes, Mx, can be mapped to a moment magnitude, Mw(Mx) by piecewise
linear interpolation.
.. warning::
Do not map :term:`mB <magnitude, broadband body-wave (mB)>`
or :term:`Mwp <magnitude, broadband P-wave moment (Mwp)>` to Mw since
this is hardcoded already and done automatically by :ref:`scmag`.
Setup
-----
The configuration procedure is:
#. Set up a magnitude-type profile for the original magnitude type in global
module configuration. Use :ref:`scconfig` for creating the profile.
#. Configure the parameter *MwMapping*, which will become available along with
the new profile, e.g., :confval:`magnitudes.MLc.MwMapping`. Alternatively,
add the parameter to :file:`seiscomp/etc/global.cfg`. The parameter is
configured as a list of sample points of a piecewise linear function mapping
from the original magnitude, Mx, to Mw(Mx).
Example for Mw(MLc) based on MLc:
.. code-block:: properties
magnitudes.MLc.MwMapping = MLc_0:Mw(MLc)_0,MLc_1:Mw(MLc)_1,...,MLc_N:Mw(MLc)_N
Any magnitude value outside the configured range is ignored.
The new moment magnitudes will be available along with the original magnitudes
and can be viewed in :ref:`scolv` or :ref:`scesv` and considered by :ref:`scmag`
or :ref:`scevent`.
In order to avoid that :ref:`summary magnitudes <concepts-magnitudes-summary>`
are computed from original magnitudes and mapped Mw together and biased to both,
the original magnitudes can be blocklisted in :ref:`scmag`
(:confval:`summaryMagnitude.blacklist`).
Application
-----------
* Mapped Mw() magnitudes are automatically computed when configured.
* For consideration in summary magnitudes configure and run :ref:`scmag`.
* For consideration in preferred magnitudes configure and run :ref:`scevent` or
select in :ref:`scolv`.
* For interactive computation choose the original magnitude name in :ref:`scolv`
when computing magnitudes.

View File

@ -1,13 +1,14 @@
.. _tutorials_archiving:
*******************************
Set up local waveform archiving
*******************************
**************************
Maintain waveform archives
**************************
You will ...
* Set up :ref:`slarchive` with its necessary bindings
* Set up `purge_datafiles` in crontab
* Control the life-time of waveforms
* Access waveforms
Pre-requisites for this tutorial:
@ -21,11 +22,12 @@ Pre-requisites for this tutorial:
Afterwards/Results/Outcomes:
* Save real-time data in a local archive for later processing.
* See :term:`miniSEED` day files for GE stations in your local :ref:`waveform archive <concepts_waveformarchives>`.
* See :term:`miniSEED` day files for GE stations in your local
:ref:`waveform archive <concepts_waveformarchives>`.
Time range estimate:
* 5 minutes
* 20 minutes
Related tutorial(s):
@ -34,23 +36,40 @@ Related tutorial(s):
----------
**Motivation**:
Without activating archiving, your local Seedlink server
will only keep waveforms for a short time.
Motivation
==========
Without activating waveform archiving, your local :ref:`Seedlink server <seedlink>`
will only keep waveforms for a short period of time.
This makes it hard to review old events, for example.
:ref:`slarchive` is therefore set up and used for archiving real-time waveforms
from a seedlink server.
In this example, we'll arrange for keeping waveforms for one week.
Before starting, you'll need bindings for your stations;
see the tutorials :ref:`tutorials_geofon_waveforms`
or :ref:`tutorials_waveforms`.
The :program:`slarchive` collects data and archives it
locally using a :term:`SDS` file system structure of
nested subdirectories and systematically named files.
Before starting, you'll need ensure to have access to readl-time data from a
:ref:`seedlink` server. To make seedlink bindings for your stations see the
tutorials :ref:`tutorials_geofon_waveforms` or :ref:`tutorials_waveforms`.
Background
==========
:ref:`slarchive` collects data and archives it locally in the directory defined
by :confval:`archive` using a :term:`SDS` file
system structure of nested subdirectories and systematically named files. For
working with the archived data, read the section on
:ref:`tutorials_archiving-access`.
Setup
=====
:ref:`slarchive` requires a module configuration and bindings.
You may configure slarchive using :ref:`scconfig` or by command-line actions.
In scconfig
===========
-----------
#. Under the Modules tab, go to Acquisition, and select :program:`slarchive`.
Here you can see the default parameters used.
@ -71,11 +90,15 @@ In scconfig
should apply to, under "Networks" on the left-hand side of the
bindings tool.
.. warning:: The name 'week' is just a label.
.. warning::
The name 'week' is just a label.
Its functionality comes from changing the value of the `keep` parameter.
Changing the *name* of a binding profile does not change its function.
.. note:: You can also choose which channels should be archived,
.. note::
You can also choose which channels should be archived,
using the ":confval:`selectors`" box.
For instance, you may collect data at several sample rates,
and only wish to archive the highest rate.
@ -93,17 +116,21 @@ In scconfig
Command line
============
------------
You will need to edit each of your top-level key files to refer to
a new binding profile.
e.g.::
e.g.
.. code-block:: sh
$ cd ~/seiscomp/etc/key
$ vi station_GR_CLL
Add the line `slarchive:week` to whatever lines are already there.
Afterwards it will look something like this::
Afterwards it will look something like this
.. code-block:: properties
# Binding references
global:BH
@ -114,7 +141,9 @@ Afterwards it will look something like this::
Repeat this for the top-level key file of each station
you wish this binding to apply to.
Now create the binding profile in the key directory.
This is a file with a name corresponding to the binding profile name; here: 'week' ::
This is a file with a name corresponding to the binding profile name; here: 'week'
.. code-block:: sh
$ cd ~/seiscomp/etc/key
$ mkdir slarchive
@ -129,66 +158,131 @@ This is a file with a name corresponding to the binding profile name; here: 'wee
slarchive is not running
starting slarchive
.. note::
Left unattended, your disk will eventually fill up with archived data.
To prevent this you will need a script like `purge_database`,
which is provided with SeisComP.
This can be run once per day using the `cron` feature of your system.
The command::
Data life cycle
---------------
$ seiscomp print crontab
Left unattended, your disk will eventually fill up with archived data since
:ref:`slarchive` itself does not delete any data.
will print a number of lines to the terminal.
Type `crontab -e` and insert these lines into the crontab file for your
user (typically `sysop`).
Exit your crontab editor.
Displaying your crontab should now show a line for `purge_database`.::
$ crontab -l
20 3 * * * /home/sysop/seiscomp/var/lib/slarchive/purge_datafiles >/dev/null 2>&1
[There may be other lines too.]
Deleting files
~~~~~~~~~~~~~~
This shows you that the `purge_datafiles` script
will run every day at 3:20 a.m.
To prevent your file system from filling up you may delete data using a script
like `purge_database`, provided with |scname|. The script considers duration set
by the *keep* parameter in slarchive bindings for defining the number of days to
keep the data in your archive.
The script can be run once per day using the `cron` feature of your system.
The command
.. code-block:: sh
$ seiscomp print crontab
will print a number of lines with suggested actions to the terminal. Type
`crontab -e` and insert these lines into the crontab file for your user (typically `sysop`).
Exit your crontab editor.
Displaying your crontab should now show a line for `purge_database`.
.. code-block:: sh
$ crontab -l
20 3 * * * /home/sysop/seiscomp/var/lib/slarchive/purge_datafiles >/dev/null 2>&1
[There may be other lines too.]
This shows you that the `purge_datafiles` script will run every day at 3:20 a.m.
.. note::
If you examine the `purge_datafiles` script, you will see that all it does
is look for files with a last modified time older than a certain number
of days ago.
The number of days to keep can be set station-by-station using the
ARCH_KEEP feature.
A convenient way to do this for many stations is with
multiple binding profiles, one for each length of time desired.
If you examine the `purge_datafiles` script, you will see that all it does
is looking for files with a last modified time older than a certain number
of days ago.
The number of days to keep can be set station-by-station using the
ARCH_KEEP feature.
A convenient way to do this for many stations is with
multiple slarchive binding profiles, one for each length of time desired.
Checking archiving is functioning
=================================
Extending disk space
~~~~~~~~~~~~~~~~~~~~
* If :program:`seedlink` is configured correctly, a new station's streams
appears in output from :program:`slinktool`::
In case your file system fills up with data and you do not wish to delete
old ones, you may add an additional harddisk and configure :confval:`archive`
of :program:`slarchive` to store the new data there. Thereafter you may
configure the *combined* or the *sdsarchive* :ref:`global_recordstream` to read
the data from both sources.
$ slinktool -Q : | grep CLL
GR CLL HHZ D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:49.0299
GR CLL HHE D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:45.0299
GR CLL HHN D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:39.2299
Verification
------------
* If :ref:`seedlink` is configured correctly, a new station's streams
appear in output from :ref:`slinktool`
.. code-block:: sh
$ slinktool -Q : | grep CLL
GR CLL HHZ D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:49.0299
GR CLL HHE D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:45.0299
GR CLL HHN D 2020/04/01 01:11:57.6649 - 2020/04/01 07:28:39.2299
This shows three streams being acquired from station 'CLL'.
The second time shown is the time of the most recent data for each stream.
* If :program:`slarchive` is configured correctly, waveform data for the
* If :ref:`slarchive` is configured correctly, waveform data for the
station appears in :program:`slarchive`'s SDS archive directory:
.. code-block:: sh
.. code-block:: sh
$ ls -l seiscomp/var/lib/archive/2020/GR/CLL
total 12
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHE.D
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHN.D
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHZ.D
$ ls -l seiscomp/var/lib/archive/2020/GR/CLL
total 12
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHE.D
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHN.D
drwxr-xr-x 2 user user 4096 Apr 1 06:30 HHZ.D
$ ls -l seiscomp/var/lib/archive/2020/GR/CLL/HHZ.D/
total 12728
-rw-r--r-- 1 user user 5492224 Mar 31 00:04 GR.CLL..BHZ.D.2020.090
-rw-r--r-- 1 user user 7531008 Apr 1 00:03 GR.CLL..BHZ.D.2020.091
$ ls -l seiscomp/var/lib/archive/2020/GR/CLL/HHZ.D/
total 12728
-rw-r--r-- 1 user user 5492224 Mar 31 00:04 GR.CLL..BHZ.D.2020.090
-rw-r--r-- 1 user user 7531008 Apr 1 00:03 GR.CLL..BHZ.D.2020.091
You may read these data files directly using :ref:`scrttv`, e.g.:
.. code-block:: sh
$ scrttv seiscomp/var/lib/archive/2020/GR/CLL/HHZ.D/*
.. _tutorials_archiving-access:
Access to Archived Data
=======================
Archived waveforms can be read or provided in multiple ways depending on the
application.
* Offline reading with :ref:`scrttv`: Read miniSEED files directly using
:ref:`scrttv`, e.g.:
.. code-block:: sh
$ scrttv seiscomp/var/lib/archive/2020/GR/CLL/HHZ.D/*
* Automatically for data processing: |scname| modules such as
:ref:`scautopick` or :ref:`scolv` can read data from SDS
archive with the *sdsarchive* :ref:`global_recordstream` when running on the
same computer.
* External clients: You may provide the data to clients on other
computers using :ref:`scwfas` or :ref:`fdsnws` both providing data via
:cite:t:`fdsn`.
* Direct file access: For directly fetching :term:`miniSEED` waveform data from
archive you may use :ref:`scart` or Linux commands. You may combine scart
with other modules avoiding redundant file storage. Examples:
.. code-block:: sh
$ scart -dEsv -t 2025-02-01T01:00~2025-02-01T01:00 /archive | scrttv -
$ scart -dEsv -t 2025-02-01T01:00~2025-02-01T01:00 /archive | scautopick -I - -d localhost --ep --playback

View File

@ -52,13 +52,13 @@ Check data are available
========================
First, we'll query the upstream Seedlink server, which runs on
host `geofon.gfz-potsdam.de` at port 18000.
host *geofon.gfz.de* at port *18000*.
We do this with SeisComP's :ref:`slinktool` command, giving the ``-L`` option
to :ref:`slinktool`
.. code-block:: sh
$ slinktool -L geofon.gfz-potsdam.de
$ slinktool -L geofon.gfz.de
6C GF01 GF01
6C GF02 GF02
6C GF03 GF03
@ -76,7 +76,7 @@ code GE
.. code-block:: sh
$ slinktool -Q geofon.gfz-potsdam.de | grep ^GE.*BHZ
$ slinktool -Q geofon.gfz.de | grep ^GE.*BHZ
GE ACRG BHZ D 2019/11/28 06:51:48.7500 - 2019/11/28 09:18:32.1000
GE APE BHZ D 2019/11/28 07:40:52.0400 - 2019/11/28 12:22:00.3950
GE ARPR BHZ D 2019/11/27 23:23:27.4400 - 2019/11/28 09:41:22.1500
@ -130,7 +130,7 @@ StationXML format.
.. code-block:: sh
$ wget "http://geofon.gfz-potsdam.de/fdsnws/station/1/query?net=GE&level=response" -O ge.xml
$ wget "http://geofon.gfz.de/fdsnws/station/1/query?net=GE&level=response" -O ge.xml
Option 2: Using WebDC3
@ -144,7 +144,7 @@ from different data centres among other possibilities.
You can find detailed information about WebDC3 in the on-line documentation at
:cite:t:`webdc3-documentation`.
* Go to http://eida.gfz-potsdam.de/webdc3 with a browser.
* Go to http://eida.gfz.de/webdc3 with a browser.
* Click on "Explore stations" and move the slider to select only the current year
and only "Public permanent nets" on the Network type list.
@ -335,10 +335,9 @@ References
.. target-notes::
.. [#WebDC] The WebDC3 service is available at http://eida.gfz-potsdam.de.
See also
.. [#WebDC] The WebDC3 service is available at http://eida.gfz.de. See also
M. Bianchi, *et al.* (2015): WebDC3 Web Interface. GFZ Data Services.
doi:`10.5880/GFZ.2.4/2016.001 <http://dx.doi.org/10.5880/GFZ.2.4/2016.001>`_
.. [#NETPAGES] For instance that of the GEOFON Program, at
https://geofon.gfz-potsdam.de/waveform/archive/network.php?ncode=GE.
https://geofon.gfz.de/waveform/archive/network.php?ncode=GE.

View File

@ -1,278 +0,0 @@
.. _tutorials_magnitude-region-aliases:
****************************************
Magnitudes: Regionalization, Aliases, Mw
****************************************
You will ...
* Regionalize magnitude
* Create new magnitude types as aliases from other magnitudes and amplitudes.
* Map magnitudes to the moment magnitude, Mw
:Pre-requisites for this tutorial:
* Read the :ref:`concepts section on magnitudes <concepts_magnitudes>`.
* Real-time data for the station must be available locally.
See :ref:`tutorials_waveforms` or :ref:`tutorials_geofon_waveforms`.
* Inventory must be loaded locally.
:Afterwards/Results/Outcomes:
* Regionalized magnitudes,
* New magnitude types as aliases.
* Moment magnitudes
:Time range estimate:
* 30 minutes
-----------
.. _tutorials_magnitude-region:
Regionalize Magnitudes
======================
By regionalization, magnitudes can be computed with region-dependent properties.
The procedure to set up magnitude regionalization is:
#. Create one file which contains the polygons surrounding the regions within
which magnitude parameters shall apply. The polygon files are provided in
:ref:`BNA <sec-gui_layers-vector-format-bna>` or
:ref:`GeoJSON format <sec-gui_layers-vector-format-geojson>` and located as
set out in the :ref:`documentation of map layers <sec-gui_layers>`. The file
can be created from any |scname| GUI application providing maps, e.g.,
:ref:`scmv`.
#. For the desired magnitude type create a magnitude-type profile in global
module configuration. The name of the profile matches the name of the
magnitude, e.g., *MLc* for the :ref:`MLc magnitude <global_mlc>`.
#. Configure the :confval:`magnitudes.MLc.regionFile` parameter with the full
path and name of the polygon file created above.
#. Within the magnitude-type profile create one or more magnitude-region
profile(s) for defining the regionalized parameters applied to the region(s).
The name of a profile corresponds to the name of the polygon contained in the
polygon file to which the parameters shall apply. Use *world* for all regions
not covered by any polygon.
#. Configure the regionalized magnitude parameters of the magnitude-region
profile. Activate the *enable* parameter if you wish to apply this profile.
#. Restart the data processing:
.. code-block:: sh
seiscomp restart
or execute a GUI module.
.. important::
* Parameters which can be configured along with regionalization assume
defaults from global binding parameters but override global bindings
parameters when configured.
* Once regionalization is active, magnitudes for events outside the
defined region(s) will not be computed. For considering such events add
another magnitude-region profile with the name "*world*".
Magnitudes for events outside any other magnitude-region profile will then
be computed according to this profile.
Station corrections
-------------------
:ref:`Magnitude station corrections <concepts-magnitudes-correction>` can also
be applied in case of regionalization. Simply add the names of the
magnitude-region profile along with the correction parameter to the original
parameter in global module configuration, :file:`global.cfg`, for the respective
magnitude type and station. Use comma separation for multiple regions and colon
for separating the region name from the value.
Example for correcting MLv computed at station GE.UGM:
.. code-block:: properties
module.trunk.GE.UGM.magnitudes.MLv.offset = 0.1, europe:0.2, asia:-0.1
.. note::
The configuration of parameters starting with *module.trunk.* is not
supported by :ref:`scconfig`. All corresponding configurations must be done
by directly editing the configuration file, e.g.,
:file:`seiscomp/etc/global.cfg`.
.. _tutorials_magnitude-aliases:
Magnitude Aliases
=================
New magnitude types (aliases) can be created based on existing magnitude and
amplitude types but configured specifically.
The procedure to set up magnitude aliases is:
#. Create a magnitude alias in :file:`global.cfg` by configuring
:confval:`magnitudes.aliases`. Example:
.. code-block:: properties
magnitudes.aliases = MLc1:MLc:MLc
#. Configure the alias magnitudes in either way:
* Write bindings parameters to global module configuration or
* Set up :ref:`regionalization <tutorials_magnitude-region>`:
**Binding parameters in global module configuration:**
#. Read the relevant parameter names of the original magnitude from global
binding, e.g., in :ref:`scconfig`. The names must include the full
hierarchy including all sections. Example:
.. code-block:: properties
magnitudes.MLc01.parametric.c1
#. Open the module configuration file, e.g.,
:file:`seiscomp/etc/global.cfg` in a text editor.
#. Prepend *module.trunk.global.* to the parameter name and add it along with
its value to the configuration file. Example:
.. code-block:: properties
module.trunk.global.magnitudes.MLc01.parametric.c1 = 0.7
#. Add the new magnitude name to the configuration of all relevant modules,
e.g., :ref:`scamp`, :ref:`scmag`, :ref:`scevent`, :ref:`scolv`.
.. note::
The parameters starting with *module.trunk.* are not available for
configuration in :ref:`scconfig`.
.. warning::
Binding parameters configured in global module configuration should only
be considered exceptionally. These parameters will
* Override the corresponding parameters configured by regionalization
using the region *world*.
* Not be written to the database and cannot be accessed by SeisComP
modules running on other computers.
**Regionalization:**
* Consider the tutorial on
:ref:`magnitude regionalization <tutorials_magnitude-region>` above.
* For the name of the new magnitude-type profile now use the alias name.
.. hint::
When adding the magnitude-region profile in
:ref:`scconfig`, scconfig does not know about the referenced original
magnitude. Therefore, not all possible configuration parameters may be
listed depending on the magnitude, e.g. for MLc. For getting the full
list, first create and configure a magnitude-region profile for the
referenced magnitude.
#. Close scconfig
#. Open the configuration file :file:`global.cfg`
#. Rename the name of the referenced magnitude in the parameters to the
name of the alias.
.. _tutorials_mags_moment:
Moment Magnitudes
=================
All magnitudes, Mx, can be mapped to a moment magnitude, Mw(Mx).
The configuration procedure is:
#. Set up a magnitude-type profile for the original magnitude type in global
module configuration. Use :ref:`scconfig` for creating the profile.
#. Configure the parameter *MwMapping*, which will become available along with
the new profile, e.g., :confval:`magnitudes.MLc.MwMapping`. Alternatively,
add the parameter to :file:`seiscomp/etc/global.cfg`. The parameter is
configured as a list of sample points of a piecewise linear function mapping
from the original magnitude, Mx, to Mw(Mx).
Example for Mw(MLc) based on MLc:
.. code-block:: properties
magnitudes.MLc.MwMapping = MLc_0:Mw(MLc)_0,MLc_1:Mw(MLc)_1,...,MLc_N:Mw(MLc)_N
Any magnitude value outside the configured range is ignored.
.. warning::
Do not map the magnitudes :term:`mB <magnitude, broadband body-wave (mB)>`
and :term:`Mwp <magnitude, broadband P-wave moment (Mwp)>` to Mw since
this is hardcoded already and done automatically by :ref:`scmag`.
The new moment magnitudes will be available along with the original magnitudes
and can be viewed in :ref:`scolv`or :ref:`scesv` and considered by :ref:`scmag`
or :ref:`scevent`.
In order to avoid that :ref:`summary magnitudes <concepts-magnitudes-summary>`
are computed from original magnitudes and mapped Mw together and biased to both,
the original magnitudes can be blocklisted in :ref:`scmag`
(:confval:`summaryMagnitude.blacklist`).
.. _tutorials_mags_regionalize_testing:
Final Tests
===========
* Regionalization:
#. Start :ref:`scolv` with the option :option:`--debug` and load an event of
interest
.. code-block:: sh
scolv --debug
#. Relocate the event for generating a new origin.
#. Compute magnitudes selecting the magnitude of interest.
#. Inspect the computed magnitudes in the
:ref:`Magnitude tab of scolv <scolv-sec-magnitude-tab>` or read the
debug output listing the considered magnitudes and stations along with
the regionalized parameters.
* Magnitude aliases:
#. Start :ref:`scolv` with the option :option:`--debug` and load an event of
interest
.. code-block:: sh
scolv --debug
#. Relocate the event for generating a new origin.
#. Compute magnitudes selecting the magnitude of interest including the new
alias.
#. Inspect the computed magnitudes in the
:ref:`Magnitude tab of scolv <scolv-sec-magnitude-tab>` or read the
debug output listing the considered magnitude names and aliases along with
the considered parameters and their values. Example where MLc1 is derived
from MLc with a modified maximum depth:
.. code-block:: sh
...
13:30:46 [debug] GE.UGM: MLc1: effective correction (no locale) = 1.00:0.00
13:30:46 [debug] Parameters for magnitude MLc1
13:30:46 [debug] + maximum depth: 50.000 km
13:30:46 [debug] + distance mode: hypocentral
13:30:46 [debug] + minimum distance: -1.000 km
13:30:46 [debug] + maximum distance: 889.561 km
...

View File

@ -6,11 +6,14 @@ Installation on Ubuntu
You will ...
* Make a basic |scname| installation
* Make a basic |scname| installation of SeisComP in version 4.0.0 on Ubuntu 20.04
* Make an initial configuration
* Perform function tests
Pre-requisites for this tutorial:
* Internet access
* :ref:`Documentation of installation <installation>`
Afterwards/Results/Outcomes:
@ -51,18 +54,20 @@ but the steps for other Ubuntu versions are similar.
$ sudo addgroup admin
$ sudo usermod -a -G admin,adm,audio sysop
.. note:
.. note::
Adding a new user is not mandatory. You can install under an existing user
directory. Creating a new user is recommended as it allows an easy cleanup
of the system later simply by removing the new user if needed.
#. Check the size and the architecture. This is espcially required when installing
:ref:`pre-compiled packages<tutorials_postinstall_package>`: ::
:ref:`pre-compiled packages<tutorials_postinstall_package>`:
$ df -h
$ cat /etc/issue
$ uname -m
.. code-block:: sh
$ df -h
$ cat /etc/issue
$ uname -m
Compare the available disk space with the requirements given in
the :ref:`installation` section.
@ -75,9 +80,10 @@ but the steps for other Ubuntu versions are similar.
Install from source code
========================
To compile SeisComP from the source code follow the
:ref:`instructions in the development section <build>`. You may later download and add
maps as described below in the :ref:`package section <tutorials_postinstall_package>`.
To compile |scname| from the source code follow the
:ref:`instructions in the development section <build>`. You may later download
and add maps as described below in the
:ref:`Documentation of installation <installation>`.
.. _tutorials_postinstall_package:
@ -85,7 +91,18 @@ maps as described below in the :ref:`package section <tutorials_postinstall_pack
Install pre-compiled release packages
=====================================
You may download and installed pre-compile SeisComP binary package, maps and documentation.
You may install the |scname| packages in either way:
* :ref:`gsm<installation-gsm>` (recommended) a package manager provided by
:cite:t:`gempa`,
* :ref:`manually by extracting packages <installation-manual>`.
Here we refer to the manual extraction of packages. More details are given
in section :ref:`installation`.
You may download and installed pre-compile |scname| binary package, maps and
documentation.
#. Download the appropriate |scname| binary package taking into
account your Linux distribution and the architecture.
@ -99,15 +116,16 @@ You may download and installed pre-compile SeisComP binary package, maps and doc
.. code-block:: sh
wget "https://www.seiscomp.de/downloader/seiscomp-maps.tar.gz"
$ wget "https://www.seiscomp.de/downloader/seiscomp-maps.tar.gz"
* the documentation package. Make sure, the documentation matches your
SeisComP version.
|scname| version.
.. note::
The |scname| packages received from gempa GmbH contain the documentation
for the respective version and no separate download is required.
The |scname| packages received from :cite:t:`gempa-download` contain the
documentation for the respective version and no separate download is
required.
#. Untar the :file:`seiscomp*` files (binary package, maps and documentation)
you will find in your home or downloads directory. For SeisComP in version
@ -180,7 +198,7 @@ You may download and installed pre-compile SeisComP binary package, maps and doc
For PostgreSQL, also see the detailed :ref:`installation` instructions.
.. warning ::
.. warning::
For Ubuntu 18.04 and newer, take care with MariaDB/MySQL installation.
Before the next step, you must set a root password *for MariaDB/MySQL*
@ -250,14 +268,14 @@ Find a detailed description in section :ref:`getting-started` and short guide be
.. hint::
If, when you attempt to run a SeisComP command such as :ref:`scconfig` or
If, when you attempt to run a |scname| command such as :ref:`scconfig` or
:ref:`scolv`, you receive an error message like
.. code-block:: sh
scconfig: command not found
then the most likely explanation is that you have not set your SeisComP
then the most likely explanation is that you have not set your |scname|
environment variables correctly.
Run the `seiscomp` command with the full path to
@ -278,7 +296,7 @@ Find a detailed description in section :ref:`getting-started` and short guide be
Datacenter ID. These are used for Arclink and Seedlink, and in the information
describing data model objects such as origins and events.
#. The `seiscomp` command is a wrapper, which controls the SeisComP modules.
#. The `seiscomp` command is a wrapper, which controls the |scname| modules.
See :ref:`system-management`.
Run something by typing seiscomp followed by a command
@ -296,15 +314,22 @@ Find a detailed description in section :ref:`getting-started` and short guide be
Use 'help [command]' to get more help about a command
#. Start :ref:`scmaster`.
#. Start and test :ref:`scmaster`.
As described in the :ref:`overview`, these are needed for
communication between the SeisComP database and the individual
SeisComP modules.
communication between the |scname| database and the individual
|scname| modules.
.. code-block:: sh
$ seiscomp start scmaster
starting scmaster
$ seiscomp status scmaster
In case errors are reported you should understand the full debug log:
.. code-block:: sh
$ scmaster --debug
#. Install all dependencies needed for the GUI
@ -333,7 +358,7 @@ Find a detailed description in section :ref:`getting-started` and short guide be
$ seiscomp exec scrttv
After seeing the SeisComP splash screen,
After seeing the |scname| splash screen,
you'll likely get an error message "Could not read inventory (NULL)".
After a new installation, that's okay.
Click that box away, and you'll see a screen with

View File

@ -127,12 +127,12 @@ Check it Works
Further Information
===================
* The `URL Builder at GEOFON <https://geofon.gfz-potsdam.de/waveform/builder.php>`_
* The `URL Builder at GEOFON <https://geofon.gfz.de/waveform/builder.php>`_
lets you fill out a form to tailor your request.
The URL to use to make your request is displayed at the bottom of that page.
* More example requests are at the
`FDSNWS description at GEOFON <https://geofon.gfz-potsdam.de/waveform/webservices.php>`_
`FDSNWS description at GEOFON <https://geofon.gfz.de/waveform/webservices.php>`_
* The FDSN Web Services specification document :cite:p:`fdsn-specs` provides the
technical documentation and examples.

View File

@ -1,17 +1,19 @@
.. _tutorials_upgrade:
******************
Upgrading SeisComP
******************
***************************
Updating/Upgrading SeisComP
***************************
You will ...
* Upgrade a SeisComP system
* Update/Upgrade a SeisComP system
* Migrate a SeisComP3 system to a newer SeisComP version
Pre-requisites for this tutorial:
* Tutorial on :ref:`installation <tutorials_postinstall>` and SeisComP previously installed
* :ref:`Documentation of installation <installation>`
* Tutorial on :ref:`installation <tutorials_postinstall>` and |scname|
previously installed
Afterwards/Results/Outcomes:
@ -28,9 +30,10 @@ Background
==========
Installing a new SeisComP :ref:`release version <tutorials_upgrade_versions>`
is typically simple and the step described in :ref:`tutorials_upgrade-normal`
can be applied. **More actions** are required when
Updating/upgrading |scname| to a higher
:ref:`release version <installation_versions>` is typically simple and the
steps described in :ref:`tutorials_upgrade-normal` can be applied.
**More actions** are required when
* Upgrading the major version of SeisComP as described in :ref:`tutorials_upgrade-normal`.
* Upgrading :ref:`from SeisComP3 to SeisComP in version 4.0.0. or higher <tutorials_upgrade_v4>`.
@ -38,66 +41,32 @@ can be applied. **More actions** are required when
SeisComP in version 4 or higher <tutorials_upgrade_seedlink>`.
.. _tutorials_upgrade_versions:
Upgrade vs. update
------------------
SeisComP versions
-----------------
SeisComP has :ref:`developed over time <history>`. The versions can be distinguished
by the name of the release:
* **SeisComP since version 4.0.0** uses release version numbers such as *5.2.1*
where
* 5: major version with changes in API and database schema version, new features,
bug fixed, optimizations,
* 2: minor version with new features, bug fixed, optimizations,
* 1: patch number with bug fixes, optimizations.
.. note ::
When increasing the major version number, an upgrade of
the database is required.
* **SeisComP3** uses release versions, names, numbers and patch numbers.
Full example: *SeisComP3-jakarta-2020.330.02*
* 3: release version
* jakarta: release name
* 2020.330: release number
* 02: patch number
Names are adjusted depending on changes in source code:
* **Release version:** major changes in module groups, functionality, concepts, data model.
Example: SeisComp3 is SeisComP in version 3.0
in comparison to version 2.5 the GUIs were introduced.
* **Release name:** major changes in functionality, concepts, data model.
Example: with SeisComP3-Seattle the new user friendly configuration GUI :ref:`scconfig`
was introduced.
* **Release number:** changes in data model version and/or major changes in applications and optimizations.
The numbers include the year and the day of the year of the software release.
Example: Jakarta-2018.327
* **Patch number:** optimizations of applications without changes in the data model version.
Here we understand that *upgrades* increase the major release version number
while *updates* only increase the minor version or the patch number, see section
:ref:`installation_versions`.
Upgrade SeisComP on multiple machines
-------------------------------------
Upgrading multiple machines
---------------------------
Applications can only connect to a messaging system that runs with a database
in an equal or lower data base schema version. In distributed |scname| systems
one machine host the messaging system and the database and all other machines
are connected to this messaging or are running independently, the |scname|
installation on the machine operating the messaging is always updated last.
in an equal or lower data base schema version. However, upgrading |scname| to a
higher major release version typically increases the database scheme version.
Therefore, in distributed |scname| systems where one machine hosts the messaging
system and the database and all other machines are connected to this messaging,
the |scname| installation on the machine operating the messaging is always
upgraded last.
**Example:** A distributed system includes a processing system with the
messaging system and database and a GUI work station connected to the processing
system:
#. Upgrade the GUI work station
#. Upgrade the processing system, take actions to
:ref:`upgrade the database version <tutorials_upgrade-db>`.
#. :ref:`Upgrade <tutorials_upgrade-normal>` the GUI work station
#. :ref:`Upgrade <tutorials_upgrade-normal>` the processing system, take actions
to :ref:`upgrade the database version <tutorials_upgrade-db>`.
.. note::
@ -110,98 +79,50 @@ system:
.. _tutorials_upgrade_download:
Package Download
================
Package download
----------------
Get the SeisComP package in the latest version or older ones from gempa GmbH or
from the download website of :cite:t:`seiscomp`.
.. note ::
gempa provides :cite:t:`gsm` for convenient and consistent download and
installation of SeisComP and other packages.
Get and install the |scname| package in the any available version from
:cite:t:`gempa` or from the download website of :cite:t:`seiscomp` as described
in section :ref:`installation-packages`.
.. _tutorials_upgrade_changelog:
Documentation of Changes
========================
Documentation of changes
------------------------
The important novelties, optimizations and changes that are available after upgrading
are documented in the change log which can be read
`online <https://www.seiscomp.de/doc/base/changelog.html>`_.
It is recommend to read the change log before taking further actions.
The details can also be found locally in the file
.. code-block:: sh
$SEISCOMP_ROOT/share/doc/seiscomp/CHANGELOG
which is integrated in the :ref:`documentation <sc-changelog>` or accessible
from the *Docs* panel in :ref:`scconfig`.
The important novelties, optimizations and changes that are available after
upgrading are documented in the Changelog which is part of this documentation
and which can also be accessed through the *Docs* panel of :ref:`scconfig`.
The installed locally installed file is
:file:`$SEISCOMP_ROOT/share/doc/seiscomp/CHANGELOG`
The Changelog can also be read
`online <https://www.seiscomp.de/doc/base/changelog.html>`_ but care should be
take that the version number matches your.´
.. note::
New features are regularly advertised and described in detail on the
`News website of gempa GmbH <https://www.gempa.de/news/>`_ and on the
:cite:t:`seiscomp-forum`.
.. _tutorials_upgrade-normal:
Normal Upgrade
==============
The normal upgrade including upgrading the major version of SeisComP takes only
a few steps:
#. :ref:`Download <tutorials_upgrade_download>` the SeisComP package.
#. Stop all SeisComP modules:
.. code-block:: sh
seiscomp stop
#. Install the new packages.
.. note::
Users of external, e.g., |gempa| modules must ensure that these external
modules match the SeisComP release version if they depend on SeisComP
libraries.
#. Test the database schema version and update bindings
.. code-block:: sh
seiscomp update-config
:ref:`Upgrade the database schema version <tutorials_upgrade-db>` if
mismatches are reported.
#. After a successful upgrade, start all modules again and observe the status:
.. code-block:: sh
seiscomp start
seiscomp status started
New major release with the features are regularly advertised and described in
detail on the `News website of gempa GmbH <https://www.gempa.de/news/>`_ and
on the :cite:t:`seiscomp-forum`.
.. _tutorials_upgrade-db:
Upgrade database schema version
===============================
-------------------------------
When installing a new SeisComP release with a higher major version number,
upgrading the database may be required. The database version will be tested and
the required actions will be shown when executing:
When upgrading |scname| to a higher major version number as set out in section
:ref:`tutorials_upgrade-normal`, upgrading the database schema is typically
required, too. The database version will be tested and the required actions will
be reported when executing:
.. code-block:: sh
seiscomp update-config
seiscomp update-config**Special case:**
or when pressing the Update Configuration button in scconfig.
or when pressing the Update Configuration button in :ref:`scconfig`.
An upgrade from version SeisComP3 jakarta-2017.334 to SeisComP in version 5.1.0
will give, e.g.:
@ -219,12 +140,22 @@ will give, e.g.:
* migration to the current version is required. apply the following
scripts in exactly the given order:
* mysql -u sysop -p -D seiscomp -h localhost < /home/sysop/seiscomp/share/db/migrations/mysql/0_10_to_0_11.sql
* mysql -u sysop -p -D seiscomp -h localhost < /home/sysop/seiscomp/share/db/migrations/mysql/0_11_to_0_12.sql
* mysql -u sysop -p -D seiscomp -h l
**Special case:**ocalhost < /home/sysop/seiscomp/share/db/migrations/mysql/0_11_to_0_12.sql
error: updating configuration for scmaster failed
The shown migration scripts can be used directly as given and in the given order:
The shown migration scripts can be used directly as given and in the given
order but you need to first stop all modules writing to or deleting objects from
the database such as :ref:`scmaster`, :ref:`scdb`, :ref:`scardac` or
:ref:`scdbstrip` running on the same or any connected machine, e.g.
* MySQL / MariaDB:
.. code-block:: sh
seiscomp stop scmaster
**Special case:**
Thereafter, apply the migration according to your database:
* MySQL/MariaDB:
.. code-block:: sh
@ -239,13 +170,15 @@ The shown migration scripts can be used directly as given and in the given order
psql -U sysop -d seiscomp -h localhost -W -f /home/sysop/seiscomp/share/db/migrations/postgresql/0_11_to_0_12.sql
Using the migration scripts provides a more user friendly way than copying the
lines of MySQL code from the changelog. In future versions we might add the option
lines of MySQL code from the changelog which was practise in past SeisComP3
versions. In future versions we might add the option
to automatically run the migrations.
.. warning::
Upgrading the database make take some time. Do no interrupt the process!
During this time, the |scname| messaging system is unavailable causing a downtime of the system.
During this time, the |scname| messaging system is unavailable causing a
downtime of the system.
After applying the migration scripts the database should be at the correct version.
Test again with:
@ -254,16 +187,77 @@ Test again with:
seiscomp update-config
After successfully upgrading the database continue your previous upgrade procedure.
After successfully upgrading the database continue your previous upgrade
procedure.
.. _tutorials_upgrade-normal:
Normal Update/Upgrade
=====================
Normal updates/upgrades of the major version of |scname| takes only a few steps:
#. If you are tracking your |scname| installation using :program:`git`
(recommended), ensure all previous changes are committed and the installation
is clean.
#. Stop all SeisComP modules:
.. code-block:: sh
seiscomp stop
#. Download and install the |scname| package as described in section
:ref:`installation-packages`.
#. Understand the Changelog of the installed |scname| as described in section
:ref:`tutorials_upgrade_changelog`.
#. Infrequently configuration parameters require changes which
are documented in the Changelog. You may also scan your configuration for
deprecated or obsolete configuration parameters or values using
`gempa-checkSCconfig.py <https://data.gempa.de/packages/Public/tools/>`_
provided by :cite:t:`gempa`. Apply changes accordingly.
#. The software dependencies may have changed after upgrading. Install them as
described in section :ref:`software_dependencies`.
#. Test the database schema version and update bindings
.. code-block:: sh
seiscomp update-config
:ref:`Upgrade the database schema version <tutorials_upgrade-db>` if
mismatches are reported. The mismatch reports will also give the upgrade
instructions. Repeat *seiscomp update-config* after upgrading the database
schema version.
**Background:** When upgrading the major |scname| version you
typically need to upgrade the database scheme version.
#. After a successful update/upgrade, start all modules again and observe the
status:
.. code-block:: sh
seiscomp start
seiscomp status started
#. If you are tracking your |scname| installation using :program:`git`
(recommended), commit all changes.
.. _tutorials_upgrade_v4:
SeisComP3 to version >=4
Upgrading from SeisComP3
========================
SeisComP in version 4 has some major differences to SeisComP3 which require adjustments.
The main differences are in the :ref:`directories of the SeisComP installation <sec-tutorials_upgrading_path>`
SeisComP in version >=4 has major differences to SeisComP3 which require
adjustments. The main differences are in the
:ref:`directories of the SeisComP installation <sec-tutorials_upgrading_path>`
and the :ref:`messaging system <sec-tutorials_upgrading_messaging>`.
The changes and the required actions are explained below. They must be considered
in addition to the steps set out in section :ref:`tutorials_upgrade-normal`.
@ -274,8 +268,8 @@ in addition to the steps set out in section :ref:`tutorials_upgrade-normal`.
Files and directories
---------------------
With **SeisComP3** all the default installation typically required all modules and configurations
in the directories
With **SeisComP3** all the default installation typically required all modules
and configurations in the directories
* seiscomp3/ , typically $HOME/seiscomp3 or /opt/seiscomp3/
* $HOME/.seiscomp3/
@ -410,14 +404,14 @@ configuration. Migrate the legacy database parameters and configure the new one:
queues.production.groups = ${defaultGroups}, L1PICK, L1LOCATION
* Set groups per queue in :confval:`queues.$name.groups`,
* **Special case:** Set groups per queue in :confval:`queues.$name.groups`,
ignoring groups in :confval:`defaultGroups`
.. code-block:: properties
queues.production.groups = L1PICK, L1LOCATION, AMPLITUDE, PICK, LOCATION, MAGNITUDE, FOCMECH, EVENT, QC, PUBLICATION, GUI, INVENTORY, ROUTING, CONFIG, LOGGING, IMPORT_GROUP, SERVICE_REQUEST, SERVICE_PROVIDE
* Set groups in :confval:`defaultGroups`
* **Special case:** Set groups in :confval:`defaultGroups`
.. code-block:: properties
@ -426,9 +420,9 @@ configuration. Migrate the legacy database parameters and configure the new one:
.. warning::
When setting groups in the queues all groups configured in
:confval:`defaultGroups` will be ignored unless `${defaultGroups}` is used.
Add all groups from :confval:`defaultGroups` to the queues to keep the
default groups.
:confval:`defaultGroups` will be ignored unless `${defaultGroups}` is
used. Add all groups from :confval:`defaultGroups` to the queues to
keep the default groups.
* Add the interface name, currently only *dbstore* is supported. Example for
a queue names *production*
@ -484,9 +478,8 @@ After adjusting the structure, variables and configuration parameters, check if
Seedlink
--------
When upgrading from SeisComp3 Jakrata-2018.327 or older and using :ref:`seedlink`,
consider the sections :ref:`tutorials_upgrade_seedlink` and
:ref:`tutorials_proc_seedlink`.
When upgrading from SeisComp3 in version Jakrata-2018.327 or older and using
:ref:`seedlink`, consider the section :ref:`tutorials_upgrade_2018.327`.
Automatic module check
@ -508,8 +501,10 @@ modules automatically during computer startup, then the startup script must be
adjusted.
Upgrade From SeisComP3 Jakarta-2018.327 or Before
=================================================
.. _tutorials_upgrade_2018.327:
Upgrading From SeisComP3 <= Jakarta-2018.327
============================================
.. _tutorials_upgrade_seedlink:
@ -591,7 +586,7 @@ Script for renaming the seedlink buffer directories:
net=""
while read a b c; do
case $a in
--) break;;
--) break;;tutorials_upgrade_seedlink
name) eval sta=$c;;
network) eval net=$c;;
esac

View File

@ -77,11 +77,11 @@ Examples:
for your playback.
Example for one hour of data from the GE network from
`FDSNWS at GEOFON <https://geofon.gfz-potsdam.de/waveform/webservices/fdsnws.php>`_:
`FDSNWS at GEOFON <https://geofon.gfz.de/waveform/webservices/fdsnws.php>`_:
.. code-block:: sh
wget -O data.mseed "http://geofon.gfz-potsdam.de/fdsnws/dataselect/1/query?net=GE&cha=BH*&starttime=2021-04-01T06:00:00Z&endtime=2021-04-01T07:00:00Z"
wget -O data.mseed "http://geofon.gfz.de/fdsnws/dataselect/1/query?net=GE&cha=BH*&starttime=2021-04-01T06:00:00Z&endtime=2021-04-01T07:00:00Z"
scmssort -u -E data.mseed > [your miniSEED file]
* **CAPS server:** Extract the data from gempa's CAPS server :cite:p:`caps`

View File

@ -39,10 +39,10 @@ First, we'll query the upstream Seedlink server,
to confirm that it has current data.
We do this with SeisComP's :program:`slinktool` command,
giving it the '-L' option to list the available stations.
For this example, we'll use the server at host `geofon.gfz-potsdam.de`
For this example, we'll use the server at host `geofon.gfz.de`
on port 18000 (the default) ::
$ slinktool -L geofon.gfz-potsdam.de
$ slinktool -L geofon.gfz.de
AW VNA1 VNA1
AW VNA2 VNA2
[..]
@ -56,7 +56,7 @@ This can be a long list. It shows the network code and station code of each
of the stations for which data is available from this Seedlink server.
We can restrict the output to our station of interest using `grep`. ::
$ slinktool -Q geofon.gfz-potsdam.de | grep GR.CLL
$ slinktool -Q geofon.gfz.de | grep GR.CLL
GR CLL LHN D 2020/05/06 15:13:41.2249 - 2020/05/06 21:15:28.0299
GR CLL BHZ D 2020/05/06 15:13:41.2249 - 2020/05/06 21:22:13.1300
GR CLL BHN D 2020/05/06 15:13:41.2249 - 2020/05/06 21:22:15.4300