B13211 value always 0 in exported BUFR

[edigiacomo]

The Var object seems ok:

$ python3 <<EOF
import dballe
print(dballe.var("B13211", 12.123).get())
EOF
12

But when I export the message, the value becomes zero:

$ python3 <<EOF | dbamsg dump --interpreted
import sys
import dballe

msg = dballe.Message("generic")
msg.set_named("year", 2020)
msg.set_named("month", 10)
msg.set_named("day", 8)
msg.set_named("hour", 0)
msg.set_named("minute", 0)
msg.set_named("second", 0)
msg.set_named("rep_memo", "test")
msg.set_named("longitude", 12.12345)
msg.set_named("latitude", 43.12345)

msg.set(dballe.Level(1), dballe.Trange(254, 0, 0), dballe.var("B13211", 12.123))

exporter = dballe.Exporter("BUFR")
sys.stdout.buffer.write(exporter.to_binary(msg))
EOF
#0[0] generic message, 43.12345,12.12345, dt: 2020-10-08T00:00:00, 2 contexts:
Level -,-,-,-, tr -,-,-,
001194 Report mnemonic(CCITTIA5): test
004001 YEAR(YEAR): 2020
004002 MONTH(MONTH): 10
004003 DAY(DAY): 8
004004 HOUR(HOUR): 0
004005 MINUTE(MINUTE): 0
004006 SECOND(SECOND): 0
005001 LATITUDE (HIGH ACCURACY)(DEGREE): 43.12345
006001 LONGITUDE (HIGH ACCURACY)(DEGREE): 12.12345
Level 1,-,-,-, tr 254,0,0
013211 Volume of basin(M**3): 0

[dcesari]

Just a thought: looking at dballe.txt, B13211 is coded with 37 bits and 37 > 32, maybe some overflow occurs due to the use of 32 bit int?
B13211 is the only non-character variable with so many bits, since it is local, could we set a scale factor to reduce bits? I remember some thoughts concerning the max. volume of Italian basins (lago di Campotosto?).

[spanezz]

Trovato. In wreport/varinfo.h:

    /**
     * Encode a double value into a positive integer value using Varinfo binary
     * encoding informations (bit_ref and scale)
     *
     * @param fval
     *   Value to encode
     * @returns
     *   The double value encoded as an unsigned integer
     */
    uint32_t encode_binary(double fval) const;

Quindi i valori interi hanno al momento una codifica che deve stare nei 32bit.

Se serve avere interi piú grandi (e se gli altri decoder BUFR lo supportano), apriamo un issue in wreport?

[spanezz]

Intanto ho fatto push del test riprodotto nel branch issue239

[edigiacomo]

Grazie a entrambi! Non so se possiamo usare un fattore di scala, perché come specifiche avevo una precisione di 1m³ (@dcesari vedi email "Volume invaso Ridracoli" del 2017).

[spanezz]

Parlando con Emanuele, vediamo tre possibilità:

• se si parla di dighe, magari basta una precisione ai 10 o 100 m³
• se si parla di invasi che possono essere sia grandi che piccoli, si possono fare due variabili, una per invasi grandi con meno precisione, e una per invasi piccoli con piú precisione
• altrimenti si può salvare come stringa (però poi serve fare special-casing nelle interfacce)

Non ho visto nelle tabelle WMO nessuna variabile numerica con piú di 32bit di ampiezza nella codifica BUFR. Questo mi rende abbastanza pessimista sulla possibilità di usare una variabile del genere mantenendo compatibilità con altri decoder, e non mi è chiaro come poter testare altri decoder su variabili cosí grandi a meno di non andargli a manomettere la loro definizione dei codici B.

[spanezz]

Altra possibilità: non salvare BUFR, e salvare solo JSON

[edigiacomo]

Dopo valutazione interna, si è deciso di correggere la dimensione in bit della variabile e portarla a 32.