Summary
Climate BDA is built against Landis.Library.UniversalCohorts-v1, but the
current Core v8 releases of Biomass Succession, Dynamic Fuel System, Dynamic
Fire System and Original Wind are all built against
Landis.Library.UniversalCohorts-v2. Because the two DLLs publish types under
the same namespace but different assembly identities, the Core's site-variable
type check fails at initialization and the run aborts. There is no combination
of current releases in which Climate BDA and Biomass Succession both load.
Error
The data type of site variable "Succession.UniversalCohorts" is
Landis.Library.UniversalCohorts.SiteCohorts, not
Landis.Library.UniversalCohorts.SiteCohorts
The message looks self-contradictory because it prints only the fully-qualified
type name and not the assembly. SiteCohorts from UniversalCohorts-v1.dll and
SiteCohorts from UniversalCohorts-v2.dll are distinct CLR types.
Environment
| Component |
Version |
| LANDIS-II Core |
8.0 (8) |
| Biomass Succession |
7.2 |
| Dynamic Fuel System |
4.1 |
| Dynamic Fire System |
4.1 |
| Original Wind |
4.1 |
| Climate BDA |
5.0 |
| OS |
Windows 10 |
Where it fails
The scenario loads Core, ecoregions, species, Biomass Succession, Dynamic Fuel,
Dynamic Fire and Original Wind successfully. Biomass Succession registers the
site variable:
Registering Data: Succession.UniversalCohorts.
Every other extension initializes without complaint. The run then aborts at the
point Climate BDA resolves that variable — after Original Wind finishes
initializing, before any timestep executes.
Root cause in this repository
At tag v5.1, both the project file and the support-library script still pin v1:
src/BDA-Climate.csproj — <Reference Include="Landis.Library.UniversalCohorts-v1">
src/lib/support_libs_download.ps1 — downloads Landis.Library.UniversalCohorts-v1.dll
The v5.1 release (2026-05-05, asset LANDIS-II-V8.Climate.BDA.5.1-setup.exe)
is titled "Beta release for changes integrating Universal Cohort Library v2",
but as far as I can tell from the two files above the v2 migration has not
actually landed. If I have misread that and v5.1 is expected to work, please say
so and I will retest against it directly.
Why this cannot be worked around by the user
Downgrading is not an option in the other direction either: no Biomass
Succession release targeting Core v8 is built against UniversalCohorts-v1, so
there is no pair of released binaries that satisfies both sides. The fix has to
be a Climate BDA build against v2.
Steps to reproduce
- Install LANDIS-II Core v8 with Biomass Succession 7.2, Dynamic Fuel System
4.1, Dynamic Fire System 4.1, Original Wind 4.1 and Climate BDA 5.0.
- Run any scenario whose
DisturbanceExtensions list includes both
"Biomass Succession" and "Climate BDA".
- The run aborts during initialization with the error above.
Removing the "Climate BDA" line and its input file is sufficient to make the
same scenario run to completion, which isolates the failure to that extension.
Request
Is a Climate BDA build against Landis.Library.UniversalCohorts-v2 planned, and
is there a timeline? Happy to test a build against the reproduction scenario
above if that is useful.
Summary
Climate BDA is built against
Landis.Library.UniversalCohorts-v1, but thecurrent Core v8 releases of Biomass Succession, Dynamic Fuel System, Dynamic
Fire System and Original Wind are all built against
Landis.Library.UniversalCohorts-v2. Because the two DLLs publish types underthe same namespace but different assembly identities, the Core's site-variable
type check fails at initialization and the run aborts. There is no combination
of current releases in which Climate BDA and Biomass Succession both load.
Error
The message looks self-contradictory because it prints only the fully-qualified
type name and not the assembly.
SiteCohortsfromUniversalCohorts-v1.dllandSiteCohortsfromUniversalCohorts-v2.dllare distinct CLR types.Environment
Where it fails
The scenario loads Core, ecoregions, species, Biomass Succession, Dynamic Fuel,
Dynamic Fire and Original Wind successfully. Biomass Succession registers the
site variable:
Every other extension initializes without complaint. The run then aborts at the
point Climate BDA resolves that variable — after Original Wind finishes
initializing, before any timestep executes.
Root cause in this repository
At tag
v5.1, both the project file and the support-library script still pin v1:src/BDA-Climate.csproj—<Reference Include="Landis.Library.UniversalCohorts-v1">src/lib/support_libs_download.ps1— downloadsLandis.Library.UniversalCohorts-v1.dllThe
v5.1release (2026-05-05, assetLANDIS-II-V8.Climate.BDA.5.1-setup.exe)is titled "Beta release for changes integrating Universal Cohort Library v2",
but as far as I can tell from the two files above the v2 migration has not
actually landed. If I have misread that and v5.1 is expected to work, please say
so and I will retest against it directly.
Why this cannot be worked around by the user
Downgrading is not an option in the other direction either: no Biomass
Succession release targeting Core v8 is built against UniversalCohorts-v1, so
there is no pair of released binaries that satisfies both sides. The fix has to
be a Climate BDA build against v2.
Steps to reproduce
4.1, Dynamic Fire System 4.1, Original Wind 4.1 and Climate BDA 5.0.
DisturbanceExtensionslist includes both"Biomass Succession"and"Climate BDA".Removing the
"Climate BDA"line and its input file is sufficient to make thesame scenario run to completion, which isolates the failure to that extension.
Request
Is a Climate BDA build against
Landis.Library.UniversalCohorts-v2planned, andis there a timeline? Happy to test a build against the reproduction scenario
above if that is useful.