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 #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)

[spanezz]

Altra possibilità può essere definire che un input è un'analisi invece di un forecast, e usare questa definizione per filtraggi e assegnazioni dello step giusto. In questo modo si possono avere potenzialmente input derivati calcolati a partire da un'analisi e un forecast, se serve.

Rimane il come capire automaticamente quando un GRIB è una cosa o l'altra, non ricordo se ci sia già la distinzione nel timerange e sia effettivamente usata

[dcesari]

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)

L'analisi è di per se un processo continuo unidimensionale, per cui c'è un unico tempo che è il reftime, ha meno gradi di libertà di un dataset di forecast, quindi questo problema secondo me non si pone (a meno che non mi sfugga qualcosa).

Dal punto di vista dei nostri metadati non è distinguibile (purtroppo o per fortuna?) un dato di forecast a step 0 da un dato di analisi (v. il problema del dataset IFS che hai sollevato ieri). In grib2 c'è anche una chiave typeOfProcessedData (v. /usr/share/eccodes/definitions/grib2/tables/11/1.4.table) che attualmente non gestiamo in libsim ma che dovremmo forse farlo . In ogni caso non la prenderei come oro colato, per cui supporto la proposta citata sotto:

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.

Questo avrebbe anche il vantaggio di permettere un caso, esotico ma forse neanche troppo, in cui qualcuno voglia trattare come analisi un dataset di forecast con reference time successivi regolari e in cui tutti gli step sono uguali tra loro ma >0 (oltre a poter gestire più reference time di forecast contemporaneamente).

* 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)

Di questa avevo parlato sopra nella issue descrivendo l'euristica in libsim, possiamo tentare di indovinarlo, ma a sto punto se inplementiamo --analysis siamo a posto, no? Eventualmente si dovrà prevedere una flag equivalente in libsim per fare l'override dell'autodetection euristico ed avere un comportamento coerente nelle eventuali cumulazioni & c.

[brancomat]

A seguito di chiarimenti telefonici con @spanezz, si diceva che il primo step è l'introduzione del reftime nella gestione degli input, tema scorporato nella #88

Una volta chiusa quella partita, si passa a introdurre una flag --analysis che modifichi la logica con cui arkimaps scandisce l'asse temporale (non più lungo end step ma lungo reference time) in modo che ad esempio le cumulate lavorino su più reftime

[spanezz]

Ora che #88 è fatto, non dovrebbe esserci piú confusione tra stessi step di run di modello a differenti reftime.

Per il discorso di cumulate generate a partire da dati di analisi, mi potete dare un campione di dati e un esempio (anche solo descritto) di ricetta?

[dcesari]

Per un dataset di analisi propongo una query tipo questa, se hai accesso all'arkimet interno:

arki-query --data 'reftime: >= 2021-11-26 00:00:00, <= 2021-11-28 19:00:00; product:GRIB1,200,2,2 or GRIB1,200,2,61' \
http://arkimet.metarpa:8090/dataset/lama5_arc

Ho volutamente messo un campo istantaneo e uno cumulato per rendere la vita più difficile, ma se ne può prendere uno solo.

Ho scoperto che in libsim c'era un bug per cui nel caso di cumulazioni di analisi come queste, ad es. su intervalli di 6 ore, l'output conteneva anche i dati per un eventuale intervallo finale non coperto completamente dall'input, quindi chiaramente sbagliati, l'ultimo commit ha corretto questa cosa. Comunque a livello di test di arkimaps non è necessario aggiornare urgentemente, l'importante è sapere che i numeri dell'ultima mappa potrebbero essere sbagliati.

[dcesari]

Volevo aggiungere una cosa, non so come sia attualmente gestita la cumulazione nelle ricette, ma ad ogni modo in vg6d_transform c'è un parametro --comp-full-steps che in casi come questi forza gli intervalli di cumulazione ad intervalli "modulo step" (calcolati prendendo come riferimento l'inizio dell'anno zero alle 00 UTC per quanto possa aver senso) quindi se cumulo su 6 ore, gli intervalli saranno sempre 0-6... 18-0 UTC etc. Se non metto quel parametro invece la cumulazione parte dal primo intervallo utile, il che non è facile da controllare con un'arki-query, perché se ad es. metto reftime >= 00:00 per dati orari, ottengo come prima ora buona le 23:00. Insomma diciamo che nella stragrande maggioranza dei casi --comp-full-steps fa quello che vorrebbe l'utente, quindi credo valga la pena metterlo di default. Se mai ci sarà l'esigenza di toglierlo ci penseremo.

[spanezz]

Vorrei creare un test case con quei dati: mi dite una ricetta rilevante, e i risultati attesi rispetto all'attuale? (immagino che i risultati attesi siano un file per reftime invece di un file per step)

[brancomat]

Se parli di cumulate, allego due casistiche: tp.grib.tar.gz

1) lama5tp.grib precipitazioni orarie in grib1 da modello lamaz (esempio di arki-query descritto sopra da @dcesari): qui un tentativo di processing produce un output singolo per i vari tp1h, tp3h, tp6h, tp12h, tp24h mentre sarebbe lecito aspettarsi ad esempio per le precipitazioni orarie un'immagine per istante 2) erg5tp.grib precipitazioni orarie in grib2 (modificate con il grib_set descritto sopra da Davide) + una precipitazione cumulata giornaliera. Qui per motivi non chiari un tentativo di processing mostra il solo plot della tp24h. Mi aspetterei plot orari e cumulati con come unico problema il fatto che la cumulata a 24h coincide di fatto con il messaggio grib già cumulato, in teoria potrebbe plottare entrambi e tenere di fatto l'ultimo plottato.

le ricette coinvolte sono in particolare recipes/tp_inputs.yaml e le varie recipes/tp{1,3,6,12,24}h.yaml

@dcesari usando --comp-full-steps non ci giochiamo le cumulate trascinate? sui prodotti di sala operativa sono molto gettonate

[spanezz]

tp.grib.tar.gz contiene solo tp.grib, e non lama5tp.grib e erg5tp.grib: immagino sia andato storto qualcosa

[dcesari]

Dunque per i grib2 (erg5tp) temo che dovremo rivedere la codifica di "analisi cumulate" in seguito a quanto discusso sopra in questa issue, per cui mi concentrerei su grib1 (lama5tp), che non intendiamo cambiare.

Il perché ottieni un output singolo (da vg6d_transform o parli di mappe finali?) mi risulta oscuro, posso dare ua mano a capire. In generale mi sfugge che uso fa arkimaps delle chiavi derivate di grib_api tipo stepRange per fare il suo lavoro in questi casi.

Riguardo --comp-full-steps, in realtà inibisce le cumulate trascinate solo nel caso di cumulate per differenza (tipicamente nei forecast). Nel caso nostro delle analisi cumulate per aggregazione, non avevo previsto la possibilità delle cumulate trascinate, non mi è passata per la testa, non so se per difficoltà implementativa o perché inconsapevolmente mi pareva che avesse poco senso. Insomma, nel caso dell'aggregazione il significato di --comp-full-steps, è leggermente diverso, cioè "aggancia gli intervalli ad un intervallo assoluto modulo step anziché partire dal primo intervallo utile" mentre nel caso delle differenze è "calcola solo le cumulate in intervalli relativi modulo step anziché in tutti gli intervalli relativi possibili".

Mi sorge un dubbio, è possibile cumulare analisi su intervalli di lunghezza diversa per differenze? Me lo autochiedo, forse sì.

[brancomat]

Scusate, alla luce degli ultimi due commenti ri-uploado il solo esempio di lama5, che di fatto corrisponde all'output della query descritta da @dcesari qui: https://github.com/ARPA-SIMC/arkimaps/issues/77#issuecomment-990959485

lama5.tar.gz

Ci sono campi di analisi cumulabili (precipitazioni) e istantanei (mslp), per entrambi l'uscita desiderata è una mappa all'ora + le relative cumulate. Io ho il sospetto che arkimaps già le faccia ma tutte con lo stesso nome perché quando estraggo il tar ho questi log:

$ tar xvf out.tar.gz 
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
tp1h_default/tp1h+000.png
mslp_default/mslp+000.png
tp1h_default/tp1h+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
mslp_default/mslp+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp6h_default/tp6h+000.png
tp12h_default/tp12h+000.png
tp6h_default/tp6h+000.png
tp12h_default/tp12h+000.png
tp12h_default/tp12h+000.png
tp12h_default/tp12h+000.png
tp12h_default/tp12h+000.png
tp12h_default/tp12h+000.png
tp12h_default/tp12h+000.png
tp24h_default/tp24h+000.png
tp24h_default/tp24h+000.png
tp24h_default/tp24h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
tp3h_default/tp3h+000.png
log.json
grib_filter_rules

[spanezz]

Facendo dispatch di lama5.grib. ottengo una lunga fila di:

ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]
ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]
ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]

Vedo che la directory di lavoro è stata comunque riempita, per il momento faccio finta di niente

[spanezz]

Intanto ho sistemato il tar in modo che sia tutto diviso in una directory per reftime. Ora dovresti trovare cose tipo:

$ tar atf issue77.tar 
2021-11-27T09:00:00/mslp_default/mslp+000.png
2021-11-26T08:00:00/mslp_default/mslp+000.png
2021-11-26T22:00:00/mslp_default/mslp+000.png
2021-11-26T15:00:00/mslp_default/mslp+000.png
2021-11-26T14:00:00/mslp_default/mslp+000.png
2021-11-26T16:00:00/mslp_default/mslp+000.png
2021-11-27T06:00:00/mslp_default/mslp+000.png
2021-11-27T13:00:00/mslp_default/mslp+000.png
2021-11-27T10:00:00/mslp_default/mslp+000.png
...

[dcesari]

Facendo dispatch di lama5.grib. ottengo una lunga fila di:

ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]
ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]
ECCODES ERROR   :  Unknown stepType=[13] timeRangeIndicator=[13]

Vedo che la directory di lavoro è stata comunque riempita, per il momento faccio finta di niente

Questo si tampona installando (su fedora/RH dai nostri repo) il pacchetto eccodes-simc che completa le definitions con le nostre estensioni, che in questo caso derivano dalle convenzioni cosmo/DWD. Il file chiave qui è /usr/share/eccodes-simc/definitions/grib1/5.table. ll timeRangeIndicator 13 è quello che permette di identificare le "analisi cumulate".

[spanezz]

Questo si tampona installando (su fedora/RH dai nostri repo) il pacchetto eccodes-simc che completa le definitions con le nostre estensioni, che in questo caso derivano dalle convenzioni cosmo/DWD. Il file chiave qui è /usr/share/eccodes-simc/definitions/grib1/5.table. ll timeRangeIndicator 13 è quello che permette di identificare le "analisi cumulate".

Se possibile preferirei avere dei test case che non richiedano patch alle definition di eccodes. Se non è possibile, allora mi accontento e cerco di vedere come fare detect della presenza delle patch e saltare test di conseguenza