conversione variabili ecmwf / cosmo about libsim HOT 2 CLOSED

On 13/01/2016 14:18, Daniele Branchini wrote:

sarebbe utile (forse) avere un qualche modo di convertire le variabili
(tipo da ecmwf a cosmo e viceversa)

questa una lista incompleta di parametri e fattori di conversione:

|98,128,228 * 1000 = 200,2,61 (pioggia)
98,128,144 * 1000 = 200,2,78 + 200,2,79 (neve)
98,128,186 * 100 = 200,2,73 (copertura nubi basse)
98,129,164 * 100 = 200,2,71 (copertura totale nubi)

Queste sono più o meno gestite nell'importazione in gridinfo e nella
conversione grib-bufr-grib, per cui credo che una vg6d_transform che fa
trasformazione vuota su un grib ECMWF e riesporta con un template che
abbia tabella 2 versione 2 e centro != 98 potrebbe uscire rinormalizzato.

98,228,24 + 98,128,129 / 98 = 200,201,84 (zero termico¹)

qui mi è venuto ora in mente che, a parte il tuo programma python, si
potrebbe definire una funzione in alchimia che somma l'orografia.

from libsim.

|98,128,228 * 1000 = 200,2,61 (pioggia)
98,128,186 * 100 = 200,2,73 (copertura nubi basse)
98,128,164 * 100 = 200,2,71 (copertura totale nubi)

Queste ora sono tutte gestite (comprese anche nubi medie e alte, umidità del suolo e altri tipi di prec.), vengono rinormalizzate alla corrispondenti variabili WMO o estensioni locali SIMC se si imposta un template con centro non 98, meglio 200 in uscita alla vg6d_transform

98,128,144 * 1000 = 200,2,78 + 200,2,79 (neve)

Per gestire questa bisogna fare l'operazione di cui sopra ai dati ECMWF mentre per COSMO bisogna fare un giro con alchimia, --output-variable-list=B13205 che fa il calcolo di cui sopra (già implementato)

98,228,24 + 98,128,129 / 98 = 200,201,84 (zero termico)

Date le caratteristiche del nostro fantastico data model e l'inventiva di ECMWF, non si riesce a fare niente di pulito in questo caso. Soprassiedo e chiudo.

from libsim.