Preprocessing della precipitazione: scumulazione e conversione

[edigiacomo]

COSMO ha la precipitazione in mm e cumulata da instante di riferimento (0-1, 0-2, 0-3, 0-72), mentre ECMWF ha la precipitazione in m e cumulata (mi pare) sul periodo (0-6, 6-12, ...). È necessario un preprocessing che calcoli la precipitazione sul periodo in mm.

[dcesari]

Potrebbe aiutare:

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.

Libsim normalizza l'unità di misura solo nella conversione a bufr, nelle trasformazioni griglia-grliglia non dovrebbe fare niente tranne settare correttamente il timerange che nei grib1 ECMWF cumulati è sbagliato.

[brancomat]

Aggiunta (anche relativa a #39), 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]

Nota: questo lascia scoperto il discorso conversione da metri a millimetri per ECMWF

[dcesari]

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 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.

[spanezz]

Sto avendo un po' di problemi a barcamenarmi tra gli output dei modelli possibili per ifs e per cosmo, le trasformazioni che servono per ifs e per cosmo, e gli input possibili postprocessati per le ricette per ifs e per cosmo, con diverse ricette a seconda degli intervalli di (s)cumulazione.

Ci sarebbe qualcuno domani (lunedí) mattina per guidarmi in una qualche videocall a mettere assieme un elenco di comandi che a partire dagli output dei modelli di ifs e di cosmo mi dà tutti i dati di input che servono per tutti i passi di ricette che servono, divisi per passo di ricetta (1h 3h 6h 12h 24h)?

[brancomat]

Proviamoci, ma lo scenario potrebbe essere parzialmente incompleto (ancora non ho aperto tutte le casistiche di ricette).
Però su questi temi anticipo domanda a @dcesari: mi confermi che per ottenere total snow fall di COSMO devo sommare large scale e convettiva (leggi: non c'è una variabile già pronta come nella dissemina IFS?)

[dcesari]

Si, confermo che Cosmo non ha una "total snow" né una "total rain", d'altra parte per le corse ad alta risoluzione (leggi 2.8, 2.2 km) lo schema di convezione precipitante (al momento) è spento, per cui la precipitazione convettiva è sempre zero (probabilmente non viene neanche prodotta) e quindi quella somma è un esercizio inutile. Se poi parliamo di neve, i "temporali di neve" sono una roba abbastanza esotica, per cui non si commetterebbe u grosso errore a trascurare la "convective snow".
Non sarebbe invece trascurabile la "convective rain" se uno volesse plottare la "total rain" (solo liquida, non "total precipitation") del cosmo a 5km, che ha la convezione attiva, ma non so quanto sia di interesse, forse per gli idrologi.
Se serve sono disponibile per una videoconf anche ora o dopo le 15.30.

[spanezz]

Per la scumulazione sembra che ci siamo. Per la somma di convettivo/precipitante/eccetera, apriamo un ticket separato, o se dipende da ricetta a ricetta, ne parliamo nei ticket delle singole ricette?

[brancomat]

Sì mi pare un tema ricetta-dipendente nel senso che anche se il tema dal punto di vista fisico è univoco, come poi viene declinato variabile per variabile e modello per modello ha una certa variabilità.
Chiudo issue.