Rendering: t2m media giornaliera

[brancomat]

Uno dei prodotti richiesti è la media giornaliera mobile su 24h della temperatura a due metri dal suolo.

Analogamente a quanto fatto per #17 (la class Decumulate in input.py) ci sarebbe da creare un input di type average che lanci libsim con queste opzioni:

vg6d_transform --comp-stat-proc=254:0 --comp-step='1 00' --comp-frac-valid=0 in.grib out.grib

come già fatto per decumulate a --comp-step andrebbe poi passato il parametro step della ricetta

[spanezz]

Puoi farmi la ricetta, magari usando decumulate o cat invece di average, cosí ho un punto di riferimento da usare per il test?

[brancomat]

creata ricetta bozza con decumulate: t2mavg.yaml

[spanezz]

decumulate al momento usa f"--comp-step=0 {self.step:02d}", mentre nel tuo esempio sarebbe "1 {self.step:02d}".

Il passaggio da 0 a 1 del primo parametro è voluto?

[brancomat]

versione breve: no, è un refuso

versione lunga: il --comp-step è nella forma D hh, quello era un esempio su 24 ore che si può esprimere sia come --comp-step='1 00' che come --comp-step='0 24', quindi va a zero perché si comporti analogamente al decumulate

[spanezz]

Ho aggiunto l'input average, l'ho usato per t2mavg, ho aggiunto un test.

Passo per review

[brancomat]

Apparentemente non riconosce la variabile calcolata come temperatura e non la converte in gradi centigradi, ho guardato il grib calcolato in pantry e mi sembra corretto, non so se c'entri qualche meandro di eccodes perché alla combinazione temperatura + timeRangeIndicator = 3, pare assegnare uno shortName diverso alla variabile: t_2m_cl ("Climat. temperature, 2m Temperature"), provo a indagare

[dcesari]

Molto probabile che sia così.

Aggiungo una nota sul --comp-frac-valid=0, metterlo a 0 è un po' azzardato, l'avevo proposto come soluzione rapida all'inizio, perché potrebbe darti una media valida anche se c'è un solo valore buono nell'intervallo. Ora la formula legata a quell'argomento è un po' complicata nel caso di elaborazioni istantanee->medie (astrologata da @pat1)

      --comp-frac-valid=REAL
              (from  0.  to 1.) specify the fraction of input data that has to
              be valid in order to consider a  statistically  processed  value
              acceptable;  for instantaneous data the criterion is the longest
              time between two contiguous valid data within comp-step interval
              following  this rule: longest=comp-step/(comp-frac-valid*999 +1)
              thus comp-frac-valid == 0 => longest=comp-step,  comp-frac-valid
              == 1 => longest=comp-step/1000) [default=1.00000000]

comunque diciamo che se poniamo ad es. --comp-frac-valid=0.003 ne consegue che la media è valida se i dati distano al max comp-step/4 circa cioè 6 ore nel nostro caso.

[spanezz]

Lo metto configurabile nell'input?

[dcesari]

Mah, non la farei così raffinata, anche perché il legame tra il numero che metti e l'effetto non è così intelligibile, battezzerei un valore ragionevole e lo cablerei nello script.

[brancomat]

Parentesi sullo scaling, aggiusto il tiro: è probabilmente il grib_automatic_scaling di Magics che non funziona in questo contesto, ma la cosa è aggirabile mettendolo a off e specificando l'offset a mano nella ricetta (sulla falsa riga di quello che avviene per mslp o la copertura nuvolosa)

[brancomat]

ho scorporato la questione --comp-frac-valid in issue separata (#112)