search

ARPA-SIMC / arkimaps

generazione mappe meteorologiche da modelli previsionali
GNU General Public License v2.0
0 stars 1 forks source link

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

Closed brancomat closed 3 years ago

brancomat commented 3 years ago

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

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

preprocessing:

brancomat commented 3 years ago

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 commented 3 years ago

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

brancomat commented 3 years ago

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 commented 3 years ago

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:

dcesari commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Era arkimet#256

brancomat commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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