Coding of time-processed analyses in grib2

[dcesari]

Abbiamo scoperto (in realtà lo sapevo da un annetto, ma avevo nascosto sotto al tappeto) che i grib2 di cosmo prodotti in modalità analisi, contenenti quantità elaborate su un intervallo (precipitazione cumulata e pochi altri per intenderci), sono codificati diversamente da come avevamo deciso di codificarli noi a suo tempo secondo i nostri standard interni.

Convenzione SIMC

sezione 1

• reference time (year, month, day, etc.) punta all'inizio dell'intervallo di elaborazione
• typeOfProcessedData ignorato ma tipicamente = 1 [Forecast products]

  sezione 4, template 4.8

• forecastTime = 0
• lengthOfTimeRange = durata del periodo di elaborazione
• typeOfTimeIncrement = 1 [Successive times processed have same forecast time, start time of forecast is incremented]
• *OfEndOfOverallTimeInterval (year, month, day, etc.) puntano alla fine dell'intervallo di elaborazione

Convenzione Cosmo

sezione 1

• reference time (year, month, day, etc.) punta alla fine dell'intervallo di elaborazione
• typeOfProcessedData = 2 [Analysis products]

  sezione 4, template 4.8

• forecastTime = 0
• lengthOfTimeRange = durata del periodo di elaborazione
• typeOfTimeIncrement = 2 [Successive times processed have same start time of forecast, forecast time is incremented]
• *OfEndOfOverallTimeInterval (year, month, day, etc.) sbagliato per un bug di Cosmo, ma l'intenzione era la stessa che avevamo nella nostra convenzione, comunque lo ignoriamo di solito

Insomma la grossa differenza è che reference time punta all'inizio o alla fine, la nostra scelta è dettata da questa frase del WMO: "The reference time in section 1 and the forecast time together define the beginning of the overall time interval." v. pag. 28 del doc. WMO che pare dire che abbiamo ragione noi :-).

Al momento, per permettere l'elaborazione dei grib2 di Cosmo (rianalisi SPHERA) ho fatto una modifica per cui se typeOfProcessedData==2 e typeOfTimeIncrement==2 il grib è riconosciuto come "convenzione cosmo" e il reftime interpretato di conseguenza in fase di importazione. In teoria si potrebbe anche fare l'operazione opposta in fase di codifica, cioè se il template fornito ha typeOfProcessedData==2 e typeOfTimeIncrement==2 il reftime viene spostato alla fine e si setta typeOfTimeIncrement resta =2, ma non l'ho fatto per ora. L'unica applicazione nota, oltre a SPHERA, credo che sia l'analisi ERG5, mentre le varie analisi operative di Cosmo sono ancora in grib1.

Non possiamo pensare di ricodificare SPHERA.

Con l'abbandono del nudging per LETKF non mi aspetto in futuro un grande uso di analisi elaborate nel tempo prodotte da Cosmo/Icon, ma qualcosa ci sarà per la qualità dell'aria. (Però ignoro se ICON produce output cumulato in modalità analisi).

Le domande principali sono quindi:

• Sposare la convenzione Cosmo e ricodificare ERG5 (sarebbe un peccato perché la nostra convenzione mi pare più corretta)?
• Implementare la codifica dei grib stile Cosmo anche in scrittura?
• Varie ed eventuali

[dcesari]

Per il momento abbiamo deciso di mantenere la nostra convenzione e di non prevedere l'uscita di grib2 di analisi "cumulata" in stile Cosmo.

[dcesari]

La issue ridiventa attuale in quanto la nostra interpretazione di typeOfTimeIncrement = 1 (v. sopra convenzione SIMC) pare non essere comunemente accettata (v. eccodes oltre che DWD) e comunque va probabilmente interpretata come "medio/cumulo diversi lagged forecast" e non "genero un'analisi continua", per cui ci accingiamo ad abbandonarla.

La "convenzione cosmo" indicata sopra va probabilmente reinterpretata come:

Convenzione Cosmo con centre == 78 (DWD)

sezione 1

• reference time (year, month, day, etc.) punta alla fine dell'intervallo di elaborazione (probabilmente per compatibilità con la vecchia convenzione grib1 DWD, usata anche da noi; coincide con la rappresentazione interna dballe/libsim ma non con la convenzione SIMC grib2)
• typeOfProcessedData = 2 [Analysis products]

sezione 4, template 4.8

• forecastTime = 0
• lengthOfTimeRange = durata del periodo di elaborazione
• typeOfTimeIncrement = 2 [Successive times processed have same start time of forecast, forecast time is incremented]
• *OfEndOfOverallTimeInterval (year, month, day, etc.) punta alla fine dell'intervallo di cumulazione + lengthOfTimeRange volutamente! e non per un bug di Cosmo, la cosa è insensata, ma comunque ignoriamo queste chiavi in input

Convenzione Cosmo con centre != 78 (non DWD)

sezione 1

• reference time (year, month, day, etc.) punta all'inizio dell'intervallo di elaborazione (quindi diversa dalla rappresentazione interna dballe/libsim ma analoga alla convenzione SIMC grib2)
• typeOfProcessedData = 2 [Analysis products]

sezione 4, template 4.8

• forecastTime = 0
• lengthOfTimeRange = durata del periodo di elaborazione
• typeOfTimeIncrement = 2 [Successive times processed have same start time of forecast, forecast time is incremented]
• *OfEndOfOverallTimeInterval (year, month, day, etc.) punta alla fine dell'intervallo di cumulazione come è logico che sia

Altra informazione utile dal WMO nel manuale 306 su grib2 (cito a memoria): "reference time defined in section 1 plus forecast time defined in section 4 define the beginning of the overall time interval" che rende la convenzione DWD sbagliata ma, come detto sopra, probabilmente adottata per compatibilitè con vecchi archivi.

[dcesari]

Al momento i nostri usi interni di queste convenzioni sono limitati a ERG5 e SPHERA.

ERG5 è stato codificato con la convenzione SIMC (+ in aggiunta centre=200, typeOfProcessedData=2) e quindi per convertirlo alla nuova convenzione basterebbe un grib_set -s typeOfTimeIncrement=2,typeOfProcessedData=2 (il secondo ridondante ma non guasta), senza cambiare reftime (che altrimenti sconvolgererebbe gli archivi arkimet).

SPHERA è stata purtroppo generata con centre=78 e quindi si porta dietro il peccato originale della convenzione DWD. Non è pensabile di ricodificarla dato il volume di dati e la sua modalità di archiviazione.

Allo stato attuale (versione 6.5.3) libsim interpreta in lettura la convenzione SIMC e parallelamente la convenzione cosmo come fosse sempre DWD, indipendentemente dal centro (implementata per SPHERA qualche tempo fa) e scrive sempre in coonvenzione SIMC.

Le proposte sono quindi:

• a livello di convezioni adottare per "grib2 cumulati" la convenzione "Cosmo non-DWD" abbandonando quella "SIMC".
• a livello implementativo libsim implementare (già fatto in realtà a meno di un commit) la lettura corretta della nuova convenzione cosmo, distinguendo il caso centre=78 dal caso generico, in modo da non compromettere SPHERA, mantenendo la scrittura stile SIMC, e successivamente forzare la scrittura in modalità Cosmo nel momento in cui saremo certi di volerlo fare (anche quasi subito).

[dcesari]

Attenzione, a livello ad es. di archivi arkimet, usando dati con convenzioni SIMC o Cosmo non DWD il reftime punta all'inizio dell'intervallo, per cui un'estrazione per reftime fornisce dati diversi rispetto a quelli attesi nel caso di estrazioni da dataset analoghi bufr o grib1; con grib2 l'intervallo di cumulazione "sporge" in avanti rispetto all'intervallo di estrazione, negli altri casi all'indietro.

[virginiapoli]

About "Convenzione Cosmo con centre != 78 (non DWD)" Nella conversione dei netcdf di cumulata radar a grib, se si setta:

• typeOfTimeIncrement = 2

non funziona, ad esempio, vg6d_transform --comp-stat-proc=1 --comp-step="0 03" filein fileout

[dcesari]

Al momento, dopo il commit 977a062d5077fac5a05decc406029f57fd0a93c9 lo stato è il seguente:

• i 3 stili (SIMC, Cosmo centro 78, Cosmo centro non 78) sono riconosciuti in lettura
• in scrittura di default viene usato lo stile SIMC, ma si può attivare lo stile Cosmo settando la variabile d'ambiente LIBSIM_G2COSMO_BEHAVIOR ad un valore non nullo, lo stile centro 78 o meno viene scelto in base al centro codificato nel messaggio grib usato come template

Il prossimo passo sarà eliminare lo stile SIMC.