ARPA-SIMC / arkimet

A set of tools to organize, archive and distribute data files.
Other
15 stars 5 forks source link

ERROR formatter failed #321

Closed lidiabressan closed 2 months ago

lidiabressan commented 10 months ago

ciao !

i got an error in this file (grib2) for level (here the 1st message): pres.tar.gz

arki-scan --dump --annotate grib:pres.grb

ERROR formatter failed Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/arkimet/formatter/formatter.py", line 39, in format res = formatter(t) File "/usr/lib/python3.6/site-packages/arkimet/formatter/level.py", line 48, in format_level return format_single_level(type1, scale1, value1) + " " + format_single_level(type2, scale2, value2) TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

pres.tar.gz

dcesari commented 10 months ago

It is probably a duplicate of #317, can we close that issue merging in a new release?

brancomat commented 10 months ago

arkimet v1.48-1 has been installed on internal server "rocky8" please test if this version gives the same error

dcesari commented 10 months ago

My speculation was wrong, the error remains also using the new version, after some debugging, I have the feeling that the formatter opens an old level table /usr/share/eccodes/definitions/grib2/tables/4/4.5.table instead of /usr/share/eccodes/definitions/grib2/tables/15/4.5.table which should be the right table according to the tablesVersion = 15 key.

dcesari commented 10 months ago

Actually it seems an unimplemented feature: https://github.com/ARPA-SIMC/arkimet/blob/75b0fc58d0714ec141c3655f8ab8fd764028e718/python/arkimet/formatter/level.py#L22

spanezz commented 10 months ago

A possible quick fix could be to change default_table_version in https://github.com/ARPA-SIMC/arkimet/blob/75b0fc58d0714ec141c3655f8ab8fd764028e718/python/arkimet/formatter/eccodes.py#L112 to something newer (15?)

A proper fix requires to add a way to give format_level access to centre, table_version, local_table_version, which are currently not stored in the level metadata.

The problem is that those values might not always be available when trying to format a level: for example, trying to format a summary that contains only Level information, without origin and the like.

However, for a proper fix the problem is wider: if the level does require those other information to be interpreted, it may be insufficiently defined. Would a level with a given value with table version 4 mean something else with table version 15? If so, we might have to add the table version to the level information, like we have with products.

If however it's just a case of levels being added without being redefined, the quick fix of updating default_table_version might end up being the proper fix for just adding support for the new levels

dcesari commented 5 months ago

I propose a pull request. As far as I know, the new table versions add or deprecate entries, but they should not change the content of existing entries except for cosmetic corrections.

brancomat commented 4 months ago

The pull request has been merged in arkimet v1.50-1 (already available in copr repos)

spanezz commented 2 months ago

With 1.51 I get:

$ arki-scan --dump --annotate grib:pres1.grb
Source: BLOB(grib,/home/enrico/lavori/arpa/arkimet/pres1.grb:0+271076)
Origin: GRIB2(00080, 00255, 002, 000, 002)  # GRIB2 from 80, subcentre 255, type Forecast, background process 0, process 2
Product: GRIB2(00080, 000, 003, 000, 015, 001)  # Pressure (Pa)
Level: GRIB2D(150, 000, 0000000014, 150, 000, 0000000015)   # 150 Generalized vertical height coordinate 0 14 150 Generalized vertical height coordinate 0 15
Timerange: Timedef(0s, 254, 0s) # Analysis or observation, istantaneous value
Reftime: 2023-10-11T00:00:00Z   # 2023-10-11T00:00:00Z
Area: GRIB(Ni=326, Nj=391, latfirst=33500000, latlast=49100000, lonfirst=2700000, lonlast=22200000, tn=0)   # GRIB(Ni=326, Nj=391, latfirst=33500000, latlast=49100000, lonfirst=2700000, lonlast=22200000, tn=0)
Proddef: GRIB(tod=1)    # GRIB(tod=1)
Run: MINUTE(00:00)  # MINUTE(00:00)
Note: [2024-07-17T07:42:40Z]Scanned from pres1.grb:0+271076

I assume this means that this has been fixed