Open dcesari opened 3 years ago
Per il momento abbiamo deciso di mantenere la nostra convenzione e di non prevedere l'uscita di grib2 di analisi "cumulata" in stile Cosmo.
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:
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.
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:
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.
About "Convenzione Cosmo con centre != 78 (non DWD)" Nella conversione dei netcdf di cumulata radar a grib, se si setta:
non funziona, ad esempio, vg6d_transform --comp-stat-proc=1 --comp-step="0 03" filein fileout
Al momento, dopo il commit 977a062d5077fac5a05decc406029f57fd0a93c9 lo stato è il seguente:
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 templateIl prossimo passo sarà eliminare lo stile SIMC.
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
sezione 4, template 4.8
Convenzione Cosmo
sezione 1
sezione 4, template 4.8
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: