ERROR formatter failed

[lidiabressan]

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]

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

[brancomat]

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

[dcesari]

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]

Actually it seems an unimplemented feature:

arkimet/python/arkimet/formatter/level.py

Line 22 in 75b0fc5

# TODO: index centre, table_version, local_table_version

[spanezz]

A possible quick fix could be to change default_table_version in

arkimet/python/arkimet/formatter/eccodes.py

Line 112 in 75b0fc5

default_table_version = 4

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]

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]

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