Installation

In this section we list requirements and instructions for the installation of TOAST only. For the installation and configuration of SeisComP consult its documentation. Usually TOAST is installed and set up directly by gempa GmbH.

These instructions assume:

  • Ubuntu 24.04 LTS as operating system,

  • sysop as system user and

  • MariaDB as database.

TOAST installation type

Based on the TOAST architecture, several possibilities for the installation exist:

  • As single user setup with TOAST server, TOAST client and GSS all running on the same machine.

  • With TOAST server and GSS running on a server machine and one or more TOAST client machines connecting to it.

  • More complex setups including some redundancy.

In these instructions we describe the most straightforward installation type where all components are installed on the same machine.

Create data directory

  • By default, bathymetry, forecast zones, source regions, map tiles etc. are installed at /home/data.

  • Create the data directory and set the access rights:

    sysop@host:~$ sudo mkdir /home/data
    sysop@host:~$ sudo chown sysop:sysop /home/data
    

Install GSM

gsm (gempa Software Manager) is a command line tool for handling software packages.

  1. Login as sysop and open a terminal

  2. Download, extract and execute gsm:

    sysop@host:~$ mkdir ~/install
    sysop@host:~$ cd ~/install
    sysop@host:~$ wget https://data.gempa.de/gsm/gempa-gsm.tar.gz
    sysop@host:~$ tar -xf gempa-gsm.tar.gz
    sysop@host:~$ cd gsm
    sysop@host:~$ ./gsm
    
  3. If required, install missing dependencies as reported by gsm.

  4. The initial gsm configuration is performed through the command setup which will auto-detect your operating system. Confirm or adapt the suggestions and enter Username, Password and Repository URL provided by gempa.

    sysop@host:~$ ./gsm setup
    

Note

After initial setup of gsm with ./gsm setup, the file gsm.conf contains the configured parameters. Re-run setup to make modifications.

Execute ./gsm -h to list options and consult the file README to get further information.

Install packages using GSM

  • Update the package list

    sysop@host:~$ cd ~/install/gsm
    sysop@host:~$ ./gsm update
    
  • Install the required packages:

    sysop@host:~$ ./gsm install seiscomp recordstream mapprojections quakelink toast-server toast-client gss-server gss-plugin-easywave2 gss-plugin-ewttt bathymetry tidegauges-ioc forecastzones-rtsp world-t
    

Install dependencies

In order for TOAST to work, some system package dependencies have to be met.

  • Install dependencies

    sysop@host:~$ ~/seiscomp/bin/seiscomp install-deps base gui mariadb-server toast gss
    
  • If you want to generate mp4 videos in the TOAST bulletins, you need to install ffmpeg. For Ubuntu and Debian distributions, ffmpeg is installed with the TOAST dependencies, but for RHEL it has to be installed separately:

    sysop@host:~$ sudo ~/seiscomp/bin/seiscomp install-deps toast-ffmpeg
    

Environment variables

SeisComP and gempa modules require a set of system environment variables.

  • Add them to ~/.bashrc:

    sysop@host:~$ ~/seiscomp/bin/seiscomp print env >> ~/.bashrc
    sysop@host:~$ source ~/.bashrc
    

Install database server

Typically MariaDB is used as a replacement for the MySQL database. With the installation of the dependencies above MariaDB should already be installed. After installation the database server has to be secured and started.

  • Make sure MariaDB is installed:

    sysop@host:~$ sudo apt install mariadb-server mariadb-client
    
  • Secure the database. Answer all questions with Y. Define a root password for the database (e.g. mysqlroot).

    sysop@host:~$ sudo mysql_secure_installation
    
  • Optional: database tuning. In /etc/mysql/mariadb.conf.d/50-server.cnf append:

    [mysqld]
    innodb_buffer_pool_size = 2G
    innodb_flush_log_at_trx_commit = 2
    max_allowed_packet = 16777216
    

Create SeisComP and TOAST databases

  • Use the SeisComP control tool to create the databases. Enter names for agencyID, datacenterID and organization. Use the mysql root password from above. Default values for the other parameters should be fine in most cases.

    sysop@host:~$ seiscomp setup
    
  • Alternatively, to create only the TOAST database, you can use the corresponding setup script at $SEISCOMP_ROOT/share/db/tsunami. Execute it to get help.

Create GSS database

The GSS module has its own documentation. Here is an excerpt describing how to create the GSS database.

  • The GSS database has to be created manually. Log in to the DB as root using the password set above (enter the sudo password beforehand if required):

    sysop@host:~$ mysql -u root -p
    
  • Create the gss database:

    MariaDB [(none)]> CREATE DATABASE gss CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
    MariaDB [(none)]> grant usage on gss.* to sysop@localhost identified by 'sysop';
    MariaDB [(none)]> grant all privileges on gss.* to sysop@localhost;
    MariaDB [(none)]> flush privileges;
    MariaDB [(none)]> quit
    
  • Create the gss database tables (sysop system user password):

    sysop@host:~$ mysql -u sysop -p gss < ~/seiscomp/share/db/gss/mysql.sql
    

Enable GPU-based computation

NVIDIA driver

  • The GSS simulation plugin EasyWave can use either the CPU or the GPU for simulations, but on the latter it runs significantly faster.

  • In order to take advantage of GPU computation, an NVIDIA graphics card supporting CUDA is required and the corresponding drivers have to be installed.

  • Please install the NVIDIA drivers according to the used Linux distribution.

Note

In contrast to previous versions of TOAST, in the current version the CUDA toolkit does not have to be installed, as the necessary libraries are included.

Directory/File structure

TOAST is usually installed within a SeisComP environment. The file/directory structure is:

Path

Description

$SEISCOMP_ROOT

SeisComP root directory. Typically $HOME/seiscomp or /opt/seiscomp.

$SEISCOMP_ROOT/etc

Configuration directory containing *.cfg files

$SEISCOMP_ROOT/bin

Binaries (executables)

$SEISCOMP_ROOT/lib

Libraries

$SEISCOMP_ROOT/share/toastd/templates

Default directory for templates which are used for Bulletin templates

$SEISCOMP_ROOT/share/toast/scripts

Default directory for scripts used by the TOAST client (e.g. for dissemination)

$HOME/.seiscomp

System user specific settings for SeisComP applications

$HOME/.seiscomp/toast

System user specific settings for TOAST

$HOME/.seiscomp/gss/[plugins]

Root directory for the GSS plugins

/home/data

Typical location of data directory for maps, bathymetry etc.

Hint

Most installations of TOAST are installed as sysop user and have /home/sysop/ as home directory. Therefore, many examples in this documentation are for this user. Please use your user name and the corresponding home directory instead.

Configuration

Module configuration

Use scconfig ‣ Modules for configuration.

Note

Global parameters can be set either at

  • System ‣ global to set them for all modules or at:

  • gempa ‣ modulname ‣ global to set them only for a specific module.

toastd parameters are set at:

  • Messaging ‣ scmaster ‣ scmaster ‣ queues ‣ production ‣ processors ‣ messages ‣ toastd.

TOAST client parameters are set at:

  • gempa ‣ toast.

GSS parameters are set at:

  • gempa ‣ gss.

The configurations made using scconfig are usually stored in the directory $SEISCOMP_ROOT/etc in text files with ending cfg. If scconfig is switched from system- to user-mode, the files are stored in ~/.seiscomp and take priority. Consult the scconfig documentation for more information.

Example configuration files

Here is a set of example configuration files which can be used as a starting point.

Inventory and Bindings

Via gsm you can install a package with preconfigured tide gauge inventory and bindings for the Global sea monitoring network of IOC.

  1. Login as sysop

  2. Install inventory and bindings:

    sysop@host:~$ cd ~/install/gsm
    sysop@host:~$ ./gsm install tidegauges-ioc
    
  3. Update configuration and write to database:

    sysop@host:~$ seiscomp update-config
    

For more information on how to configure bindings, consult the SeisComP documentation.

Fault geometry configuration

If a tsunami on-the-fly-simulation using EasyWave is initiated and no focal mechanism (moment tensor) is available for the event, then the strike-, dip-, and rake-angles and the depth for the automatic rupture patch generation are looked up in a file containing the information about subduction geometry and local faults (see: Flowchart for the automatic generation of simulations).

This file has to be provided to the toastd and the GSS. The TOAST client retrieves this file from the GSS upon connection.

File location

The file provided by gempa containing the fault definitions is located at: $SEISCOMP_ROOT/share/toast/faults.xml.example. and $SEISCOMP_ROOT/share/gss/faults.xml.example.

This file has to be copied in order to be used and to make modifications introduced by the user persistent throughout TOAST updates.

sysop@host:~$ cd ~/seiscomp/share/toast
sysop@host:~$ cp faults.xml.example faults.xml
sysop@host:~$ cd ~/seiscomp/share/gss
sysop@host:~$ cp faults.xml.example faults.xml

File content and format

The faults file version currently provided (v1.2) contains almost 200 fault lines covering most subduction zones world wide. For instance, it contains all contour lines from the slab2-model between 20 and 80 km depth. The lines at 0 km depth are either from the RUM-model (Gudmundsson & Sambridge, 1998), generated manually according to literature and bathymetry or from the previous version of the file (in which case reference is not set).

XML Format

Below is an example for the format of the file:

 1<gempa faults_version="1.2">
 2  <fault checked="true" depth="0.0" id="005" name="Algeria" reference="doi:10.1002/2014JB011751" type="reverse">
 3    <vertex dip="70" rake="90" strike="76">
 4      <latitude>37.590</latitude>
 5      <longitude>8.995</longitude>
 6    </vertex>
 7    <vertex dip="70" rake="90" strike="81">
 8      <latitude>37.389</latitude>
 9      <longitude>8.023</longitude>
10    </vertex>
11    ...
12  </fault>
13  ...
14  <fault checked="true" depth="20.0" id="021" name="Calabria 20 km #1" reference="Slab2" type="reverse">
15    <vertex dip="36" rake="90" strike="230">
16      <latitude>37.334</latitude>
17      <longitude>13.450</longitude>
18    </vertex>
19    ...
20  </fault>
21  ...
22</gempa>

The file contains several fault elements which have vertex sub-elements. Faults and vertices can be added, modified and removed manually via text editor. The format of the file is described below. Make sure the XML is valid when editing the file (e.g. xmllint –noout faults.xml).

Fault definitions file explanation

Line

Description

1

Version of the fault definitions.

2

Fault description including the attributes
  • checked (if true then the fault is used for patch generation)

  • depth (in km)

  • id (unique)

  • name (arbitrary, can be shown in map view)

  • reference (to fault source)

  • type (reverse for subduction zones, normal, transform)

3

Vertex description including the attributes dip, rake, and strike. For definitions see for instance: openSHA.

4

Latitude coordinate of the vertex.

5

Longitude coordinate of the vertex.

The type affects the way the faults are drawn in map view. Note that in case of reverse, the side the triangles on a fault line point to is left when progressing on the line. Reverse the ordering of the vertices in the XML to change the pointing direction.

The ordering of the vertices is irrelevant for the generation of patches for simulations, as the strike angle is not determined by consecutive vertex coordinates but is an attribute of each vertex.

Maximum fault distance

The parameter patches.maxFaultDist can be configured independently for the toastd, the TOAST client and the GSS. It defines the maximum horizontal distance allowed between epicenter and the closest point in the faults for automatic patch generation and consequently for a simulation to be started. Default value is 1 degree.

Note

If you define your own faults file, make sure that the largest distance between neighboring fault lines belonging to the same geologic feature is not larger than twice the value of patches.maxFaultDist, otherwise there might be a region between lines where no simulations are generated. 1 degree is fine for the default file.

Forecast zones configuration

Forecast zones are geographical regions - oftentimes corresponding to political districts - for which a specific tsunami early warning bulletin is generated. Technically, the forecast zones are associated with forecast points for which simulation results are either computed on-the-fly or by extraction from a precalculated database.

See also: Forecast Zones perspective and: Forecast zones.

You can use gsm to install a set of predefined example forecast zones and points files:

sysop@host:~$ cd install/gsm
sysop@host:~$ ./gsm install forecastzones-rtsp

See Forecast zones and points file formats if you want to generate you own set of forecast zones and points files.

The forecast zones and profiles can be configured using scconfig.

Note

The forecast zones are configured at gempa ‣ toast, while the forecast points are configured at plugin level, e.g. gempa ‣ easywave2 if used together with EasyWave.

First, add a forecastZones profile, configure the parameters and register the profile:

Example:

forecastZones.rtsp.filename = /home/data/forecastzones/rtsp/6.3.1/cfz/CFP_Version_2018Mar14.dbf
forecastZones = rtsp

Then, add a forecastPoints profile, configure the parameters and register the points profile:

Example:

forecastPoints.rtsp.filename = /home/data/forecastzones/rtsp/6.3.1/cfp/CFP_Version_2018Mar14.dbf
forecastPoints = rtsp

Forecast zones and points file formats

Note

Forecast zone and forecast point files are usually provided by the customer. They can be created using GIS software like QGIS. The extent of a forecast zone is related to local administrative districts, typically it is between 50 and 500 km. The number of points in a zone should be such that they cover the geographical area and geological features of the zone and can vary between a couple to a couple tens of points. Consult the example forecast files as a starting point. Consider that runup values for a zone are aggregated as described in Aggregation strategy. Make sure to check the points against the bathymetry used for simulations. See below the suggested naming scheme for the IDs of the zones and points.

Forecast zones

The forecast zones geographical outlines are defined in shapefiles (ending .shp). Attributes data are stored in dBase files (ending .dbf), and a third file (ending .shx) is used as index. The .dbf file may contain any attributes, following are used by TOAST:

Forecast zones metadata

Name

Datatype

Description

Forecast Zones Perspective

EX_BOX_ID

Integer

Unique forecast zone ID

ID

BOX_NAME

String

Forecast zone name

Name

PLACE_NAME

String

Place name

Place

STATE_PROV

String

Province name

Province

COUNTRY

String

Country name

Country

CNTRY_CODE

String

Country abbreviation

Geo code

CATEGORIES

String

Categories

Categories

The EX_BOX_ID (Exclusive Box Id) is mandatory and has to be unique (hence exclusive) as it is used as identifier for the forecast points (see below). All other parameters are optional, but the more information is provided the better. For each forecast zone, arbitrary categories can be assigned in CATEGORIES as a comma-separated string.

Forecast points

For each forecast zone TOAST needs a set of forecast points. The points are stored in binary files in dBase format (ending .dbf). Following attributes in a forecast point file are used by TOAST:

Forecast points metadata

Name

Datatype

Description

Forecast Zones Perspective

CFPNO

String

Unique forecast point ID

ID (upon expanding)

EX_BOX_ID

Integer

Link to forecast zone ID

ID

POINT_Y

Double

Latitude value

Geo code

POINT_X

Double

Longitude value

Geo code

PLACE_NAME

String

Place name

Place

STATE_PROV

String

Province name

Province

COUNTRY

String

Country name

Country

PLACE_NAME, COUNTRY and STATE_PROV are optional and are derived from the associated zone if they are not set.

Note

For the attributes EX_BOX_ID in the forecast zones and CFPNO in the forecast points we recommend a naming scheme using the country phone code. In this way, it is guaranteed that the IDs are unique throughout all zones and points. For instance, for Algeria having code +213 that would be: EX_BOX_ID: 2130001, 2130002, … CFPNO: 21300000001, 21300000002, …

Threat level mapping configuration

Threat level is a property of the forecast zones, and is typically assigned based on runup value of the active simulation. However, more complex mappings are possible. They are defined in the TOAST configuration.

Note

Threat level mapping has been introduced in TOAST in 2023. Before that, threat level could only be visualized using the forecast zones color gradient which uses runup as key. In templates, a clearsilver definition had to be used.

Threat level mapping is set up by creating threatLevel profiles using scconfig and registering the profiles at threatLevels. The threat level profiles have to be registered in descending order, e.g.:

threatLevels = threat-warning,threat-watch,threat-none

In this case, they are assigned the numerical levels 2, 1 and 0 by TOAST. Use these numerical levels as keys for threat level color gradients.

Variables and conditions

  • The first profile whose condition is fulfilled determines the threat level.

  • The variables which can be used generally correspond to the columns in Forecast Zones perspective without spaces (e.g. Geo Code -> GeoCode)

  • Times can be accessed as seconds and milliseconds (e.g. T1Time.s and T1Time.ms)

  • For every variable there is an additional [Variable]Exists variable to check if it is valid (e.g. RunupExists). Use simExists to verify if a simulation is available. Note that if a variable is not valid, it is still initialized to a default value. This is 0 for numeric variables and an empty string for text variables (e.g. T1TimeExists==False -> T1Time.s=0 and T1Time.ms=0).

  • Incident parameters can be accessed in the following way: inc.mag, inc.magType, inc.lat, inc.lon, inc.depth, inc.time, inc.sourceType, inc.sourceTypeComment, inc.sourceOrigin, inc.evalMode, inc.sev.

  • Similarly, simulation parameters can be accessed in the following way: sim.mag, sim.lat, sim.lon, sim.depth, sim.sourceType, sim.sourceTypeComment, sim.status, sim.type, sim.maxTime, sim.availTime.

  • If several simulations are selected, for each simulation a True/False value is returned and they are combined via logical or (e.g. Sim1 returns True and Sim2 returns False, then the overall value is True).

  • The mathematical conditions are evaluated using the Mathematical Expression Library ExprTk which is described here.

Severity concept

Here we give a short description of the new Severity feature which can be accessed in the threat levels via inc.sev. Severity is an incident property which can be used for non-earthquake events which thus do not have a magnitude. It can be set by the user (see: Create artificial incidents) and corresponds to a time span in hours.

The idea is to configure the threat levels in a way that if no magnitude is present, then severity is used and each forecast zone which has T1 below severity is assigned a threat, and for T1 above severity no threat is assigned.

Examples

An example for threat level profiles which depend only on runup value looks like this:

threatLevel.threat-warning.title = "Warning"
threatLevel.threat-warning.condition = "Runup>=3"
threatLevel.threat-watch.title = "Watch"
threatLevel.threat-watch.condition = "Runup>=0.5"
threatLevel.threat-none.title = "No Threat"
threatLevel.threat-none.condition = "RunupExists"

Here is an example for a condition where the threat level additionally depends on forecast zone category:

threatLevel.threat-cat.condition = "(Runup>=3 and 'mainland' in Categories) or (Runup>=2 and 'offshore' in Categories)"

If you want to define threat levels which depend on runup if it exists and otherwise on travel time and magnitude, do:

threatLevel.mag.condition = "RunupExists ? Runup>=3 : T1TimeExists and T1Time.s>=0 and T1Time.s<3600 and sim.mag>=7"

This example uses only severity as a condition:

threatLevel.severity.condition = "T1Time.s/60/60<inc.sev"

Combine these example definitions in order to get the desired results.

Simulation bathymetry files configuration

In order for a tsunami on-the-fly-simulation to be computed (in contrast to a pre-computed scenario), a directory containing the bathymetry file(s) for the simulation backend has to be provided. In case of EasyWave, the directory is configured at easywave2.data.

Example:

easywave2.data = /home/data/bathymetry/

You can use gsm to install a set of bathymetry files for EasyWave:

sysop@host:~$ cd install/gsm
sysop@host:~$ ./gsm install bathymetry

See Source regions configuration on how to configure the default bathymetry for the simulations within a source region.

Creating bathymetry files

TOAST is provided with bathymetries suiting the needs of the customer. Additional bathymetry files for EasyWave can be made by the following procedure:

  • Generate and download a bathymetry grid in geotiff format from NOAA Grid Extract:

    • Select ETOPO1 (bedrock)

    • Click on the icon Select area of interest by rectangle and use the mouse or enter the Area of Interest manually

    • Download Data

  • Convert the file to binary Surfer 6 grd format as used by EasyWave in two steps:

    • Use gdal software to convert the downloaded geotiff file to ArcGIS:

    • gdal_translate -of AAIGrid <geotiff_file.tiff> <ascii_file.asc>

    • Use the script ~/seiscomp/share/toast/scripts/arc2grd.py to convert the ArcGIS file to binary surfer grid:

    • ./arc2grd.py <ascii_file.asc> <surfer_file.grd>

    • move the surfer file to the bathymetry directory

In case of EasyWave, the bathymetry has to be provided in Golden Software Surfer 6 binary (preferred) or text format.

Note

To display the bathymetry which was used for a simulation in map view with color coding, select a simulation and click Bathymetry in the Map Layers panel. Note that this works only for binary, not for text format grid files.

To show the outline of a bathymetry file as green line, go to the Simulation backend settings in the interactive simulation dialog and select the respective bathymetry (grid).

Source regions configuration

Source regions define polygon coordinates within which simulations should be started. See: Flowchart for the automatic generation of simulations.

Use gsm to install a set of predefined example source region files:

sysop@host:~$ cd install/gsm
sysop@host:~$ ./gsm install sourceregions

Using scconfig, add a sourceRegion profile and configure the parameters.

  • sourceRegion.$name.aoi - (Area Of Interest) points to a bna file

  • sourceRegion.$name.name - Points to a bathymetry grd file (without file ending). This is the default bathymetry which is used for simulations within this source region. In the Simulation backend settings of the interactive simulation dialog it is highlighted with a star.

Register the profile at: sourceRegions.

Example

sourceRegion.IndianOcean.aoi = /home/data/sourceregions/IndianOcean.bna
sourceRegion.IndianOcean.name = io_rtsp
sourceRegions = IndianOcean

In the following figure, the sourceRegion defined in the profile above is shown as black line, and the outline of the default bathymetry associated with this sourceRegion is shown in green.

../_images/source_region.png

Source region (black line) and default bathymetry outline (green)

Note

To show source regions as black lines, copy their bna files to one of the two locations:

  • $SEISCOMP_ROOT/share/bna

  • ~/.seiscomp/bna

Create a bna polygon

You can create a BNA polygon manually in TOAST Map perspective. Click and hold the CTRL-key and do a series of left-mouse clicks. On the lower left you can see total length and area covered by the polygon. Then right-mouse click -> Measurements -> Save as BNA/geoJSON File. To save in GeoJSON format use the filename extension .geojson.

Bulletins, templates and Live tabs configuration

Note

With the new TOAST multiuser version released in 2023, template and livetab functionality was extended significantly. The configuration was adapted accordingly.

Previously, templates were configured in TOAST (toast.cfg) and re-read from file system each time before rendering or disseminating. The same, presently configured templates were used for all incidents.

Now, templates are configured at the TOAST server, more precisely in the toastd (TOAST daemon) plugin section of scmaster (file scmaster.cfg). When an incident is created, all configured templates are stored in the database together with the incident. Templates can be edited from within the TOAST GUI. These changes affect only the templates of the currently selected incident.

The Live tab configuration, which is still done at the TOAST GUI (file toast.cfg) supports a template tree (hierarchy) setup.

Template variables were added which can be configured in scmaster and edited with a dedicated variable editor widget in the TOAST GUI.

A revision variable for each template counts the number of times a template has been disseminated.

See: Create warning bulletins and other output using templates on how to create templates for the generation and dissemination of tsunami warning bulletins.

Templates configuration

Concept

The templates are configured in a queue of scmaster, typically the Production queue. The toastd plugin has to be added to the queue so that the templates and template groups can be set up in a tree-like fashion. Templates and groups can be added using the green plus-icon in scconfig ‣ Modules ‣ Messaging ‣ scmaster ‣ queues ‣ production ‣ processors ‣ messages ‣ toastd ‣ bulletins + Template or + Group. Templates and groups have to be registered (linked). The configuration is saved in the file $SEISCOMP_ROOT/etc/scmaster.cfg. It is possible to add a template to more than one group.

Example

../_images/template_tree.png

Template tree with one template (Definitions) and two groups (National, State) at the base.

The template tree above is defined by the following configuration.

# Defines the ordered list of templates.
queues.production.processors.messages.toastd.bulletins.templates = definitions

# Defines the ordered list of templates groups.
queues.production.processors.messages.toastd.bulletins.groups = national, state

# Name of the template.
queues.production.processors.messages.toastd.bulletins.template.definitions.name = Definitions

# Path to template file.
queues.production.processors.messages.toastd.bulletins.template.definitions.file = "@DATADIR@/toast/templates/definitions.cst"

# Name of the group.
queues.production.processors.messages.toastd.bulletins.group.national.name = "National"

# Defines the ordered list of templates.
queues.production.processors.messages.toastd.bulletins.group.national.templates = no_threat, watch

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.national.template.no_threat.name = "No threat"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.national.template.no_threat.file = "@DATADIR@/toast/templates/national/no_threat.txt.cst"

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.national.template.watch.name = "Watch"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.national.template.watch.file = "@DATADIR@/toast/templates/national/watch.txt.cst"

# Name of the group.
queues.production.processors.messages.toastd.bulletins.group.state.name = "State"

# Defines the ordered list of templates groups.
queues.production.processors.messages.toastd.bulletins.group.state.groups = nt, st

# Name of the group.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.name = "Northern Territory"

# Defines the ordered list of templates.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.templates = no_threat, watch

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.template.no_threat.name = "NT No threat"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.template.no_threat.file = "@DATADIR@/toast/templates/state/nt/no_threat.txt.cst"

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.template.watch.name = "NT Watch"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.state.group.nt.template.watch.file = "@DATADIR@/toast/templates/state/nt/watch.txt.cst"

# Name of the group.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.name = "Southern Territory"

# Defines the ordered list of templates.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.templates = no_threat, watch

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.template.no_threat.name = "ST No threat"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.template.no_threat.file = "@DATADIR@/toast/templates/state/st/no_threat.txt.cst"

# Name of the template.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.template.watch.name = "ST Watch"

# Path to template file.
queues.production.processors.messages.toastd.bulletins.group.state.group.st.template.watch.file = "@DATADIR@/toast/templates/state/st/watch.txt.cst"

Template variables configuration

Concept

Template variables are configured in a similar way as the templates. Use scconfig ‣ Modules ‣ Messaging ‣ scmaster ‣ queues ‣ production ‣ processors ‣ messages ‣ toastd ‣ bulletins + Variable. Register the variables at ‣ bulletins. They can be accessed in the templates via ClearSilver syntax. The Template variables panel allows to edit them from within the TOAST GUI via double-click on value. Like the templates, the template variables are associated with an incident. That is, they are stored in the database together with an incident and modifications using the editor affect only the current incident.

Example

# Defines a list of context variables for the bulletin generation. Each
# variable must be defined with a Variable type.
queues.production.processors.messages.toastd.bulletins.variables = test_header

# Name of the variable as being accessed in the template.
queues.production.processors.messages.toastd.bulletins.variable.test_header.name = exerciseTestStr

# The optional initial value of the variable.
queues.production.processors.messages.toastd.bulletins.variable.test_header.value = "TEST -- TEST -- TEST -- TEST"
../_images/template_variable_editor.png

Template variable editor with two variables defined. The variable value can be edited by double-click.

Live tabs configuration

Concept

The Live tabs are configured at the TOAST GUI (toast.cfg). If no Live tabs are configured, per default there is one tab Live tabs in which the complete template tree is available.

Alternatively, an arbitrary number of Live tabs can be configured. Use scconfig ‣ Modules ‣ gempa ‣ toast ‣ liveTab + Live tab profile. Set the title and optionally defaultTemplate, entryPoint to the template tree and buttonText of the dissemination button.

Register the Live tab profiles at liveTabs.

Example

../_images/livetab_state.png

Undocked Live tab State with two groups (Northern, Southern Territory) with each two templates (No threat, Watch). The current template is indicated to the right of the selection button. The default button text Disseminate is changed to Export.

The example configuration is based on the template configuration from above. It has two Live tabs with different entry points (National, State).

# Registration of live tabs.
liveTabs = national, state

# Title of the tab
liveTab.national.title = NATIONAL

# Active template of the live tab. The option expects a path of the template
# tree, e.g., /National/Watch
liveTab.national.defaultTemplate = "/National/Watch"

# Template tree entry point, e.g., /National. This option can be used to limit
# the template selection of the live tab to a specific subtree.
liveTab.national.entryPoint = /National

# Title of the tab
liveTab.state.title = STATE

# Template tree entry point, e.g., /National. This option can be used to limit
# the template selection of the live tab to a specific subtree.
liveTab.state.entryPoint = /State

# Text of the disseminate button
liveTab.state.buttonText = Export

Color profiles, gradients and colors configuration

The default color profiles, gradients and colors for the various features like maximum wave height, forecast zones or bathymetry are stored in the file ~/seiscomp/share/toast/mapstyles.default and the user-defined color profiles, gradients and colors in ~/.seiscomp/toast/mapstyles, both defined in JSON format [1].

The color settings can be changed directly in TOAST using the color editor or color profile editor as described in Create and modify color profiles.

Note

If a gradient or color profile is not properly defined or present, the default gradient is used for the corresponding feature.

Warning

All changes made in ~/seiscomp/share/toast/mapstyles.default are overwritten with the next TOAST update.