openfe
openfe copied to clipboard
Issue using espaloma for small molecule forcefield
Hello! I would like to use the espaloma forcefield for my small molecule, but I get the following error when I set the protocol settings.forcefield_settings.small_molecule_forcefield = 'espaloma-0.3.2'
Error: The protocol unit 'IPC to IPG repeat 1 generation 0' failed with the error message: ValueError: No registered small molecule template generators could load force field 'espaloma-0.3.2' Available installed force fields are: GAFFTemplateGenerator: ['gaff-1.4', 'gaff-1.8', 'gaff-1.81', 'gaff-2.1', 'gaff-2.11'] SMIRNOFFTemplateGenerator: ['smirnoff99Frosst-1.0.1', 'smirnoff99Frosst-1.0.8', 'smirnoff99Frosst-1.0.5', 'smirnoff99Frosst-1.0.2', 'smirnoff99Frosst-1.0.3', 'smirnoff99Frosst-1.0.6', 'smirnoff99Frosst-1.0.7', 'smirnoff99Frosst-1.0.9', 'smirnoff99Frosst-1.1.0', 'smirnoff99Frosst-1.0.4', 'smirnoff99Frosst-1.0.0', 'tip5p-1.0.0', 'openff-1.2.1', 'opc3', 'tip4p_ew', 'openff-1.1.0', 'tip5p', 'openff-1.3.1', 'tip3p_fb-1.1.1', 'opc-1.0.1', 'openff-2.2.0', 'opc', 'tip4p_fb-1.0.0', 'opc3-1.0.1', 'spce', 'openff-1.0.1', 'tip4p_fb-1.0.1', 'openff-2.0.0', 'openff-1.2.0', 'openff-2.2.1-rc1', 'openff-1.3.1-alpha.1', 'spce-1.0.0', 'opc-1.0.0', 'openff-2.1.1', 'tip3p_fb-1.1.0', 'openff-2.2.1', 'opc3-1.0.0', 'openff-1.0.0-RC2', 'openff-1.0.0', 'tip3p-1.0.0', 'tip3p-1.0.1', 'opc-1.0.2', 'openff-1.3.0', 'openff-2.2.0-rc1', 'openff-2.1.0', 'tip3p_fb-1.0.0', 'openff-2.0.0-rc.1', 'tip4p_fb', 'openff-2.1.0-rc.1', 'openff-1.1.1', 'tip4p_ew-1.0.0', 'openff-1.0.0-RC1', 'tip3p', 'openff-2.0.0-rc.2', 'tip3p_fb', 'ff14sb_off_impropers_0.0.3', 'ff14sb_off_impropers_0.0.2', 'ff14sb_off_impropers_0.0.4', 'ff14sb_off_impropers_0.0.1'] EspalomaTemplateGenerator: ['espaloma-0.3.2']
In my conda env, I have the packages:
espaloma 0.3.2 pyhd8ed1ab_0 conda-forge
espaloma_charge 0.0.8 pyhd8ed1ab_0 conda-forge
What am I missing?
Thank you for opening up this issue! I will get it triaged in the next day or so, we do support and test espaloma so this should work. My guess is that some other error is happening that we don't handle correctly which is why this error is confusing.
@chabi-fin In the env where you have espaloma and espaloma_charge do you get any errors with openfe test
Yes, I remember hitting this error and, if I recall correctly, it was about the environment not solving to the correct openmmforcefields version. Can you share the full package list of your environment? (That is, the output of conda list, or mamba list)
I attach my conda env.
I also tried creating a new environment with mamba create -n fep_env openfe espaloma, but the error persists.
@mikemhenry running openfe test yields 7 failed, 788 passed, 63 skipped, 1 xfailed, 2 xpassed, 1644 warnings in 445.06s (0:07:25) and I notice test_espaloma_import_error PASSED
Any idea how to fix the openmmforcefields/openfe/espaloma compatability?
@chabi-fin It looks like all the espaloma tests passed (and were not skipped) so that is good. Can you post the script you are using that is giving you this error (and the inputs if you can)? The version of openfe you are using is rather old, can you make a new env with:
mamba create -n fep_env "openfe=1.3.1" "espaloma=0.3.2"
@mikemhenry when you say "espaloma tests" do you mean "espaloma-charge tests"?
As far as I can remember, I don't think we ever added espaloma FF tests anywhere in openfe.
Relevant openmmtools issue for numpy 2.0: https://github.com/choderalab/openmmtools/issues/772
Edit: wrong issue sorry 🤦🏽
@mikemhenry I have tried to make an environment with the newer version of openfe, but this environment cannot be solved. I get a conflict related to qcportals ` Looking for: ['openfe=1.3.1', 'espaloma=0.3.2']
Could not solve for environment specs The following packages are incompatible ├─ espaloma 0.3.2** is installable and it requires │ └─ qcportal >=0.15.0,<0.50.0a0 , which can be installed; └─ openfe 1.3.1** is not installable because it requires └─ openff-toolkit >=0.16,<0.17 , which requires └─ openff-toolkit-base [0.16.0 pyhd8ed1ab_0|0.16.0 pyhd8ed1ab_1|...|0.16.8 pyhd8ed1ab_3], which requires └─ qcportal >=0.50.0 , which conflicts with any installable versions previously reported. `
My script is just a single command within a slurm script:
openfe quickrun transformations/IPC_IPG_TEST.json -o IPC_IPG_TEST/results.json -d IPC_IPG_TEST
with the input (here as .txt):
IPC_IPG_TEST.json.txt
@chabi-fin I just released a new espaloma build on conda-forge which expands the dgl versions that are compatible which should fix these dependency issues, can you check if it now works for you?
Thanks! Mike
I tried again to create a fresh environment with echo "Y\n" | mamba create -n fep_esp -c conda-forge openfe espaloma espaloma_charge, but the resulting environment is still with the old openfe version
openfe 1.0.1
espaloma 0.3.2
If I try and force the version openfe=1.3.1, then
The following packages are incompatible
├─ espaloma is installable with the potential options
│ ├─ espaloma 0.3.2 would require
│ │ └─ qcportal >=0.15.0,<0.50.0a0 with the potential options
│ │ ├─ qcportal [0.15.6|0.15.7|0.15.8], which can be installed;
│ │ └─ qcportal 0.15.8 would require
│ │ └─ pandas <1.5 with the potential options
│ │ ├─ pandas [0.17.0|0.17.1|...|0.24.2] would require
│ │ │ └─ python [2.7* |>=2.7,<2.8.0a0 ], which can be installed;
│ │ ├─ pandas [0.17.0|0.17.1|...|0.20.3] would require
│ │ │ └─ python 3.4* , which can be installed;
│ │ ├─ pandas [0.17.0|0.17.1|...|0.23.4] would require
│ │ │ └─ python [3.5* |>=3.5,<3.6.0a0 ], which can be installed;
│ │ ├─ pandas [0.19.2|0.20.0|...|0.22.0] would require
│ │ │ └─ python 3.6* , which can be installed;
│ │ ├─ pandas [0.22.0|0.23.0|...|1.1.5] would require
│ │ │ └─ python >=3.6,<3.7.0a0 , which can be installed;
│ │ ├─ pandas [0.23.4|0.24.0|...|1.3.5] would require
│ │ │ └─ python >=3.7,<3.8.0a0 , which can be installed;
│ │ ├─ pandas [0.24.2|0.25.3|...|1.4.4] would require
│ │ │ └─ python >=3.8,<3.9.0a0 , which can be installed;
│ │ ├─ pandas [1.1.3|1.1.4|...|1.4.4] would require
│ │ │ └─ python >=3.9,<3.10.0a0 , which can be installed;
│ │ └─ pandas [1.3.4|1.3.5|...|1.4.4] would require
│ │ └─ python >=3.10,<3.11.0a0 , which can be installed;
│ ├─ espaloma [0.2.2|0.2.3|0.2.4|0.3.1] conflicts with any installable versions previously reported;
│ └─ espaloma 0.3.2 would require
│ └─ dgl 1.1.2.* with the potential options
│ ├─ dgl 1.1.2 would require
│ │ └─ python >=3.10,<3.11.0a0 , which can be installed;
│ ├─ dgl 1.1.2 would require
│ │ └─ python >=3.11,<3.12.0a0 , which can be installed;
│ └─ dgl 1.1.2 would require
│ └─ python >=3.9,<3.10.0a0 , which can be installed;
└─ openfe 1.3.1** is not installable because it requires
└─ openff-toolkit >=0.16,<0.17 , which requires
└─ openff-toolkit-base [0.16.0 pyhd8ed1ab_0|0.16.0 pyhd8ed1ab_1|...|0.16.9 pyhd8ed1ab_0], which requires
└─ qcportal >=0.50.0 , which conflicts with any installable versions previously reported.
while if I try and use openfe=1.4,
The following packages are incompatible
├─ click is installable with the potential options
│ ├─ click [6.6|6.7] would require
│ │ └─ python 2.7* , which can be installed;
│ ├─ click 6.6 would require
│ │ └─ python 3.4* , which can be installed;
│ ├─ click [6.6|6.7] would require
│ │ └─ python 3.5* , which can be installed;
│ ├─ click [6.6|6.7] would require
│ │ └─ python 3.6* , which can be installed;
│ ├─ click [8.0.0|8.0.1] would require
│ │ └─ python >=3.6,<3.7.0a0 , which can be installed;
│ ├─ click [8.0.0|8.0.1|...|8.1.3] would require
│ │ └─ python >=3.7,<3.8.0a0 , which can be installed;
│ ├─ click [8.0.0|8.0.1|...|8.1.3] would require
│ │ └─ python >=3.8,<3.9.0a0 , which can be installed;
│ ├─ click [8.0.0|8.0.1|...|8.1.3] would require
│ │ └─ python >=3.9,<3.10.0a0 , which can be installed;
│ ├─ click [8.0.3|8.0.4|...|8.1.3] would require
│ │ └─ python >=3.10,<3.11.0a0 , which can be installed;
│ ├─ click 8.1.3 would require
│ │ └─ python >=3.11,<3.12.0a0 , which can be installed;
│ ├─ click [5.1|6.7|...|8.1.8], which can be installed;
│ ├─ click [8.1.3|8.1.4|...|8.2.1] would require
│ │ └─ __win, which is missing on the system;
│ └─ click [8.2.0|8.2.1] conflicts with any installable versions previously reported;
└─ openfe 1.4** is installable and it requires
└─ click <8.2 with the potential options
├─ click [6.6|6.7], which can be installed (as previously explained);
├─ click 6.6, which can be installed (as previously explained);
├─ click [6.6|6.7], which can be installed (as previously explained);
├─ click [6.6|6.7], which can be installed (as previously explained);
├─ click [8.0.0|8.0.1], which can be installed (as previously explained);
├─ click [8.0.0|8.0.1|...|8.1.3], which can be installed (as previously explained);
├─ click [8.0.0|8.0.1|...|8.1.3], which can be installed (as previously explained);
├─ click [8.0.0|8.0.1|...|8.1.3], which can be installed (as previously explained);
├─ click [8.0.3|8.0.4|...|8.1.3], which can be installed (as previously explained);
├─ click 8.1.3, which can be installed (as previously explained);
├─ click [5.1|6.7|...|8.1.8], which can be installed;
└─ click [8.1.3|8.1.4|...|8.2.1], which cannot be installed (as previously explained).
What OS are you using? Can you use echo "Y\n" | mamba create -n fep_esp -c conda-forge openfe espaloma espaloma_charge python=3.10 and see what happens?
Using echo "Y\n" | mamba create -n fep_esp -c conda-forge openfe espaloma espaloma_charge python=3.10 still results in the old version of openfe.
openfe 1.0.1
espaloma 0.3.2
I'm working on a linux based HPC system.
Can you try specifying the latest versions? This will tell us were the conflicts come from:
echo "Y\n" | mamba create -n fep_esp -c conda-forge "openfe=1.4.0" "espaloma=0.3.2" "espaloma_charge=0.0.8" "python=3.10" And if you don't need python 3.10:
echo "Y\n" | mamba create -n fep_esp -c conda-forge "openfe=1.4.0" "espaloma=0.3.2" "espaloma_charge=0.0.8"
This should be fixed with espaloma 0.4.0
Please feel free to re-open the issue if it doesn't fix your problem :)