Storm surge & waves (WP13)

_ Filling/formating this in is too time consuming and I’m not sure if it is relevant. _
_Please consider task-specific meeting again, to request the information for this one. _

Which applications/models are planned to get into operation in Phase 2
Storm surges are to be predicted using regional configuration of the hydrodynamic model NEMO (+SWAN).

Predicting sea level in the Eastern-Baltic pilot area, planned to be operational in Feb/2024

Status: ready to go, under development
Dev: Configuration of model finished. Scripts to prepare the forecast (From ECMWF mars data) are already operational.
ECFLOW? not for particular configuration. Configuration is operational (once per day) using cron and shellscripts at atos. Ecflow should be developed.

For triggering: 0,1 whether Hectometric data exist in data lake or in the file system.
Trigger should be EDF detection based + Human decision.
NRT testruns: Yes…Definitely we need testing in NRT mode – for stability after applying initialization/boundary forcing. It is Fixed domain.

Triggering

Storm surge impact model should be triggered upon the existence of hectometric meteo data.
EDF (HIDRA based storm surge detector) should output Detection (+ probability) to AVISO?
Further Automated/Manual trigger should launch deode NWP and after it has completed StormSurge workflow for Eastern Baltic can be launched.

- HIDRA storm surge detector for triggering / Adriatic impact model:
– Approach: threshold-based (optihthred…) or other? Manual?: It is a DeepLearning ssh regressor model, which will further allow detection of storm surges and probabilistic triggering.
– Data/parameters needed for triggering: needs a) ECMWF ensemble dataset for n (52) ensembles and 72h hourly mean sea level pressure, u and v 10m wind components. (Further developments require 6-day forecast, but perhaps 72h is enough). b) It requires -72h:0 observation ssh at corresponding station.
– Pilot regions for ssh detection: stations Adriatic sea (Koper harbour), eastern Baltic sea (Pärnu, Haapsalu, Kuressare, Tallinn, Narva-Jõesuu)

All the rest of the implications regarding triggering is subject of EDF developments, in which the members of WP13T3 participate in WP11.

Targeted platform (HPC needed?, EWC?)

P1 work has been conducted on ATOS, should be transferable to LUMI as well.
Has been tested on LUMI and has a suitable compiling environment.
Workflow for EBaltic simulation has not been tested as it depends on availability of mars, cdo, ncks.

Resources: 10-20 min on ~250 cpus (requires additional node due to i/o server, which requires additional/separate node, in slurms’ MPMD execution)

Triggering application (EDF) will remain in ATOS.

Input needs (NWP, other data/auxiliary data), where to access

Meteo:
from mars:
area = 66/9/53/31,
grid = .08/.08,
param = 2t/10u/10v/tp/msl/2d/sp/sf/ssrd/strd/tcc,

Initial:
case A) hotstart files from operational run
case B) -48h:0 spinup from CMEMS Baltic NRT state
case C) Climatology

Boundary: requirements access to CMEMS data api
case A) Hourly data from CMEMS Baltic NRT
copernicus marine subset:
“dataset_id”: “cmems_mod_bal_phy_anfc_PT1H-i”,
“start_datetime”: “${yyyy1}-${mm1}-${dd1}”,
“end_datetime”: “${yyyy2}-${mm2}-${dd2}”,
“minimum_longitude”: 21.5,
“maximum_longitude”: 21.6,
“minimum_latitude”: 57.00,
“maximum_latitude”: 61.00,
“minimum_depth”: 0,
“maximum_depth”: 150,
“variables”: [
“sla”,
“thetao”,
“so”,
“siconc”,
“sithick”
],

case B) // future outlook, HIDRA based openboundary simulator

- to be accessed from FDB/…, (still not sure what is this)
maybe/ depends on if the deode nwp data will be available on LUMI through this…

• - some inline/direct access e.g. on HPC needed? (→ potential speed up e.g. for AQ models) *
  The test-runs using Hectometric NWP data at atos were conducted using the direct output of NWP model // model specific grib files
• - any special needs? parameters not yet considered in NWP output, …*
  It needs specific model configuration/setup (namelists, input grids, interpolation weights.. etc)

For trigger:
Data is acquired via EDF

Expected output, we need to sort out the format management
netcdf, of hourly model parameters
domain: 2D fields: of size 529×455 ; lon,lat: (21.55 … 30.35⁰ E, 56.942 …60.725⁰ N )
hourly: 48 h lead time (as it is promised for deode?)
(perhaps allow 10 min output for SSH, for proper representation of local seiching )

SSH: sea surface height [m]

extended 2D output of ocean variables (not surge related)
SSU: sea surface zonal current vel. [m/s]
SSV: sea surface meridional current vel. [m/s]
SSS: sea surface salinity [g/kg]
SST: sea surface temperature [deg]

extended 2D output of ice variables (not surge related)
ice thickness, concentration and drift: icethic icefrac uice vice

extended 2D output of wave variables (not surge related), when wave coupling will be active
Hsig: significant wave height [m]
Tpeak: spectral peak wave period [s]

NRT monitoring
n/a

What is the timeline? Milestones events?
- application A: Milestone event according the technical proposal is DD/MM/YYYY, if not milestone .. what’s the timeline?
Storm surge detection operational: Nov/2024
Storm surge for Baltic sea operational: Feb/2025

PoC for sector-specific working groups
(needed to help to develop and build up the end-to-end workflow in operations)
I feel that these need further elaboration during second half of P2…
WP13T3
Ilja Maljutenko
Marko Rus
Matjaz Licer
PoC for 3rd line support
dedicated emails of support_stormsurges@deode.com

(to be contacted by 2nd line in case of problems with the operational workflow for this application)