Installation ============ |appname| software package via GSM -------------------------------------- #. Obtain the `GSM `_ script from |gempa| #. Update the package information and install added package(s) with: .. code-block:: bash $ ./gsm update $ ./gsm install shard-server #. Install optional packages, e.g.: .. code-block:: bash $ ./gsm install quakelink Building configuration ====================== |appname| needs to know where stations are located in the building. The inventory that is used to describe stations and instruments is not sufficient for that task. Until more formal schema extensions are available SHARD uses its own configuration. Buildings can be configured with scconfig or directly in :file:`shard.cfg`. The entry point is :confval:`buildings`. This variable holds a list of building IDs that shall be used. Each building ID points to additional entries in the configuration. An example: .. code:: properties # Configure two buildings, A and B buildings = A,B Now only two building IDs are requested but they are not yet configured. That is done with the :confval:`building` prefix, as shown below: .. code:: properties # Configure building A building.A.name = "A building" building.A.description = "Description of building A" building.A.latlon = 1,2 building.A.picture = A.png .. note:: Per default, building pictures are expected to be in "@DATADIR@/shard/apps/assets/images/structure" That piece just configured the meta data of the building itself. The next step is to configure the sensors that are placed in the building. .. code:: properties # Building A has two sensors, top and bottom. These are just IDs and are # not used anywhere else. building.A.sensors = top, bottom Analogous to the building configuration sensors are configured via IDs: .. code:: properties # Name that is shown in the frontend building.A.sensor.top.name = "Top Sensor" building.A.sensor.top.id = AB.STA01 building.A.sensor.top.type = acceleration building.A.sensor.top.imgpos = 100, 200 building.A.sensor.top.channels = HLZ,HLN,HLE That step has to be repeated for sensor **bottom** as well. The channels are appended to the sensor ID to form a full waveform channel ID. In the example above the resulting channel IDs are AB.STA01..HLZ, AB.STA01..HLN and AB.STA01..HLE. If the channels should have a location code then this must be added to the sensor ID: .. code:: properties building.A.sensor.top.id = AB.STA01.00 Then the resulting channel IDs are AB.STA01.00.HLZ, AB.STA01.00.HLN and AB.STA01.00.HLE. .. _shard-avd: AVD configuration ================= Additionally, |appname| needs configured Acceleration, Velocity and Displacement strong motion parameters to monitor the structural health accordingly and to issue warnings and incidents. Those AVD parameters can be defined `globally`, meaning for all buildings, or `building-specific`, only for one building. Building parameters have priority. :confval:`avd.streams` or :confval:`avd.bindings.$name.patterns` define for which streams the configured AVD-parameters should apply. Thresholds ---------- Currently, following trigger parameters are configurable: * :confval:`avd.delayThreshold`, * :confval:`avd.pgaAlert` * :confval:`avd.pgaAlertIntensity`. * :confval:`avd.pgaWarning` * :confval:`avd.pgaWarningIntensity` * :confval:`avd.pgaWatch` * :confval:`avd.pgaWatchIntensity` * :confval:`avd.varianceThreshold` If one of those thresholds is exceeded, a warning or alert is issued. The thresholds can be defined globally and building-vise, e.g.: .. code:: properties # global level avd.pgaAlert = 0.1 # only for building A avd.bindings.A.pgaWarning = 0.05 .. _shard-design: Design spectrum --------------- To monitor the frequency-dependent movement of the building, |appname| uses response spectra in combination with pre-defined design spectra. They can be based, e.g., on design codes of the EC, NEHRP or DIN. | We recommend to define a path to a file that holds the design spectrum for a specific station. All design spectra files have to be stored in :file:`@DATADIR@/stations/design`. Further, we recommend to name the files matching to their stream IDs, e.g., :file:`net.sta.loc.cha.ds`. In that way, other modules like *SIGMA* or *RGSM* can make use the same files. | The other option to define the design spectrum is to give pairs of *(frequency:magnitude)*. | The design spectrum can be defined either `globally` or `building-specific`. | Exemplary: .. code:: properties # global level - defined by pairs avd.referenceSpectrum = 0.5:1, 1:2, -1:3 # only for a building - defined by .ds file. IMPORTANT: path needs to begin with '<' avd.bindings.BUILDING_NAME.referenceSpectrum = <@DATADIR@/stations/design/NET.LOC.STA.CHA.ds .. _shard-fragility: Fragility curve --------------- |appname| allows to display fragility curves. Each curve might represent different damage state probabilities depending on the shaking level (here PGA). The fragility curves must be provided in the OpenQuake NRML format as xml. We support v0.4 and `v0.5 `_ for continuous functions only. For a detailed description see `OpenQuake documentation `_, it is **noted** that: "... the parameters to be defined in the fragility input file are the mean and standard deviation of the intensity measure level (IML) for each damage state, and not the mean and standard deviation of log(IML)." We recommend to define a path to a file that holds the fragility curves for a specific station. All files have to be stored in :file:`@DATADIR@/stations/fragility`. Further, we recommend to name the files matching to their stream IDs, e.g., :file:`net.sta.loc.cha.xml`. In that way, other modules like *SIGMA* or *RGSM* can make use the same files. The fragility curve can be defined either `globally` or `building-specific`. Exemplary: .. code:: properties # # global level avd.fragilityCurves = @DATADIR@/stations/fragility/NET.LOC.STA.CHA.xml # only for a building avd.bindings.BUILDING_NAME.fragilityCurves = @DATADIR@/stations/fragility/NET.LOC.STA.CHA.xml .. _shard-maps: Map properties -------------- The location of maps stored as :cite:t:`tiles` as well as the initial zoom level can be configured. The initial focus is the location of the first building defined in :confval:`buildings`. Maps from :cite:t:`osm` or generated by the user can be included. High resolution maps can also be purchased from :cite:t:`gempa`. `Contact gempa GmbH `_ for the details. #. Add the mbtiles plugin to global parameters and configure :confval:`map.location` and :confval:`map.type` with the map tile file or URL and the map type, respectively. .. code-block:: properties plugins = ${plugins}, mbtiles map.location = [file/map URL] map.type = [type] .. note:: These parameters are typically set by global module configuration in :file:`${SEISCOMP_ROOT}/etc/global.cfg` but they may be overridden in |appname| in :file:`${SEISCOMP_ROOT}/etc/shard.cfg`. #. The maps are available through global parameters but you may adjust map features * Set :confval:`tileDB` to the MBTiles tile database if |appname| should serve tiles itself. Leave it empty if mapURI is configured with a remote tile server in :confval:`apps.mapURI`. .. code-block:: properties tileDB = /home/data/maps/world-11/world-11.mbtiles * For using a remote tile server set :confval:`apps.mapURI`. Provide start values for zoom level {z}, latitude {y} and longitude {x}, e.g.: * locally stored maps, provided by |appname| itself: .. code-block:: properties apps.mapURI = "tiles/{z}/{y}/{x}" * a remote server: .. code-block:: properties apps.mapURI = "http://example.com:8080/tiles/{z}/{x}/{y}" * or a OpenStreetMap server: .. code-block:: properties apps.mapURI = "http://tile.openstreetmap.org/{z}/{x}/{y}.png" .. note:: OpenStreetMap and probably other tile server expect the tile indexes as *z*, *x*, *y* whereas the built-in |appname| tile server expects *z*, *y*, *x*. * Set :confval:`apps.mapZoom` to the initial zoom level when showing the map view.