Derive the BMDB supported-model list from the nightly results

[jcschaff]

The desktop's BMDB tab marks each BioModels Database model supported or not, showing a warning icon and "model not compatible with vCell" for the rest, so a user is not surprised by an import that fails.

bioModelsNetInfo.xml behind it is hand-maintained and was last touched in May 2025, so it had drifted from what VCell can actually open — and drifted further with the SBML import fixes in 8.0.26.01.

The drift

Checked against test_cases.ndjson, which the BMDB nightly executes over the real collection:

	count
flagged incompatible but VCell imports them fine	55
flagged compatible but VCell cannot import them	3

Users were being steered away from 55 usable models. Supported goes from 928 → 983 of 1057.

What this changes

Supported is now derived from the nightly rather than curated by hand, and BioModelsNetInfoTest fails when the two disagree — so the list cannot silently rot again as the importer improves.

mvn test -pl vcell-client -Dtest=BioModelsNetInfoTest -Dvcell.updateBioModelsNetInfo=true

The mapping, and the one judgment call

The nightly records execution — import and simulation — while this list is only about whether a model opens. So the mapping keys on failure type, not pass/fail: a model that imports and then fails in the solver still opens and stays supported. That distinction is what most of the 55 are.

Import-blocking types are listed in IMPORT_BLOCKING_FAILURES. MATH_GENERATION_FAILURE is treated as import-blocking, which is debatable — such a model does load, so it is not strictly an import failure, but it cannot produce math and is unusable, and "not compatible with vCell" is a fair description. It accounts for 2 of the 3 demotions (175, 302); the third, 591, genuinely fails to import with a Lambda-function parse error.

Why not read the ndjson directly at runtime

vcell-cli is not a dependency of vcell-client, and its jar is not in the installer — the client ships only vcell-core, -math, -util, -restclient, -apiclient, -api-types (verified against dependency:copy-dependencies and Dockerfile-clientgen-dev:37-39). Deriving the checked-in XML keeps the desktop reading its own resource and adds no packaging change.

Note for reviewers

The diff is 58 changed lines, not 1061. The generator preserves the file's CRLF line endings deliberately; writing platform separators turned the same 58 attribute edits into a whole-file diff on the first attempt.

vcell-client Fast group: 30 tests, 0 failures.

Also worth knowing separately: this list ships inside the client jar, so it only reaches users on a client release. The runtime fetch from vcell.org/webstart/VCellBMDBInfo/ is commented out at BioModelsNetPanel.java:515-521.

🤖 Generated with Claude Code