Environment solution fails on linux

[j-wags]

For people who just want a workaround

We're aware of an issue where conda environment solution is running out of memory and exiting on computers with ~4GB of RAM or fewer. We are taking some actions to make these solves simpler, and our testing indicates that the updates in the next major conda release (version 27, using the "rattler" solver) will resolve this.

In the meantime, if you're encountering this issue (where environment solves run for a minute or two and then report Killed status), we've found that you can help the solver over the hump by specifying a python version, eg:

mamba create -n myenv -c conda-forge openff-toolkit python=3.13

Full description

Describe the bug

Linux computers with moderate resource levels can't solve environments with openff packages. I've seen this on a user's HPC, on a linux docker container spun up on my own machine (see below), and on a linux machine in GitHub Codespaces.

To Reproduce

I start a linux docker container

docker run --platform linux/amd64 -it mambaorg/micromamba

and inside the docker container

micromamba create -n temp -c conda-forge openff-toolkit

yields

(base) mambauser@14381ae9182f:/tmp$ micromamba create -n temp -c conda-forge openff-toolkit
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                     ✔ Done (2.1 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                     ✔ Done (1.3 sec)

Resolving Environment                                                                     ✔ Done (2.3 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (2.3 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (2.5 sec)

Resolving Environment                                                                           ⧖ StartingKilled

[mattwthompson]

It would be nice to shift some dependencies which don't really need¹ to be in the main package: conda-forge/openff-toolkit-feedstock#77

But I suspect most of the conflicts are due to

• RDKit and PyTorch's compiled dependencies fighting with each other
  • NAGL itself ought to be split out into a "use AshGC" packages separate from the whole shebang of "train a new charge model"
• Many versions and builds of the toolkit existing out there in the world, most with permissive constraints on most dependencies
• A few upper constraints (i.e. Interchange's current Pydantic constraint) causing fights with other newer versions of things

Footnotes

1. Do we need BeautifulSoup4 to load and parametrize molecules? ↩

[j-wags]

My priorities now (in order) are

1. figure out why mamba create -n temp -c conda-forge openff-toolkit fails to resolve the env on linux and fix it
2. get env resolution working in tests again (similar to - but not necessarily identical to - the above)

We should focus on solving item 1 before item 2.

Things we've tried and which I propose we try:

• My merged PR Fix #2182 (CI failing) #2187 partially addresses item 2 by fixing env creation for all but the linux+openeye+rdkit examples builds (by removing nomkl from the test deps).
  • I realize that this addresses item 2 without giving actionable direction on path 1, so in hindsight this may have been a misprioritization
  • Today (the first day after merging) I'm seeing all tests on main report green status, which is confusing because I merged Fix #2182 (CI failing) #2187 with some builds unable to resolve the env. So maybe item 2 is solved?
• Matt's feedstock PR to simplify deps Move examples-only dependencies to examples package conda-forge/openff-toolkit-feedstock#121 is a good shot on goal and I've merged it
• I'm leaning toward making a new bugfix Toolkit release (0.18.1) in case the solver is getting tripped up by having 5 builds of Toolkit 0.18.0 to choose between
• I think removing all the < pins that we can in Toolkit and Interchange may help
• Other ideas?

Things which I propose putting on ice until item 1 is resolved:

• The PR Pixi-fying Toolkit CI (Use Pixi to manage examples #2190) solves item 2 in a very literal sense but it is a big change and puts our CI in a state where it wouldn't catch problems with the more important item 1. So I'd like to try other solutions before moving forward with that.
• The PR removing AmberTools from CI (Do not use AmberTools in examples #2186) was intended to get CI running again (at the high cost of dropping testing of an optional dependency), and has been mostly superseded by Fix #2182 (CI failing) #2187, which gets nearly all CI running again.

[j-wags]

My best plan for how to debug is by breaking down each package into its dependencies and manually testing micromamba create commands to see which ones can be removed/version restrictions relaxed to get envs resolving again. Copy-pasteable lists of deps from most recent versions of our packages, separating openff packages from external, are:

openff-toolkit-base 0.18.0_5

• bson cachetools "networkx >=2.5" numpy packaging "python >=3.11,<3.14a0" python-constraint typing_extensions "xmltodict <1.0.3"
• "openff-amber-ff-ports >=2025.09.0" openff-forcefields openff-units openff-utilities

openff-toolkit 0.18.0_5

• "openmm >=7.6" "rdkit !=2024.03.6"
• "openff-interchange >=0.4,<0.6" "openff-nagl >=0.4"

openff-interchange-base 0.5.3_2

• "numpy <2.5" "pydantic 2.*" "python >=3.12,<3.14.0a0"
• "openff-toolkit-base >=0.16.0,<0.19" "openff-units >=0.2.0,<0.4.0" "openff-utilities >=0.1.5"

openff-interchange 0.5.3_2

• "openmm 8.*" pyedr "python >=3.12,<3.14.0a0"
• openff-packmol "openff-toolkit >=0.17.0,<0.19"

openff-nagl 0.5.5_0

• "python >=3.11"
• "openff-nagl-models >=0.1.0"

openff-nagl-base 0.5.5_0

• click click-option-group "pydantic <3" "python >=3.11" "pytorch >=2.0,<=2.8" pytorch-lightning pyyaml rdkit rich tqdm
• "openff-units openff-toolkit-base >=0.11.0"

openff-nagl-models-2025.9.0_0

• importlib_resources packaging platformdirs "python >=3.11"

openff-forcefields 2026.01.0_0

• "python >=3.11" setuptools

openff-utilities 0.1.16_1

• python >=3.11

openff-units 0.3.2_0

• numpy "pint >=0.24.0,<0.26" "python >=3.11,<3.15.0a0"
• openff-utilities

openff-amber-ff-ports 2025.09.0_0

• "python >=3.11" setuptools

[mattwthompson]

Here's a confusing result (which I do not get on native architecture)

(I'm not concerned that it fails on glibc and CUDA, but where it looks after failing there is odd)

$ CONDA_SUBDIR=linux-64 mamba create -n temp-linux-64 -c conda-forge "openff-toolkit=0.18" "openff-nagl>=0.5.5"
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (1.3 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (1.1 sec)
warning  libmamba Linux version not found, defaulting virtual package version to 0. Try setting CONDA_OVERRIDE_LINUX environment variable to the desired version.
warning  libmamba glibc version not found (virtual package skipped)

Resolving Environment                                                                     ✔ Done (1.3 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (1.5 sec)
Using Cached Shard Index for conda-forge/linux-64                                                   ✔ Done
Using Cached Shard Index for conda-forge/noarch                                                     ✔ Done
Fetching and Parsing Packages' Shards                                                           ⧖ Startingwarning  libmamba Failed to parse field 'noarch' (msgpack type=1) in shard package record for 'tensorboard-2.1.1-py38_0.tar.bz2': Expected STR or BIN type for string conversion. This field will be ignored.
Fetching and Parsing Packages' Shards                                                     ✔ Done (1.5 sec)
warning  libmamba Linux version not found, defaulting virtual package version to 0. Try setting CONDA_OVERRIDE_LINUX environment variable to the desired version.
warning  libmamba glibc version not found (virtual package skipped)

Resolving Environment                                                                   ✔ Done (342.0 sec)
error    libmamba Could not solve for environment specs
    The following packages are incompatible
    ├─ openff-nagl >=0.5.5 * is not installable because it requires
    │  └─ openff-nagl-base [==0.5.2 pyhd8ed1ab_1|==0.5.2 pyhd8ed1ab_2|...|==0.5.5 pyhd8ed1ab_0], which requires
    │     └─ pytorch [>=2.0,<=2.6 *|>=2.0,<=2.8 *] but there are no viable options
    │        ├─ pytorch [2.0.0|2.1.0|...|2.8.0] would require
    │        │  └─ __cuda =* *, which is missing on the system;
    │        └─ pytorch [2.0.0|2.1.0|...|2.8.0] would require
    │           └─ __glibc >=2.17,<3.0.a0 *, which is missing on the system;
    └─ openff-toolkit =0.18 * is not installable because it requires
       └─ openff-nagl >=0.4 * but there are no viable options
          ├─ openff-nagl [0.5.2|0.5.3|0.5.4|0.5.5], which cannot be installed (as previously explained);
          └─ openff-nagl [0.4.0|0.5.0|0.5.1|0.5.2] would require
             └─ dgl >=1.0,<=2.1 * but there are no viable options
                ├─ dgl [1.1.0|1.1.1|...|2.1.0] would require
                │  └─ __glibc >=2.17,<3.0.a0 *, which is missing on the system;
                └─ dgl [1.1.0|1.1.1|...|2.1.0] would require
                   └─ __glibc >=2.17 *, which is missing on the system.
critical libmamba Could not solve for environment specs

This implies to me that

• Having all future builds reach no farther back than the openff-nagl that made DGL optional would be a net positive
• Generally being more aggressive bumping lower constraints would be beneficial (going as far back as PyTorch 2.0 is not useful)

[mattwthompson]

I think we should take a closer look at the dependency chain that ends with CUDA, going through OpenFF NAGL and then PyTorch

• OpenFF NAGL only needs¹ GPU acceleration for training
• CUDA is one of a small number of platform-specific behaviors in this ecosystem
  • In general, if solver think it's on macOS and needs PyTorch, it'll bring down CPU-only builds²
  • Above but on Linux will bring down CUDA-enabled builds
• OpenMM builds on Linux depend on CUDA, no matter if a GPU is detected or not, with some moderately high lower constraints
  • OpenFF NAGL's upper constraint on PyTorch might be causing the solver to fight with OpenMM for valid CUDA versions, but I haven't confirmed this (and our constraint on OpenMM, 8.0.0, is very low)
  • OpenFE and their user base is an example of what we should have in mind here³

I'm having a hard time thinking of a good solution here, at least this early in the morning.

1. Having OpenFF NAGL depend on the pytorch-cpu package would likely cause problems for users who want CUDA-accelerated OpenMM simulations, which is most of our user base
2. Not having it depend on pytorch at all is probably a terrible idea
3. I don't think there's an easy way for packaging to decide if the user wants CUDA or not, and OpenMM already has opinions here

Footnotes

1. I have not timed with and without GPU acceleration, but performance is plenty fast on CPUs so it's at most a "nice to have" ↩

2. I have version 2.8.0, build cpu_generic_py313_h1ee2325_2 in one environment right now ↩

3. Though I'm unaware of special considerations past "the Python code ought to work, and OpenMM ought to use CUDA if I have an NVIDIA GPU" which is already built-in ↩

[j-wags]

Per a recommendation from @dwhswenson, I checked out using rattler to solve conda envs, and it works:

micromamba install -n base -c conda-forge conda-rattler-solver
conda config --set solver rattler # NOTE that this and the next command must explicitly call conda, NOT micromamba
conda create -n temp -c conda-forge openff-toolkit

(env solves in a few seconds, and pulls the latest version of toolkit and interchange)

[mattwthompson]

That's fantastic!

Do we know if there a plan for it coming out of experimental status? Or being available in Mamba?

[mikemhenry]

Looks like it is actually in beta RE: conda/conda-rattler-solver#68 and https://docs.conda.io/projects/conda/en/stable/new-features.html#faster-solves-with-rattler-solver

Should be the default in the conda 27.x release

[j-wags]

Yeah, I'm seeing adding the rattler solver as a 2026 Q2 goal on the conda roadmap project board (and WOW what a project board. But I know that we rarely hit our roadmap goals so I won't hold them to the Q2 timing).

But given that this is already on their roadmap and so far toward deployment, I'm thinking we:

• SHOULD NOT take radical action on our packaging (eg dropping/optionalizing whole deps just for the solver's sake) since rattler will solve this
• SHOULD continue with efforts to remove downpins (xmltodict, pydantic, pytorch, others?)
• SHOULD put out a post acknowledging that solves are sometimes failing and presenting known workarounds.
• SHOULD NOT consider this issue urgent any more

Any objections/thoughts on this plan?