gestione analisi

[brancomat]

Le analisi hanno tutte endStep zero e cambia il reftime a seconda dell'istante di riferimento.

Dando un grib con 24h di analisi dato in pasto ad arkimaps viene generata un'unica mappa istantanea (e non cumula)

allego come esempio un grib2 con dati orari di precipitazione:
tp.grib.tar.gz

c'è da capire come gestire la cosa, appunto qui poi ne parliamo

[dcesari]

Lasciami indovinare, si tratta del dataset ERG5?!
Dunque, il primo grib è la precipitazione gornaliera, poi seguono le cumulate orarie, per cui magari togliere il primo messaggio potrebbe aiutare, ma probabilmente non basta.
Il punto è che per i campi cumulati (o in generale "statistically processed" su un intervallo) e analizzati (quindi per i quali l'intervallo va indietro nel passato), se in grib1 non c'era una maniera (standard) di scriverli, in grib2 ci sono, a mio avviso, troppi gradi di libertà per poterli scrivere e non è chiaro come avevano in testa di farlo al WMO, per cui noi con libsim ci siamo dati una convenzione che probabilmente non è la stessa che hanno pensato ad ECMWF, tant'è che grib_ls ritorna stepRange pari a 0, come fosse un campo istantaneo.
Credo che dovremmo scoprire intanto come eccodes/magics si aspettano che debbano essere scritti questi tipi di campi, e poi prendere una decisione, dato che comunque questo caso d'uso al momento è limitato a ERG5 e poco altro, se ricodificare tutto in un modo doverso. Quasi certamente la cosa è già stata discussa in passato con @edigiacomo e/o altri.

[brancomat]

In effetti la precipitazione in grib2 complica ulteriormente il problema, ma credo ce ne sia uno a monte (per dire, anche della temperatura istantanea viene fatta un'unica mappa al posto di 24).
Devo ancora verificare ma temo che al momento arkimaps non gestisca più reftime all'interno dello stesso pacco dati.

Più genericamente (per @dcesari):
mi pare di capire che il problema di avere analisi su più ore (cioè serie di grib che hanno endstep 0 ma più reftime per ogni ora della giornata) sia una casistica limitata a prodotti derivati da analisi di dati osservati (erg5, arcis, cumulate radar) ma anche processi di data assimilation (cosmo_2I_assim), mentre nelle corse operative l'analisi è unica e relativa alle 00. 

1. è corretto?
2. è plausibile in generale aspettarsi (o organizzarsi per fare in modo) che le due casistiche non si intersechino?
   ovvero: che un pacco dati proveniente da un dataset contenga solo una tipologia (forecast con analisi singola) o l'altra (analisi su più ore)?

Se la risposta alla 2 è sì, arkimaps potrebbe comportarsi diversamente nella gestione dei dati se gli arriva un pacco dati che abbia endstep 0 per tutti i messaggi e reftime diversi.

[dcesari]

La risposta è positiva ad entrambe! Ovviamente la seconda non la si può garantire al 100%, ma se non è così è più probabile che sia un errore di estrazione dati che una situazione voluta. E in effetti nella procedura di elaborazione su intervalli in libsim c'è questa condizione euristica, perché da qualche parte una strategia di cumulazione deve essere scelta:

https://github.com/ARPA-SIMC/libsim/blob/772e90a28322ead74d9d2cbec5188c8c6cd02f0d/vol7d/stat_proc_engine.F90#L371

[dcesari]

Tornando al grib di partenza, ho capito dove sta il problema di interpretazione di eccodes. Se faccio

grib_set -s typeOfTimeIncrement=2 tp.grib tp2.grb

poi gli intervalli di cumulazione paiono intepretati correttamente da eccodes (stepRange). La spiegazione è qua: https://github.com/ecmwf/eccodes/blob/fd549250dc5fe8f7f07dd242b8e781f73982735f/src/grib_accessor_class_g2end_step.c#L319 ma il motivo della loro scelta non mi è chiaro, ho chiesto lumi ad Andrea se ci procura la citata issue GRIB-488.
Questo, a meno del problema di logica analisi/forecast dovrebbe essere sufficiente a generare una mappa di precipitazioni non nulla.
Dovremo eventualmente considerare di modificare gli standard libsim se questa interpretazione è generalmente accettata.

[dcesari]

2. è plausibile in generale aspettarsi (o organizzarsi per fare in modo) che le due casistiche non si intersechino?
   ovvero: che un pacco dati proveniente da un dataset contenga solo una tipologia (forecast con analisi singola) o l'altra (analisi su più ore)?

Correggo leggermente questa risposta: ci sono dei dataset, tipo quelli di cosmo5 in cui abbiamo mescolato analisi continue e previsioni, e lì stava all'utente non mescolare le cose in estrazione (c'è anche una misteriosissima chiave arkimet proddef:tod=0/1 pensata all'uopo). In tempi più recenti ho tentato di separare questi prodotti analisi/previsione in dataset diversi per non generare confusione. Quindi non escludo che abbiamo in giro dataset con potenziale rischio, però sarebbe poco sensato fare un'estrazione "a cavallo" e pretendere di fare una grafica sensata.

[spanezz]

Sto facendo un po' fatica a partire da questa discussione e distillare una todo list delle cose che devo implementare in arkimaps. Riuscite a farmi un sunto di punti implementativi, o in alternativa pianifichiamo una call per farlo assieme?

[spanezz]

In tutti i modi, in arkimaps c'è una distinzione da i dati che entrano e quelli che sono messi a disposizione delle ricette per renderizzare gli output. Un po' come con le cumulate da decumulare, è possibile definire degli input che sono calcolati a partire dalle analisi, e che generano output con gli step giusti.

Con un po' piú di lavoro è forse possibile anche dire "Per generare la mappa a +12h, per questo input ti serve qualcosa di definito cosí", calcolando la disponibilità di quell'input per quello step usando un algoritmo diverso da endStep di ecCodes.

Se invece le analisi hanno step=0 e reference time che corrisponde a reference time del modello + lo step del modello, e vanno allineati, si può anche considerare di cambiare arkimaps per lavorare a livello di forecast time (che spero sia il nome giusto per definire la somma di reference time e step) invece che a livello di step.

Non saprei proporre, allo stato attuale di quello che riesco a seguire della discussione, una strategia migliore tra queste, o possibili altre strategie. Comunque, ecco, su arkimaps c'è spazio di manovra.

Per facilitare questa discussione sia per me che per voi, oggi ho documentato i vari passaggi seguiti da arkimaps nella sua elaborazione, su https://github.com/ARPA-SIMC/arkimaps/blob/master/RECIPE_WORKFLOW.rst

Ho anche redatto un piccolo glossario di accompagnamento: https://github.com/ARPA-SIMC/arkimaps/blob/master/GLOSSARY.rst

[brancomat]

Dunque, credo che questa issue contenga (almeno) 3 problemi distinti:

1. validazione input (scorporata in validazione input #85)
2. codifica delle precipitazioni nei grib2 di analisi (che rimanderei in un secondo momento)
3. gestione delle analisi

Su quest'ultimo tema:

Se invece le analisi hanno step=0 e reference time che corrisponde a reference time del modello + lo step del modello, e vanno allineati, si può anche considerare di cambiare arkimaps per lavorare a livello di forecast time (che spero sia il nome giusto per definire la somma di reference time e step) invece che a livello di step.

Sommare reftime e step potrebbe essere un'idea risolutiva, a patto di non mischiare analisi e forecast (o più corse di forecast) nello stesso pacco dati (cosa che però in prospettiva potrebbe essere se non gestita almeno segnalata post #85)

[dcesari]

N.B. la somma di reference time e step noi normalmente nel nostro gergo la chiamiamo "verification time".

Grazie per aver fatto ordine nella issue, propongo di limitarci strettamente alla 3. qui

Non sono certo di cogliere tutti le sfaccettature, però secondo me analisi e forecast andrebbero gestiti come casi diversi, purtroppo con un po' di duplicazione. Nel caso analisi l'asse temporale viaggia lungo reference time, mentre nei forecast viaggia lungo step a parità di reference time. È vero che se consideriamo, come anticipato da #85, non accettabile avere un pacco dati con più step e più reference time contemporaneamente (ma si potrebbe anche dire e perché no? li plotto su diversi assi temporali uno per reference time) usare il verification time diventa equivalente, però temo che prima o poi ci possano venire in mente cose che vanno fatte diversamente nei due casi.

[brancomat]

Ok, provo a fare nuova proposta (anche perché la feature di gestire più corse di forecast non sarebbe male):
arkimaps potrebbe lavorare di default in forecast mode (come fa ora), usando solo lo step e (enhancement) accettando più reftime.

Poi (enhancement) potrebbe avere una flag --analysis per switchare ad una modalità dove usa il verification time.

Per essere perfetto gli mancherebbero due puntini che mi sfuggono:

• come gestire più corse di analisi (se in un'analisi l'asse temporale scorre lungo il reftime, manca come informazione il reftime di emissione, e quindi come distinguere due emissioni successive)
• come capire automaticamente se un pacco dati è un'analisi o no (c'è il timeRangeIndicator ma una corsa di forecast potrebbe avere il solo step delle 0 etichettato come analisi)