Nothing has been built yet. The accepted engines come from VALID_SOFTWARE (libmdrepo/src/constants.rs:310). That table drives --software (mdr-meta/src/types.rs:85), the name and version check in Meta::check (libmdrepo/src/metadata.rs:208), and generate()'s guard (mdr-meta/src/generate.rs:18). So a new entry plus a versions const enables all three.
Adding it to VALID_SOFTWARE alone breaks every OpenMM submission. The combination check exempts only the literal string "CUSTOM" (metadata.rs:383), but it computes the matched engines from ENGINE_FILE_FORMATS (constants.rs:158). An engine missing from that table can never match its own files, so every submission would fail with "match GROMACS instead" or similar. (This comes from reading the code; nothing has been built to try it.)
Proposal: treat OpenMM like CUSTOM for now. Give it a VALID_SOFTWARE entry and no ENGINE_FILE_FORMATS row, and change the guard at metadata.rs:383 from != "CUSTOM" to ENGINE_FILE_FORMATS.contains_key(...), so the exemption comes from the data. mdr-meta gen already handles a missing row by falling back to the cross-engine union (generate.rs:162). Don't give it a union-of-everything row: OpenMM reads AMBER, CHARMM and GROMACS inputs, and a row matching all of them would break the cross-engine mismatch check. The test meta_combination_matching_no_engine_is_fatal (metadata.rs:2573, gro + psf + dcd) would start passing a combination it is meant to reject. Narrow the exemption once real OpenMM submissions show a convention. Production has none today.
Name it OPENMM, so it sorts with its all-caps peers in the error messages, which list the BTreeMap keys in order.
Blocked on an authoritative list of OpenMM versions to accept. The other version lists are curated and this one shouldn't be guessed.
Other places that hard-code the engine list:
- the test at
libmdrepo/src/metadata.rs:1814;
- readthedocs
docs/src/toml_spec.md:16 and docs/src/mdr_meta.md:154,178;
- elm-mdrepo's
validSoftwareNames in src/Common.elm, now the only copy in the web client.
Django and md_software need no change: mdr-process upserts the software row on import.
Done when: mdr-meta check accepts a TOML declaring OPENMM with a listed version and any file combination, the combination check still rejects gro + psf + dcd for every other engine, and the docs and web list include OpenMM.
Nothing has been built yet. The accepted engines come from
VALID_SOFTWARE(libmdrepo/src/constants.rs:310). That table drives--software(mdr-meta/src/types.rs:85), the name and version check inMeta::check(libmdrepo/src/metadata.rs:208), andgenerate()'s guard (mdr-meta/src/generate.rs:18). So a new entry plus a versions const enables all three.Adding it to
VALID_SOFTWAREalone breaks every OpenMM submission. The combination check exempts only the literal string"CUSTOM"(metadata.rs:383), but it computes the matched engines fromENGINE_FILE_FORMATS(constants.rs:158). An engine missing from that table can never match its own files, so every submission would fail with "match GROMACS instead" or similar. (This comes from reading the code; nothing has been built to try it.)Proposal: treat OpenMM like CUSTOM for now. Give it a
VALID_SOFTWAREentry and noENGINE_FILE_FORMATSrow, and change the guard atmetadata.rs:383from!= "CUSTOM"toENGINE_FILE_FORMATS.contains_key(...), so the exemption comes from the data.mdr-meta genalready handles a missing row by falling back to the cross-engine union (generate.rs:162). Don't give it a union-of-everything row: OpenMM reads AMBER, CHARMM and GROMACS inputs, and a row matching all of them would break the cross-engine mismatch check. The testmeta_combination_matching_no_engine_is_fatal(metadata.rs:2573, gro + psf + dcd) would start passing a combination it is meant to reject. Narrow the exemption once real OpenMM submissions show a convention. Production has none today.Name it
OPENMM, so it sorts with its all-caps peers in the error messages, which list theBTreeMapkeys in order.Blocked on an authoritative list of OpenMM versions to accept. The other version lists are curated and this one shouldn't be guessed.
Other places that hard-code the engine list:
libmdrepo/src/metadata.rs:1814;docs/src/toml_spec.md:16anddocs/src/mdr_meta.md:154,178;validSoftwareNamesinsrc/Common.elm, now the only copy in the web client.Django and
md_softwareneed no change:mdr-processupserts the software row on import.Done when:
mdr-meta checkaccepts a TOML declaringOPENMMwith a listed version and any file combination, the combination check still rejects gro + psf + dcd for every other engine, and the docs and web list include OpenMM.