Rendering: precipitazione totale a 1h, 3h, 6h, 12h e 24h

[brancomat]

sigla: tp associata al periodo tipo tp1h tp3h...

variabili necessarie:
GRIB1,98,128,228 (IFS-ECMWF)
GRIB1,,2,61 (COSMO)

preprocessing:

• riportare preci ECMWF in mm come da Preprocessing della precipitazione: scumulazione e conversione #17
• cumulazione come da Preprocessing della precipitazione: scumulazione e conversione #17

[brancomat]

Contouring
(nota: il contouring è lo stesso di #24 e #37)

base:

"contour": "off",
"contour_highlight": "off",
"contour_hilo": "off",
"contour_label": "off",
"contour_level_selection_type": "level_list",
"contour_shade": "on",
"contour_shade_colour_method": "list",
"contour_shade_method": "area_fill",
"contour_shade_min_level": 0.5,
"legend":"on",

A cui vanno aggiunti, per cumulate 1h e 3h:

	"contour_level_list": [0.5, 1.0 ,2.0, 5.0, 10.0 ,20.0, 30.0, 50.0, 70.0, 100.0, 150.0, 200.0],
        "contour_shade_colour_list": [ "rgb( 0.686,1.000,1.000)", "rgb( 0.000,1.000,1.000)",
            "rgb( 0.447,0.639,1.000)", "rgb( 0.000,0.498,1.000)",
            "rgb( 0.145,0.000,1.000)", "rgb( 0.145,0.435,0.435)",
            "rgb( 1.000,1.000,0.000)", "rgb( 1.000,0.498,0.000)",
            "rgb( 1.000,0.000,0.000)", "rgb(1.000,0.000,1.000)",
            "rgb(0.615,0.403,0.937)" ]

Per cumulate 6/12/24h:

	"contour_level_list": [1.0, 2.0, 5.0, 10.0, 20.0, 30.0, 50.0, 70.0, 100.0, 150.0, 200.0, 300.0, 500.0],
        "contour_shade_colour_list": ["rgb( 0.686,1.000,1.000)", "rgb( 0.000,1.000,1.000)",
            "rgb( 0.447,0.639,1.000)", "rgb( 0.000,0.498,1.000)",
            "rgb( 0.145,0.000,1.000)", "rgb( 0.145,0.435,0.435)",
            "rgb( 1.000,1.000,0.000)", "rgb( 1.000,0.498,0.000)",
            "rgb( 1.000,0.000,0.000)", "rgb(1.000,0.000,1.000)",
            "rgb(0.615,0.403,0.937)", "rgb(0.5,0.,0.5)"]

[spanezz]

Mi sono un po' perso sulla scumulazione: mi potete dare il comando che serve per la conversione?

[brancomat]

Riassumo commenti salienti della #17:

1. per cumulare via libsim il comando è:

vg6d_transform --comp-stat-proc=1 --comp-step='0 12' --comp-full-steps --comp-frac-valid=0 tp.grib tp_12h.grib

variare --comp-step per le varie aggregazioni:

       --comp-step=STRING

              length of regularization or statistical processing step  in  the
              format 'YYYYMMDDDD hh:mm:ss.msc', it can be simplified up to the
              form 'D hh' [default=0000000001 00:00:00.000]

2. per la conversione da m a mm (casistica ECMWF) cito @dcesari:

alternativa 1: via libsim

Ho trovato un modo relativamente elegante di convertire anche l'unità di misura con libsim, a volte fare le cose precise paga, il trucco è specificare in output, come da manpage, un opportuno template grib:

...omissis
       in the form xmin,ymin,xmax,ymax. The output file is  specified  in  the
       form  [output_driver:[output_template:]]pathname, when output_driver is
       grib_api, output_template may specify a file contaning a  grib  message
       to be used as a template for the output file.

La procedura schematica è:

# copio un sample precotto e cambio il centro di emissione in modo che non sia ECMWF (98)
grib_set -s centre=80 /usr/share/eccodes/samples/regular_ll_sfc_grib1.tmpl regular_ll_sfc_it_grib1.tmpl
# lo uso come output template
vg6d_transform --display preci_ifs.grib grib_api:regular_ll_sfc_it_grib1.tmpl:preci_boh.grib

la vg6d_transform di cui sopra la posso usare congiuntamente alla cumulazione.
Il succo è che quando esporto ad un template che non è ECMWF/98, la variabile non viene esportata così com'è perché usa una tabella locale valida solo per il centro 98, per cui viene forzata una conversione avanti e indietro a bufr e poi di nuovo a grib, usando il file vargrib2bufr.csv che contiene anche i fattori per il cambio di unità di misura, quindi mi ritrovo la familiare variabile 61 in kg/m2.

alternativa 2: via eccodes

grib_set -w centre=98,indicatorOfParameter=142/143/144/228 -s scaleValuesBy=1000. prec_in_m.grib prec_in_mm.grib

Però produce dei grib "sbagliati", se per caso vado ad usare i metadati per estrarre ad es. l'unità di misura da scrivere nella legenda.

[spanezz]

Ho provato a estrarre dati da COSMO e da IFS.

Query COSMO: arki-query --summary-short --yaml 'reftime:=2021-01-10; product:GRIB1,,2,61' http://arkimet.metarpa:8090/dataset/cosmo_5M_ita

Query IFS: arki-query --summary-short --yaml 'reftime:=2021-01-10; product:GRIB1,98,128,228' http://arkiope:8090/dataset/ifs_ita010

Ho usato --summary-short perché mi escono dei timerange sia strani che incompatibili tra i due modelli, e vorrei ragionare su come gestirli.

I timerange di IFS sono:

    GRIB1(000, 4294967172h)
    GRIB1(000, 4294967178h)
    GRIB1(000, 4294967184h)
    GRIB1(000, 4294967190h)
    GRIB1(000, 4294967196h)
    GRIB1(000, 4294967202h)
    GRIB1(000, 4294967208h)
    GRIB1(000, 4294967214h)
    GRIB1(000, 4294967220h)
    GRIB1(000, 4294967226h)
    GRIB1(000, 4294967232h)
    GRIB1(000, 4294967238h)
    GRIB1(000, 4294967244h)
    GRIB1(000, 4294967250h)
    GRIB1(000, 4294967256h)
    GRIB1(000, 4294967262h)
    GRIB1(000, 4294967268h)
    GRIB1(000, 4294967274h)
    GRIB1(000, 4294967280h)
    GRIB1(000, 003h)
    GRIB1(000, 006h)
    GRIB1(000, 009h)
    GRIB1(000, 012h)
    GRIB1(000, 015h)
    GRIB1(000, 018h)
    GRIB1(000, 021h)
    GRIB1(000, 024h)
    GRIB1(000, 027h)
…

Sembra ci sia un problema in fase di scansione (dovrebbero esserci dei numeri negativi?), e poi comunque mi aspetterei le precipitazioni di non essere delle medie. COSMO dà invece una istantanea (che non so interpretare) e delle differenze:

    GRIB1(000, 000h)
    GRIB1(004, 000h, 001h)
    GRIB1(004, 000h, 002h)
    GRIB1(004, 000h, 003h)
    GRIB1(004, 000h, 004h)
    GRIB1(004, 000h, 005h)
    GRIB1(004, 000h, 006h)
    GRIB1(004, 000h, 007h)
    GRIB1(004, 000h, 008h)
    GRIB1(004, 000h, 009h)
    GRIB1(004, 000h, 010h)
    GRIB1(004, 000h, 011h)
    GRIB1(004, 000h, 012h)
    …

Guardando questi output ho un po' di domande:

• C'è una scansione da sistemare in fase di acquisizione per IFS?
• Quali di questi mi servono per generare 1h, 3h, 6h, eccetera?
• Come calcolo gli step in output a partire da questi elenchi di timerange in input?

[dcesari]

Dunque per Cosmo la GRIB1(000, 000h) è la precipitazione cumulata all'istante zero che e` codificata come istantanea ed è nulla per definizione, nel processo di ricumulazione con libsim non fa danni e credo venga eliminata nell'output,in definitiva è inutile, ma non dovrebbe essere dannosa se cumuliamo, se per qualche motivo non vogliamo cumulare risulta un intruso, ma non conosco maniere per non farla produrre, se non escluderla con un comando ad hoc.

[spanezz]

GRIB1(000, 000h) non dà problemi e non importa filtrarla via: chiedevo perché non ne capivo il senso e stavo cercando di avere un'idea chiara dei dati in input

[dcesari]

per Cosmo, ricumulando con --comp-full-steps su 12 ore, ottengo questi timerange:

    GRIB1(004, 000h, 012h)
    GRIB1(004, 012h, 024h)
    GRIB1(004, 024h, 036h)
    GRIB1(004, 036h, 048h)
    GRIB1(004, 048h, 060h)
    GRIB1(004, 060h, 072h)

su intervalli più corti l'estensione credo sia ovvia. Parlando in generale, i timerange necessari per una cumulata GRIB1(004,n1h,n2h) sono GRIB1(004,0,n1h) e GRIB1(004,0,n2h).
Per IFS ho meno familiarità, sicuramente i metadati sul timerange sono codificati sbagliati all'origine, devo controllare.

[spanezz]

Se ho capito bene la situazione, una ricetta del tipo "se in input trovi un dato con timerange XXX fai un output ricetta+xxx e calcolata su quell'input, ma preprocessato con questo comando" non è sufficiente.

Se ho capito bene, serve come un'espansione degli input, dove qualcosa va a cercare i GRIB1(004, 000h, XXXh), genera i GRIB1(004, YYYh, ZZZh), e in base a cosa trovo di questi ultimi, decido quali ricetta+ttt.png generare.

Torna?

[brancomat]

Io l'avrei vista in altro modo, ma magari è semplicistico (o complicantistico):
se in input hai certe variabili legate al mondo della precipitazione e specificate dalla ricetta, lanciaci sopra la cumulazione di libsim con i parametri specificati e poi parsi gli output che ti saltano fuori

Edit: questo proprio perché i metadata ECMWF potrebbero avere problemini, e ti togli il problema

[dcesari]

Se ho capito bene la situazione, una ricetta del tipo "se in input trovi un dato con timerange XXX fai un output ricetta+xxx e calcolata su quell'input, ma preprocessato con questo comando" non è sufficiente.

esatto

Il problema è che tipicamente l'utente vuole le cumulate su intervalli di egual durata, però dalla tipica estrazione in cui specifico solo il timerange indicator ma non gli intervalli, non posso sapere se l'utente vuole le cumulate su 1,3 6 o soquante ore.
A suo tempo avevo auspicato un'estensione della sintassi timerange/timedef in cui si specifica "dammi i dati con timerange indicato t scadenze da 0 a n modulo n2" e da questo posso in qualche modo dedurre che voglio le cumulate su n2 ore, eventualmente potremmo prevederla nel frontendi di Mistral. Così com'è adesso per dar un'hint al sistema di cosa voglio davvero, nella query dovrei specificare la lista esplicita di timedef necessari.
Altrimenti se estraggo tutto, ho una marea di possibili cumulate fattibili e potenzialmente sensate.

Spero di aver chiarito.

[spanezz]

Sí. Al momento non stavo pensando di agire in termini di query arkimet. La prima idea che mi era venuta era fare un passo intermedio di preprocessing a livello di tutta la directory di lavoro, in cui far girare script che dati gli input che ci sono, generino input addizionali tipo le scumulate, e poi gli ordini sono calcolati dalle ricette in base agli input piú gli input addizionali

[dcesari]

Per quanto riguarda IFS, l'errore di scanning è strano perché il dataset contiene le scadenze da 0 a 240 a passi inizialmente di 3 e poi di 6h e l'unità di misura è sempre ore. Come dicevo ECMWF ha sempre codificato in grib1 in maniera arbitraria per cui appaiono come istantanee, però il processo di ricumulazione le riconosce e l'output ha i metadati corretti.

[spanezz]

Ok, abbiamo un problema in una nuova versione di arkimet (almeno quella in sviluppo che c'è sul mio portatile), perché la query eseguita su arkiope dà risultati corretti. Riporto il bug in arkimet

[spanezz]

Era arkimet#256

[brancomat]

Purtroppo ho realizzato solo ora una complicazione:
operativamente i passi 1h, 3h, 6h, 12h hanno le mappe corrispondenti ad un output di libsim con --comp-full-steps (ovvero cumulate rispettivamente prodotte ogni 1-3-6-12 ore)
Le cumulate a 24h (e solo quelle) sono calcolate e visualizzate a intervalli triorari: 0-0, 3-3, 6-6 e così via

[dcesari]

Ti prevengo che una scumulazione preliminare su 3h + una cumulazione su 24h senza --comp-full-steps non sortisce l'effetto che potrebbe essere atteso, perché --comp-full-steps agisce solo sulla scumulazione (cumulazione per differenze) e non sulla cumulazione per aggregazione. Per cui se proprio s'ha da fare, l'unica è cumulare su 24h senza l'opzione e poi selezionare gli intervalli voluti.

[spanezz]

Specifico che per come è fatto arkimaps adesso, la scumulazione viene fatta chiamando vg6d_transform per ogni ricetta indipendentemente.

Quindi la ricetta a 24h ha la sua chiamata a vg6d_transform, la ricetta a 1h ha la sua, eccetera.

Non è un problema mettere --comp-full-steps su tutte tranne la 24h. Domanda: visto che viene chiamata per ogni ricetta indipendentemente, --comp-full-steps serve o fa del lavoro in piú?

[dcesari]

Ah, bene, allora se ogni cumulazione ha la sua ricetta si può fare relativamente facilmente. Il --comp-full-steps ci vuole negli altri casi per non avere le cumulate "dispari" tipo 1-4 2-5, etc., per 1h è ridondante, ma in generale non fa danno.

Per le 24h, ripensandoci, forse conviene filtrare a monte!? Tipo estrarre/filtrare solo le scadenze con timedef modulo 3?

[spanezz]

Intanto ho cambiato le ricette mettendo step: 1 invece di comp_step: "0 01", che da un lato è piú semplice e immediato, dall'altro ci permette di avere piú libertà a cambiare l'invocazione a vg6d_transform a seconda dello step.

Ho anche tolto --comp-full-steps. L'invocazione comunque è in arkimapslib/inputs.py sotto Decumulate.preprocess: potete guardare se cosí va bene per tutto o se serva modulare gli switchini?

[brancomat]

Direi tutto bene, mi pare che presenza o assenza di --comp-full-steps non impatti particolarmente a livello prestazionale.

Ho fatto qualche test copiando la ricetta per provare cumulate a vari intervalli: anche senza il --comp-full-steps gli endstep di tutte le cumulate seguono l'intervallo di cumulazione (ogni ora per 1h, ogni 3 per 3h, eccetera) che come si diceva sopra va benissimo per tutte tranne che per quella a 24h.

[spanezz]

In 85ab0f7 ho implementato l'uso di --comp-full-steps per tutti gli step di scumulazione tranne il 24h