scan_grib2 can't scan satellite grib2

[brancomat]

scoperto con @pat1 :

$ arki-query --summary-short --yaml '' MSG4_Seviri_1_5_WV_073_20210305_2300.grib
ERROR scanner function failed
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/arkimet/scan/grib.py", line 31, in scan
    if scan(grib, md) is False:
  File "/etc/arkimet/scan/grib2.py", line 21, in scan_grib2
    md["origin"] = {
TypeError: an integer is required (got type NoneType)
SummaryStats:
  Size: 7467561
  Count: 1
  Reftime: 2021-03-05T23:00:00Z to 2021-03-05T23:00:00Z
Items:
  Run:
    MINUTE(23:00)

il problema credo sia che /etc/arkimet/scan/grib2.py non è dipendente dal productDefinitionTemplateNumber (finora abbiamo sempre smistato dati previsti):

    # Origin
    md["origin"] = {
        "style": "GRIB2",
        "centre": grib.get_long("centre"),
        "subcentre": grib.get_long("subCentre"),
        "process_type": grib.get_long("typeOfGeneratingProcess"),
        "background_process_id": grib.get_long("backgroundGeneratingProcessIdentifier"),
        "process_id": grib.get_long("generatingProcessIdentifier"),
    }

il grib2 del satellite (allegato, vedi anche https://github.com/ARPA-SIMC/meteosatlib/issues/2) ha un productDefinitionTemplateNumber = 31 [Satellite product (grib2/tables/4/4.0.table) ] e nella sezione 4 al posto di generatingProcessIdentifier ha observationGeneratingProcessIdentifier

Aggiungo anche @dcesari e @edigiacomo agli assignees perché le ramificazioni dell'impatto sullo scan dei grib2 riguardano un po' tutti.

msg4_grib.tar.gz

[dcesari]

Ho dato un'occhiata ai template 4.*, pare che, al momento non ci siano altre eccezioni, per cui se potessimo fare un fallback, tale che se non è definito generatingProcessIdentifier prendiamo observationGeneratingProcessIdentifier e possiamo ignorare la non definizione di backgroundGeneratingProcessIdentifier dovremmo essere a posto almeno per qualche anno in avanti.

A proposito, l'esigenza di includere anche backgroundGeneratingProcessIdentifier tra i metadati sapete da dove arriva? In Cosmo non è definito e dubito che l'abbiamo mai usato, potremmo essere ancora in tempo a toglierlo.

[dcesari]

Se invece dobbiamo essere proattivi nel prevenire l'errore di decodifica, allora i template 4 che hanno observationGeneratingProcessIdentifier e non gli altri due sono al momento 4.30 (deprecato), 4.31 e 4.35.

[brancomat]

l'esigenza di includere anche backgroundGeneratingProcessIdentifier tra i metadati sapete da dove arriva? In Cosmo non è definito e dubito che l'abbiamo mai usato, potremmo essere ancora in tempo a toglierlo

Non ricordo più come sia stata decisa la sezione origin per i GRIB2. Ho fatto una rapida cernita sui dataset grib2 attualmente operativi al SIMC ed è ignorato in tutti i config. Sul toglierlo, il problema principale che vedo è il seguente: essendo precedente come ordine al generatingProcessIdentifier che è moderatamente usato in svariati filter, l'update di una versione di arkimet priva di backgroundGeneratingProcessIdentifier andrebbe coordinata con una riscrittura di tutti i filter che usano il processo generatore.

Questa cosa per le nostre catene operative si può fare (basta saperlo), il problema è come trasmettere questa informazione a eventuali usi esterni di cui magari non abbiamo quadro completo (si potrebbe usare come campanello d'allarme l'aumento di una major? non so).

Sul tema sono un po' combattuto perché da un lato si può stare conservativi dall'altro ho sempre trovato l'origin dei GRIB2 un po' troppo ricca di campi.

[dcesari]

Se deve creare più danni che vantaggi, lasciamo perdere questa "riforma costituzionale", l'importante è trovare una soluzione per interpretare quei grib.

[spanezz]

backgroundGeneratingProcessIdentifier è nel metadato origin solo perché c'è in GRIB2, e non metterlo significa che se due GRIB2 differiscono solo per quella parte della loro origin, non possono entrare entrambi in un dataset arkimet. Non so però se questo sian un caso d'uso significativo. Quando è stata fatta la scansione, non avevo specifiche sull'uso effettivo di quei campi, e ho dato per scontato che fossero tutti significativi.

Se vogliamo toglierlo posso toglierlo dal metadato (rendendolo opzionale e ignorato se presente, per non dover fare rescan dei dataset esistenti), e non cambiare la sintassi dei matcher, semplicemente ignorando backgroundGeneratingProcessIdentifier e magari dando un warning se qualcuno lo specifica

[spanezz]

Date magari un'occhiata a come viene scansionato e chiudete l'issue se tutto è come ve lo aspettate

[dcesari]

Se abbiamo risolto il caso della possibile non-definizione delle chiavi di cui sopra, a questo punto non toglierei backgroundGeneratingProcessIdentifier, ripensandoci è pur sempre una feature e chissà che non ci ritorni utile il giorno in cui, come si suol dire, nascerà Italia Meteo e faremo largamente uso di assimilazione e del concetto di "background".

[brancomat]

con arkimet 1.34-1 pare a posto:

$ arki-query --summary-short --yaml '' MSG4_Seviri_1_5_WV_073_20210312_2115.grib
SummaryStats:
  Size: 7467561
  Count: 1
  Reftime: 2021-03-12T21:15:00Z to 2021-03-12T21:15:00Z
Items:
  Origin:
    GRIB2(00098, 00000, 000, 255, 254)
  Product:
    GRIB2(00098, 003, 000, 000, 004, 000)
  Level:
    GRIB2S(  -,   -,          -)
  Area:
    GRIB(tn=90)
  Proddef:
    GRIB(tod=0)
  Run:
    MINUTE(21:15)

(o meglio, la parte Level è curiosa ma è eventualmente roba altra issue)