Summary
The DynaPop / EuClueScanner land-use allocation produces substantially different output in GeoDMS 20.1.0 than in 19.0.0, for the same config, input data and reference. Surfaced by regression test t810 (ValLuisa) in ObjectVision/GeoDMS-Test.
Observed
t810 computes LandUse + Population for Czechia 2050 (100m_DynaPop, EuClueScanner) and compares every grid cell against the LUISA reference TIFs (Czechia_P2050.tif / Czechia_P2050_Qi.tif). Cells differing from the reference (of 13,628,216 total):
| version |
LandUse cells != ref |
Population cells != ref |
| 19.0.0 |
5,983 (0.04%) |
205,930 (1.5%) |
| 20.1.0 (msbuild) |
348,587 (2.6%) |
274,970 (2.0%) |
Only the GeoDMS binary differs between the two runs (identical config, source data and reference). 19.0.0 reproduces the LUISA land-use reference almost exactly (~6k cells off); 20.1.0 diverges by 348k cells (~58x more). This is an engine behaviour change, not a model-config change.
(Population differs from the reference in both versions ~1.5-2%, i.e. the model never exactly reproduced the LUISA population - a separate, pre-existing matter, not a 19->20 regression.)
Likely area
The land-use allocation path - discrete allocation (DiscrAlloc) / EuClueScanner. Candidate: an operator behaviour change between 19.0.0 and 20.1.0 affecting the allocation result. (20.1.0 also changed connect counts and pow, so an allocation-related operator change is plausible.)
Reproduce
In ObjectVision/GeoDMS-Test:
cd batch
python full.py -version 19.0.0 -tests t810
python full.py -version 20.1.0.m -tests t810
t810 = results/t810_ValLuisa_Czech_LU_POP in Projects/100m_DynaPop/cfg/StatusQuo.dms; compares Runs/Czechia/TimeSteps/P2050/ResultingState/OutputGeneration/ClippedLandUseVT (and Clipped_Qi) against TestReferenceFiles/t810/Czechia_P2050(.|_Qi.).tif.
Note
The test previously appeared green only via a hollow-OK fallback (missing indicator -> OK); it never actually matched the reference. With the indicator now validated (GeoDMS-Test #12), the regression is visible. Found via overnight regression-suite work in GeoDMS-Test.
Summary
The DynaPop / EuClueScanner land-use allocation produces substantially different output in GeoDMS 20.1.0 than in 19.0.0, for the same config, input data and reference. Surfaced by regression test t810 (ValLuisa) in ObjectVision/GeoDMS-Test.
Observed
t810 computes LandUse + Population for Czechia 2050 (100m_DynaPop, EuClueScanner) and compares every grid cell against the LUISA reference TIFs (
Czechia_P2050.tif/Czechia_P2050_Qi.tif). Cells differing from the reference (of 13,628,216 total):Only the GeoDMS binary differs between the two runs (identical config, source data and reference). 19.0.0 reproduces the LUISA land-use reference almost exactly (~6k cells off); 20.1.0 diverges by 348k cells (~58x more). This is an engine behaviour change, not a model-config change.
(Population differs from the reference in both versions ~1.5-2%, i.e. the model never exactly reproduced the LUISA population - a separate, pre-existing matter, not a 19->20 regression.)
Likely area
The land-use allocation path - discrete allocation (
DiscrAlloc) / EuClueScanner. Candidate: an operator behaviour change between 19.0.0 and 20.1.0 affecting the allocation result. (20.1.0 also changedconnectcounts andpow, so an allocation-related operator change is plausible.)Reproduce
In ObjectVision/GeoDMS-Test:
t810 =
results/t810_ValLuisa_Czech_LU_POPinProjects/100m_DynaPop/cfg/StatusQuo.dms; comparesRuns/Czechia/TimeSteps/P2050/ResultingState/OutputGeneration/ClippedLandUseVT(andClipped_Qi) againstTestReferenceFiles/t810/Czechia_P2050(.|_Qi.).tif.Note
The test previously appeared green only via a hollow-OK fallback (missing indicator -> OK); it never actually matched the reference. With the indicator now validated (GeoDMS-Test #12), the regression is visible. Found via overnight regression-suite work in GeoDMS-Test.