The TOAST server consists of scmaster and its plugin toastd (TOAST daemon). scmaster is the central process in any SeisComP installation. It provides messaging and database write access.

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.

It 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 SeisComP processing queue and create and update TOAST incidents based on configured rules automatically whenever a new SeisComP event is created or updated.

The plugin configuration also holds the configuration of the templates (bulletins), the automatic simulation profiles, the trigger criteria and others. The configuration of scmaster and also its plugins is done in the file scmaster.cfg (look for toastd in the queues).

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 scmaster.cfg. It is assumed that the processing queue is called toast in the following examples.

plugins = ${plugins}, toastd

or

queues.toast.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:

queues.toast.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.

Processor Configuration

The TOAST daemon needs some additional information in order to work correctly. There are three categories:

• Database

• SeisComP connection for automatic incident synchronization

• GSS connection

By default the TOAST database connection string is received via the messaging connection. SeisComP 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 TOAST client needs no extra connection to the database backend.

queues.toast.processors.messages.toastd.database = mysql://sysop:sysop@localhost/toast

The SeisComP connection is configured with the source variable:

queues.toast.processors.messages.toastd.source = scmp://host/production

With this setting, the toastd will connect to the production queue of host and import SeisComP events into the toast database as TOAST incidents according to its configuration.

In order to run simulations, the GSS (gempa Simulation Server) has to be configured. The configured URL is used from within toastd as well from the TOAST client which connects to this queue. So make sure to give it a fully qualified domain name or an IP:

queues.toast.processors.messages.toastd.gss.url = gsss://host:19011

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 SeisComP syntax. When modifying and saving using scconfig standard syntax is employed.

queues.toast.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 Templates configuration.

Incident Synchronization

If a SeisComP source has been configured then incidents will be automatically created and updated if SeisComP reports new and updated events if the event fulfills the trigger criteria.

queues.toast.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:

queues.toast.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:

queues.toast.processors.messages.toastd.matching {
    magnitude.variance = 0.1
    depth.variance = 30 # km
    location.variance = 0.1 # degrees
    nodalPlane.variance = 1.0 # degrees
}