3-hour ECMWF min and max temperatures not recognized as tmin and tmax

[dcesari]

Sto cercando di calcolare la temperatura massima giornaliera, a partire dai
grib di temperatura massima tri-oraria del centro europeo, ma non ci riesco.

arki_dataset=http://arkimet.metarpa:8090/dataset/ifs_ita010

arki-query --data "reftime:=yesterday 00:00; level:GRIB1,1 ; product: GRIB1,98,228,26 ; timerange: GRIB1,2,0,3h or GRIB1,2,3h,6h or GRIB1,2,6h,9h or GRIB1,2,9h,12h or GRIB1,2,12h,15h or GRIB1,2,15h,18h or GRIB1,2,18h,21h or GRIB1,2,21h,24h or GRIB1,2,24h,27h"  $arki_dataset > tmax.grib

 vg6d_transform --comp-stat-proc=2 --comp-step='1 00' --comp-full-steps tmax.grib tmax.grb
[stderr] WARN     vg6d_transform.volgrid6d_class.input_volume-vol1 - no timeranges of the desired statistical processing type 2 available

[dcesari]

Ho sistemato con l'ultimo commit, ora riconosce max e min su 3 ore ed è in grado di ricalcolarle su un intervallo diverso.

Resta il fatto che in uscita (come avveniva per le max e min esaorarie) il codice variabile diventa tabella 128 parametro 121 o 122, cioè min o max su 6 ore, indipendentemente dalla durata dell'intervallo richiesto, tuttavia nel timerange l'intervallo è quello richiesto. Questo non è molto elegante ma in grib1 non c'è molta scelta, l'alternativa un po' più elegante sarebbe riscrivere il grib usando i parametri generici tmin e tmax della tabella WMO (quindi come Cosmo), sarebbe semplice, ma ci ritroviamo in output un grib che usa una tabella diversa da quella usata in input. Se preferite questa soluzione la applico rapidamente.

[brancomat]

Modifiche integrate nella release 6.4.5-1

Resta il fatto che in uscita (come avveniva per le max e min esaorarie) il codice variabile diventa tabella 128 parametro 121 o 122, cioè min o max su 6 ore, indipendentemente dalla durata dell'intervallo richiesto,

Riportando reazioni (o loro assenza) in analogo thread mail, per ora manteniamo questa situazione, dovessero cambiare le esigenze apriremo altra issue.