Repository navigation
Conversation
# Conflicts: # src/verification/__init__.py # tests/unit/test_verification.py # workflow/rules/inference.smk
jonasbhend
left a comment
There was a problem hiding this comment.
Hi @lclanzi. Very cool feature indeed.
I suggest we discuss if we want to ditch derived parameter computation in evalml in favor of using post-processors (and ignore sources for which derived parameters are unavailable). What do you think?
My second comment relates to direction of wind. For this, the standard verification metrics do not make sense (e.g. mean absolute error) and should be replaced with error metrics for circular quantities. I suggest to at least include a warning, or maybe ditch DD_10M for now and comment out the relevant sections.
|
Thanks for the feedback @jonasbhend! Yes, the idea is to compute all variables during inference, in order to minimize external operations. For DD_10M:
|
There was a problem hiding this comment.
the uv lock has been remove, was this on purpose?
There was a problem hiding this comment.
The .gitignore in main ignores uv.lock, but the file is still tracked because it was committed before the ignore rule was added. In this branch, I deleted uv.lock and regenerated it, which is why it is no longer present in the repository.
Which approach shall I follow?
Adds wind speed (SP_10M), wind direction (DD_10M) and relative humidity (RELHUM_2M) as verifiable parameters,
SP_10M/DD_10M/RELHUM_2Mnatively from ML-inference GRIB. Derives them fromU_10M/V_10M/T_2M/TD_2Mfor baselines (ICON archive, INCA).RELHUM_2Mnatively from the DWH (ure200h0) instead of deriving it fromT_2M/TD_2MBIAS/MSE/MAE/CORRforDD_10M: a plain difference near due-north (e.g. 355° vs 5°) previously measured a 350° error instead of the true 10°.RELHUM_2Mcolormap default (viridis, 0-100%)