gestione analisi #77
Comments
brancomat
changed the title
brancomat
added
enhancement
|
Lasciami indovinare, si tratta del dataset ERG5?! |
|
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). Più genericamente (per @dcesari):
Se la risposta alla 2 è sì, arkimaps potrebbe comportarsi diversamente nella gestione dei dati se gli arriva un pacco dati che abbia |
|
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: |
|
Tornando al grib di partenza, ho capito dove sta il problema di interpretazione di eccodes. Se faccio poi gli intervalli di cumulazione paiono intepretati correttamente da eccodes ( |
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. |
|
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? |
|
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 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 |
|
Dunque, credo che questa issue contenga (almeno) 3 problemi distinti:
Su quest'ultimo tema:
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) |
|
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. |
|
Ok, provo a fare nuova proposta (anche perché la feature di gestire più corse di forecast non sarebbe male): Poi (enhancement) potrebbe avere una flag Per essere perfetto gli mancherebbero due puntini che mi sfuggono:
|
|
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 |
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
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).
Di questa avevo parlato sopra nella issue descrivendo l'euristica in libsim, possiamo tentare di indovinarlo, ma a sto punto se inplementiamo |
|
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 |
|
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? |
|
Per un dataset di analisi propongo una query tipo questa, se hai accesso all'arkimet interno: 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. |
|
Volevo aggiungere una cosa, non so come sia attualmente gestita la cumulazione nelle ricette, ma ad ogni modo in vg6d_transform c'è un parametro |
|
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) |
|
Se parli di cumulate, allego due casistiche:
le ricette coinvolte sono in particolare @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 Riguardo Mi sorge un dubbio, è possibile cumulare analisi su intervalli di lunghezza diversa per differenze? Me lo autochiedo, forse sì. |
|
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: #77 (comment) Ci sono campi di analisi cumulabili (precipitazioni) e istantanei (mslp), per entrambi l'uscita desiderata è una mappa all'ora + le relative cumulate. |
|
Facendo dispatch di lama5.grib. ottengo una lunga fila di: Vedo che la directory di lavoro è stata comunque riempita, per il momento faccio finta di niente |
|
Intanto ho sistemato il tar in modo che sia tutto diviso in una directory per reftime. Ora dovresti trovare cose tipo: |
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 è |
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 |
Le analisi hanno tutte
endStepzero 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
The text was updated successfully, but these errors were encountered: