Lewis Blake
Lewis Blake
For record keeping: It happens here https://github.com/metno/pyaerocom/blob/8a1a4a16466e82ead958194764e493c0422adef7/pyaerocom/io/readgridded.py#L504 when checking crearted-on-the-fly `mmr*` vars, which need not actually exist. It's coming from a `logger.info()` call https://github.com/metno/pyaerocom/blob/8a1a4a16466e82ead958194764e493c0422adef7/pyaerocom/variable.py#L510
#999 take this output and puts it in logs, so maybe not so much of an issue for now.
Should this be moved to AeroToolsIssues? This is a web-side thing.
Can add a `stats_order_menu` to the `StatisticsSetup` class, but then it needs to be picked up and used on the web. Let us know if we should go forward with...
We deploy from main-dev so closing for now
Would `menu.json` be an okay place for this info?
Sounds reasonable. How about restructuring the contents of the files a little bit then. For example, this is the structure of a file: `ALL-EBAS-d-concNno2-Surface.sjon` ```json { "concNno2": { "EBAS-d": {...
From meeting 20.08.24: We add will one key `"units"`. Should not be repeated if we restructure so that everything is a time series (#1277)
> Remove also warning: > > ``` > Expected `tuple[str, ...]` but got `list` - serialized value may not be as expected > return self.__pydantic_serializer__.to_python( > ``` No, do not...
Yes, we knew the issue was in `model_dump()` based on just the warning. But given that we had neither ruled out user error nor had a bug report it made...