Gestione unità di misura degli step

[edigiacomo]

Fino a ora abbiamo sempre generato mappe con step orari (COSMO, ECMWF) ma ICON esprime alcuni timerange in minuti. Al momento, products.json e le directory dei prodotti non indicano l'unità di misura dello step e, avendoli sempre considerati implicitamente in ore, alcuni script/applicazioni (come meteotiles https://github.com/ARPA-SIMC/meteotiles/blob/v0.20/src/models/Product.js#L22-L24) calcolano degli istanti di validità non corretti.

Il problema, nel caso di ICON, mi pare si possa risolvere andando a convertire gli step da minuti a ore perché sono tutti divisibili per 60 e in tal caso si manterrebbe la retrocompatibilità.

Tuttavia, questo significherebbe togliersi la possibilità di gestire step non multipli dell'ora (che comunque al momento non ci sono), e.g. uno step di 30 minuti.

Al tempo stesso, aggiungere l'unità di misura renderebbe meno leggibile, da parte di utente, la scadenza di una specifica mappa (e.g. 4320min per uno step di 72h). Andare invece a "umanizzare" lo step (e.g. 4320min viene scritto come 72h mentre 4350min viene scritto come 72h30min) renderebbe il parsing da parte di script/applicazioni più complesso.

Assegno la issue a un po' di colleghi per discuterne.

[dcesari]

Gestire i minuti come unità di misura nel grib mi pare molto importante, piuttosto che ricodificare (eventualmente anche gestire i giorni, se non ricordo male abbiamo dei dati di previsioni mensili ECMWF con queste unità).

Per ignoranza di come è strutturato il software, non mi è chiarissimo come internamente in produts.json questo potrebbe influire, propongo per il momento di ricalcolare tutto in ore, eventualmente prevedendo dei valori decimali, tipo 3.25. In prospettiva credo che sarebbe meglio separare la gestione dell'asse dei tempi, che potrebbe usare anche un timestamp in secondi, dall'unità di misura con cui i dati sono presentati nelle mappe, che dipende dai gusti dell'utente.

[edigiacomo]

Per ignoranza di come è strutturato il software, non mi è chiarissimo come internamente in produts.json questo potrebbe influire, propongo per il momento di ricalcolare tutto in ore, eventualmente prevedendo dei valori decimali, tipo 3.25

Credo che romperebbe comunque la retrocompatibilità con le applicazioni a valle (che partono dal presupposto che lo step sia un intero) e introdurrebbe una nuova sintassi che potrebbe essere peraltro temporanea. Proporrei di convertire in ore e schiantarsi quando lo step non è multiplo di 1h, almeno fino a che non decidiamo come (e se) gestire timerange complessi (e quali), rompendo solo allora la retrocompatibilità. In questo modo, le catene attuali continuerebbero a funzionare senza modifiche (al momento alcune sono rotte) e dovrebbero essere modificate solo a partire da una certa versione di arkimaps.

In prospettiva credo che sarebbe meglio separare la gestione dell'asse dei tempi, che potrebbe usare anche un timestamp in secondi, dall'unità di misura con cui i dati sono presentati nelle mappe, che dipende dai gusti dell'utente.

Non so se ho capito bene la tua osservazione, ma nel caso di un utente che si genera localmente le sue mappe, si deve necessariamente decidere come indicare il timerange nelle directory/file dell'output (al momento è un suffisso in un pezzo del path nella forma +VALORE_STEP) e in questo caso la leggibilità potrebbe essere un elemento da tenere in considerazione. Inoltre, a partire da come è espresso nell'output di arkimaps, ogni applicazione lo può poi tradurre come crede (e.g. meteotiles visualizza l'istante di validità calcolata da istante di emissione e step).

[dcesari]

Ho capito le annotazioni, non è così semplice, allora va bene per ora di schiantarsi se lo step non è di ore intere, però propongo comunque di gestire i timerange in minuti multipli di 60, mi pare preferibile rispetto a ricodificare i messaggi.

[spanezz]

Internamente (al momento) un istante è rappresentato da un oggetto Instant che contiene reftime (datetime) e step (int). A prescindere dalla rappresentazione di Instant, il codice cerca di ragionare in istanti, anche se ci sono vari punti in cui c'è l'accesso allo step effettivo, come nella generazione dei file dei prodotti, e nelle statistiche dei prodotti prodotti.

L'elenco degli istanti disponibili è generato semplicemente iterando i file presenti nella directory della pantry dopo il dispatch.

Non è un problema cambiare la rappresentazione interna per usare un float, o un datetime.time, invece di un intero per lo step, e può essere un primo passaggio utile per mappare dove al momento viene assunto che lo step sia intero, e metterci una funzione che ne restituisce il valore in ore, e dà un NotImplementedError se lo step non è un numero intero di ore.

Questo potrebbe risolvere il problema di ICON, e metterci sulla strada di supportare step non orari una volta che se ne presentano.

Può andare come idea?

[edigiacomo]

Mi sembra un'ottima idea! In prospettiva, il tipo da usare per step potrebbe dipendere dalla necessità (e qui chiedo a @dcesari) di rappresentare o meno anche istanti non riconducibili all'ora come mese, anno, etc (https://codes.ecmwf.int/grib/format/grib2/ctables/4/4/)?

[spanezz]

Sí. Finché è un problema di rappresentazione in memoria / rappresentazione human readable, abbiamo molto margine di manovra.

Se va a impattare il calcolo degli input derivati, con discorsi tipo di usare dati di un modello che usa un'unità di misura come valori per calcolare input che devono averne un'altra, iniziamo a farci venire un grosso mal di testa. Spero però che questo non sia un caso d'uso reale, e che se abbiamo per esempio un modello climatologico che ragiona a mesi, tutta la sua catena di generazione immagini avrà valori anch'essi espressi in mesi.

[dcesari]

Supportare i periodi di mesi di calendario e loro multipli sarebbe bello, ma probabilmente fuori dai nostri scopi attuali. Va bene la proposta di @spanezz con possibilità di estensione ad unità di misura più brevi in futuro. Credo però che l'unità di misura da usare debba essere specificata dall'utente (diciamo con default = ore) e non dedotta dal contenuto dei messaggi, che potrebbero avere anche unità diverse in uno stesso pacco di dati.

[brancomat]

A titolo informativo, in realtà abbiamo già modelli con step sotto l'ora: adriac (http://arkiope.metarpa:8090/dataset/adriac) che ha step a 20min, per quel che vale anche nel summary di arkimet l'unità di misura viene mostrata in maniera variabile (ma non so se sia una semplificazione interna o dipenda dalla codifica del grib):

  Timerange:
    Timedef(0s, 254, 0s)
    Timedef(20m, 254, 0s)
    Timedef(40m, 254, 0s)
    Timedef(1h, 254, 0s)
    Timedef(80m, 254, 0s)
    Timedef(100m, 254, 0s)
    Timedef(2h, 254, 0s)

Al momento adriac non viene plottato operativamente via arkimaps ma alcune variabili sono già configurate nelle ricette, così al volo non mi pare ci siano variabili cumulate su più step, anzi, per i test dei plot mi sa che filtravo il grib per non avere variabili infrarorarie. Sono d'accordo con Davide che non sarebbe male poter scegliere a monte l'unità di misura minima, cosa che potrebbe ad esempio permettere di forzare modelli come adriac ad avere dei plot orari ed eventualmente tenersi aperta la porta di aumentare la granularità in futuro cambiando opzione.

[spanezz]

Ho preparato la modifica. Un warning è che cambierebbe il formato di products.json, usando stringhe per gli step invece di numeri:

[
 {
  "flavour": {…}
  "recipe": {… },
  "reftimes": {
   "2022-12-15 00:00:00": {
    "inputs": […],
    "steps": {
     # Qui c'erano numeri in chiave, invece di stringhe
     "11h": 1,
     "17h": 1,
     "7h": 1,
     "1h": 1,
     "10h": 1,
     …
    },
    "legend_info": null,
    "render_stats": {…},
    …

È accettabile?

[spanezz]

Ho creato la pull request #155 con l'implementazione. Se non è un problema il cambio del products.json, fate merge tranquillamente, altrimenti parliamone pure

[brancomat]

Pull request mergiata. Vedo però almeno un altro problema che scorporerei in issue separata, diciamo che con questa è stato più o meno risolto il tema: rappresentazione interna ad arkimaps degli step e passaggio al products.json, per ora la chiudo.