Skip to content

MRB-650 maps simplified#92

Draft
jonasbhend wants to merge 57 commits intomainfrom
MRB-650-Maps-simplified
Draft

MRB-650 maps simplified#92
jonasbhend wants to merge 57 commits intomainfrom
MRB-650-Maps-simplified

Conversation

@jonasbhend
Copy link
Contributor

@jonasbhend jonasbhend commented Jan 7, 2026

Add maps of forecast verification scores

Changes

  • score components for maps in verif.nc
  • Make verif.nc temporary to avoid storage of large data volumes
  • The domains which are originally called "centraleurope" and "switzerland" are mostly the same. I suggest making domain "switzerland" much smaller, so that more spatial detail can be seen, especially in the complex topography of the alps.

@Louis-Frey Louis-Frey force-pushed the MRB-650-Maps-simplified branch from 2185fd6 to 9eb4643 Compare January 22, 2026 12:43
jonasbhend and others added 29 commits January 27, 2026 16:28
summary statistics. (No changes to code yet.)
For Bias, RMSE and MAE map plots.
Francesco. Got a long way towards the png plots.

Co-authored-by: Francesco Zanetta <francesco.zanetta@meteoswiss.ch>
properly working). Output written to .png now
working.
detailed inspection of results at smaller spatial
scale.
@Louis-Frey
Copy link

I came across two different problems with this feature branch:

  1. On the current last commit, I run into memory issues in rule verif_metrics_aggregation . The job seems to be killed by SLURM due to be out of memory (analysis of the log files and consultation with ChatGPT strongly suggest this). This may confirm Francesco's reservations regarding the computation of the spatial metrics.

  2. When I extended the code to also plot the maps for the baselines, I got errors in rule report_experiment_dashboard several times last week. This made me test the code on the last commit today, resulting in the error described in 1.

So overall I can't really make sense of this. On the one hand, I apparently was able to run verif_metrics_aggregation before, because the code only failed later in report_experiment_dashboard. Also, I was able to run the full pipeline on a full year of daily forecasts with the ICON-CH1 emulator about a week ago, which ran without an error.

Also, the problem in 2. suggests that even if problem 1. does not occur, problems may arise later when the verification files are aggregated in the dashboard. This may be due to the large size of the verification files (about 17G for the run and about 11G for the ICON-CH1 baseline). However, also this ran without error in some cases (1 year experiment), so it does not seem to fail consistently.

Would be great if you could look into this!

@Louis-Frey Louis-Frey requested review from dnerini and frazane February 9, 2026 13:41
@frazane
Copy link
Contributor

frazane commented Feb 9, 2026

Make verif.nc temporary to avoid storage of large data volumes

By doing this, verification will have to be re-computed for every run, every time the workflow is executed. I don't think we want this, no?

@Louis-Frey
Copy link

Make verif.nc temporary to avoid storage of large data volumes

By doing this, verification will have to be re-computed for every run, every time the workflow is executed. I don't think we want this, no?

Yes, that could be problematic. Jonas introduced it and I haven't given it much thought, should I change it back?

@Louis-Frey
Copy link

Ok I most likely fixed problem 2. See commit 7b50809

@Louis-Frey
Copy link

And I just tried again an evalml experiment config/forecasters-ich1.yaml, which ran without an error. So issue 1. is not reproducible.

@dnerini dnerini marked this pull request as ready for review February 12, 2026 12:07
# The domains which are originally called "centraleurope" and "switzerland"
# are mostly the same. I suggest making domain "switzerland" much smaller,
# so that more spatial detail can be seen, especially in the complex
# topography of the alps.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a good idea! please move tihs comment to the description of your PR where you summarize the main changes introudced by this PR

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description is the top post in this thread I guess? I put it there too.


# Load, de-duplicate lead_time, and keep best provider per source (same logic as verif_plot_metrics)
dfs = [xr.open_dataset(f) for f in args.verif_files]
drop_variables = ["TOT_PREC.MAE.spatial", "TOT_PREC.RMSE.spatial", "TOT_PREC.BIAS.spatial",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of hardcoding the variables names, why not just opening the first dataset in the verif_files list and extract all variable names including the keyword "spatial"?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll do that.

ds,
forbidden_dims=("values",), # critical!
metric_dims=("source", "season", "init_hour", "region", "lead_time", "eps"),
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the purpose of this change? the spatial fields should have no impact on this part of the code, or am I missing something?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the spatial fields don't matter here, but they caused memory problems in the past when this rule was executed. I therefore implemented this work-around so that the spatial parts of the verification files are not loaded into memory in the first place. Chat-GPT assisted in the creation of this code, so forgive me if something is off.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I see, but I wonder if you need it? I mean, at that point you don't expect any spatial field to be present, since those were all filtered out with drop_variables no?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes I tried that. But using drop_variables alone did not solve the problem, the spatial data were still loaded into memory. So I had to add the rest of this code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then it'd be good to understand why that isn't behaving as expected and use only one single strategy to get rid of the spatial fields

@Louis-Frey Louis-Frey marked this pull request as draft February 12, 2026 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants