Current Architecture

Operational role

HCMR runs the MEDWAM4 wave model and acts as a Production Unit (PU) of MED-MFC. The operational responsibility is to deliver the generated NetCDF products to the Copernicus Marine Data Store (MDS) correctly and within the applicable Target Delivery Time (TDT).

Main components

HCMR production and primary delivery

Model output is produced on HCMR infrastructure and exposed to the primary delivery node through the NetApp/NFS production storage. The primary operational uploader runs on copernicus01 (historically referred to as Neptune) using mds-medmfc-upload-v9.

JUNO backup path

JUNO, hosted at CMCC, runs its own backup production/upload path and can deliver the same product when the primary HCMR path does not complete.

Copernicus Marine MDS

Delivery uses the MDS FTP buffer. Product files are uploaded first, followed by a DNT (Delivery Note Text/XML). The Delivery Validator checks the transfer, including MD5 checksums, ingests valid files into the Marine Data Lake, and places a response XML in the DNT response area.

Marine Data Lake

After ingestion, the native files become available in Copernicus Marine object storage (CloudFerro/S3). The FTP buffer is not the final publication location.

Monitoring layer

Monitoring is a separate observability layer. It must not become a prerequisite for production. It collects lifecycle state, file availability, upload progress, response state, fallback information and remote publication evidence.

Current architecture

flowchart LR
    F[ECMWF winds /<br/>PHY forcing] --> HPC[HCMR production<br/>MEDWAM4]
    HPC --> NFS[(NetApp / NFS<br/>production files)]

    NFS --> H[copernicus01<br/>mds-medmfc-upload-v9]
    J[JUNO / CMCC<br/>backup model + uploader] --> FTP[MDS FTP Buffer]

    H -->|NetCDF files| FTP
    H -->|DNT XML| FTP
    J -->|Backup files + DNT| FTP

    FTP --> DV[Delivery Validator<br/>MD5 + DNT processing]
    DV --> MDL[(Marine Data Lake<br/>S3 / CloudFerro)]
    DV --> R[DNT Response XML<br/>Ingested=True/False]

    R --> H
    R --> J

    H -.-> M[Monitoring / Event Collector]
    J -.-> M
    MDL -.->|Independent verification| V[Remote Verifier]
    V --> M
    M --> D[Dashboard &<br/>Continuous Event Log]

Solid arrows are part of production delivery. Dotted arrows are monitoring/verification paths and must not become production dependencies.

Important architectural limitation

The current HCMR/JUNO interaction is not strict single-owner orchestration. JUNO can decide to take over based on copernicus01 progress, but Neptune does not currently receive a reliable authoritative success/progress signal back from JUNO. This is the main coordination gap the planned architecture must address.

Connectivity design constraint

The two production nodes should not be assumed to have unrestricted direct connectivity. The future coordinator is therefore designed as a common indirect status/coordination point reachable over HTTPS, while production retains autonomous fallback behavior.