We have discussed this issue many times but I will bring this up again as this might also happen other users. (Maybe this also should be posted in the UMEP Discussions forum as we might reach a wider audience there).
We are trying to generate input data for Gothenburg but are getting issues where buiding fractions are not same in land cover fraction and 3D building descriptions in the yml-file. This originates that the values are derived from two different datasets, one building DSM and one land cover grid. This is almost always the case for most users which means that the model will not be able to be executed and used. How can we help users to overcome this issue. I understand that this, from a modelling prespective, needs to be consistent but is problematic that the same type of information comes in twice in the yml-file. How can we improve this?
To take this forward I’d like to pin down the specific problem you’re hitting rather than the general case. Could you spell out exactly what goes wrong in your Gothenburg run, and give us enough to reproduce it:
the exact validation message you get (verbatim),
the offending .yml, or at least the two blocks whose fractions disagree (the land-cover building fraction and the value implied by the 3D building description), plus how far apart they are,
your supy/SUEWS version (python -c "import supy; print(supy.__version__)").
With a concrete case we can reproduce it on our side and then work out the right fix.
Ting, this is not an easy fix for this case only but rather a general discussion on how strict we should be when checking all the parameters using the pydantic model. It is a balance between user-friendliness and being absolutely 100% correct with regards to input data. We are using version from June this year. @JAnka could give you the exact messge and how far the are apart. In some cases I think it was about 3%.
PS. Hundereds of other errors is also popping out regarding references in the yml-file, @Janka will report this soon in a new issue. DS.
Agreed, this is the right level to have it at: a policy question about how strict the validation should be, not a one-off patch for Gothenburg. The balance you describe, between user-friendliness and being correct about the inputs, is exactly the thing to get right, so let me set out how I’d approach it.
I’d separate two things that are currently bundled together:
The building-fraction inconsistency (the ~3% you mention). A 3% gap is well beyond rounding, and the two numbers genuinely describe the same physical quantity, so I don’t want to silently absorb it. But “flag it” and “stop the run with a bare error” are not the same thing. The validation already distinguishes errors from warnings, and the better behaviour here is likely a clear, actionable message (which two values conflict, by how much, and how to bring them into line), or letting the quantity be entered once and deriving the other from it, rather than a hard stop. Which of those is right depends on the actual case.
The “hundreds of reference errors” in your PS. That sounds like a separate problem, and honestly the more important one for usability: if benign issues drown out the one inconsistency that genuinely matters, nobody can tell signal from noise. Worth setting those out here too so we can look at them on their own.
For the concrete part, the most useful next step would be for @Janka to post here the exact validation message for the 3% case and the two fraction values. With a real example I can decide where each check should sit on the error/warning scale. The principle I’m working towards is straightforward: a hard error only when the run would crash or be physically meaningless, and everything that is inconsistent-but-runnable becomes a warning, with any assumption we make written into the report.
Hi,
The error message is:
error!
Unreasonable Difference of 0.031 between PAI calculated from vertical morphology and Building Fraction detected
In this case, PAI is 0.184 and building fraction is 0.153. Any difference above 0.03 gives the error message.
Regarding the other error messages Fredrik mentioned, they are likely related to the new structure of yml files in 2026.5. I’ll submit an issue separately for those.
Thanks @Janka, that pins down the check: an absolute difference above 0.03 between the PAI from the vertical morphology and the land-cover building fraction (here 0.184 vs 0.153).
The numbers tell me why the threshold trips, but to reproduce it and verify a fix I need a self-contained reproduction, not just the two values. Could you share a repro pack:
the complete .yml file that fails (the actual one, not excerpts, so it loads and fails the same way here),
the supy/SUEWS version you are on.
With that I can run it here, decide whether the 0.03 absolute threshold is the right test, and rework the message so it names the two fields and how to reconcile them. The reference errors can go in your separate issue whenever it is ready.