.. _toastd-plugin: The |toasts| consists of |scmaster| and its plugin |toastd| (|toastdaemon|). |scmaster| is the central process in any |scname| installation. It provides messaging and database write access. The configuration of |scmaster| and its plugins and thus |toastd| is done in the file *scmaster.cfg* (look for *toastd* in the queues). The |toastd| plugin extends |scmaster| by the ability to execute |toast| specific tasks like the automatic triggering of incidents and simulations. It includes the |toast| data model which is necessary to store |toast| objects in the database. |toastd| acts as a processor for all messages sent to its queues. The main purpose is to respond to journal entries sent from clients in order to queue and serialize concurrent operations from multiple clients. The |toastd| plugin can furthermore connect to a |scname| processing queue and create and update |toast| incidents based on configured rules automatically whenever a new |scname| event is created or updated. The plugin configuration also contains the configuration of the templates (bulletins), the automatic simulation profiles, the trigger criteria and others. .. _toastd-queue: Queue Configuration =================== The |toastd| plugin must be loaded into |scmaster| in order to be able to use it as message processor. This can be either done globally or per queue in :file:`scmaster.cfg`. It is assumed that the processing queue is called *production* in the following examples. .. code:: plugins = ${plugins}, toastd or .. code:: queues.production.plugins = toastd Furthermore the processor has to be added to the message processors of the queue. Loading the plugin above only makes the processor known to |scmaster| but it does not use it. This has to be done explicitly: .. code:: queues.production.processors.messages = dbstore, toastd It is recommended to append the |toastd| processor after the *dbstore* processor. This will ensure that objects are persistently stored in the database when |toastd| receives them. .. _toastd-processor: Processor Configuration ======================= The |toastdaemon| needs some additional information in order to work correctly. There are three categories: * Database * |scname| connection for automatic incident synchronization * |gss| connection By default the |toast| database connection string is received via the messaging connection. |scname| supports two kinds of connections: * Direct connection to the database backend * Proxy connection tunneled through the messaging connection The latter one has the advantage that the |toastc| needs no extra connection to the database backend. .. code:: queues.production.processors.messages.toastd.database = mysql://sysop:sysop@localhost/toast The |scname| connection is configured with the source variable: .. code:: queues.production.processors.messages.toastd.source = scmp://host/production With this setting, the |toastd| will connect to the production queue of host and import |scname| events into the *toast* database as |toast| incidents according to its configuration. In order to run simulations, the |gss| (|gssfull|) has to be configured. The configured URL is used from within |toastd| as well from the |toastc| which connects to this queue. So make sure to give it a fully qualified domain name or an IP: .. code:: queues.production.processors.messages.toastd.gss.url = gsss://host:19011 .. _toastd-template: Template Configuration ====================== |toast| uses templates to generate bulletins for dissemination. As templates may be subject to modifications per incident, they are stored in the database per incident together with a set of freely configurable template variables which are evaluated to create the bulletins. .. note:: The syntax used in the following example is a valid alternative to the standard |scname| syntax. When modifying and saving using scconfig standard syntax is employed. .. code:: queues.production.processors.messages.toastd.bulletins { variables = A, B variable.A { name = "A" value = "Text A" } variable.B { name = "B" value = "Text B" } groups = 1, 2 group { 1 { name = "Group One" templates = 1, 2 template { 1 { name = "One" file = /path/to/template/file-1-1 } 2 { name = "Two" file = /path/to/template/file-1-2 } } } 2 { name = "Group Two" templates = 1, 2 template { 1 { name = "One" file = /path/to/template/file-2-1 } 2 { name = "Two" file = /path/to/template/file-2-2 } } } } } .. hint:: For more information consult the |toast| documentation at: Installation and Configuration -> Setup -> Templates configuration :ref:`toast_template_config`. .. _toastd-sim-profiles: Simulation profiles: backend, parameters and source regions =========================================================== Simulation profiles can be used to trigger automatic simulation computation when an incident is automatically created or updated. They allow to define parameters for a specific simulation plugin combined with a source region (Area Of Interest AOI). Using simulation profiles it is possible, for example, to calculate a simulation for one region for 2 hours and to set a different simulation time for another region. Or to define a bathymetry files for a certain region. Use :ref:`gsm ` to install a set of predefined example source region files: .. code-block:: sh sysop@host:~$ cd install/gsm sysop@host:~$ ./gsm install sourceregions Regions can be defined in `BNA `_ or `GeoJSON `_ format. To add a simulation profile for |toastd| using :program:`scconfig`, navigate to scconfig -> scmaster -> queues -> production -> processors -> message -> toastd -> profiles -> automatic, add a profile and configure the parameters. and register the profile at *automatic*. * :confval:`backend` - Simulation backend to be used for this profile (as shown in the simulation dialog, e.g. *EasyWave2*) * :confval:`aoi` - (Area Of Interest) Path to BNA or GeoJSON file * :confval:`profiles.$name.parameters` - Comma separated key/value pairs of simulation parameters, e.g., :confval:`maxTime:120` or :confval:`grid:io_rtsp`. The grid expects the name of the bathymetry without file name ending. Finally register the profile at: :confval:`automatic`. The following example shows how to define a simulation profile for the Indian Ocean. .. code-block:: sh queues.production.processors.messages.toastd.profiles.automatic = io_rtsp queues.production.processors.messages.toastd.profiles.automatic.io_rtsp.backend = EasyWave2 queues.production.processors.messages.toastd.profiles.automatic.io_rtsp.aoi = /home/data/sourceregions/indian_ocean_rtsp.bna queues.production.processors.messages.toastd.profiles.automatic.io_rtsp.parameters = grid:io_rtsp, maxTime:240 See also: :ref:`toast_sim_profiles`. .. _toastd-incident_sync: Incident Synchronization ======================== If a |scname| source has been configured then incidents will be automatically created and updated if |scname| reports new and updated events if the event fulfills the trigger criteria. .. code:: queues.production.processors.messages.toastd.trigger { incident { enable = true minimumMagnitude = 5.0 maximumDepth = 100 } } If an incident exists already then it will be updated in any case, regardless of the trigger criteria. Furthermore simulations will be triggered if an incident has been created or updated based on simulation trigger criteria: .. code:: queues.production.processors.messages.toastd.trigger { simulation { maximumAge = 1800 # Half an hour minimumMagnitude = 6.0 origin.mode = "" # manual | automatic } } These criteria will be checked whenever an incident receives new source values. Furthermore to reduce the number of simulations, a new simulation will only be started if the source of an existing simulation deviates from the new incident source outside allowed limits: .. code:: queues.production.processors.messages.toastd.matching { magnitude.variance = 0.1 depth.variance = 30 # km location.variance = 0.1 # degrees nodalPlane.variance = 1.0 # degrees }