Paramaterising with openff issues about biosimspace HOT 13 CLOSED

Okay, I've fixed the first bit, but ParmEd still seems unhappy. I'll try to figure out if the issue is with the OpenMM System, Topoolgy, or the positions from the PDB file.

from biosimspace.

Hi @annamherz. I think the issue is that I have forgotten to avoid going via the intermediate PDB file now that we have a native SDF parser. (I had updated this in the network generation code following another issue that you raised, but apparently not in the OpenFF parameterisation wrapper.) The current approach is a hack (recommended by the OpenFF folks) to attempt to recover stereochemistry. I just need to check the file format associated with the molecule, then write directly to SDF if it was loaded from that format in the first place. I'll check with your example to see if it works.

For reference, you can safely ignore the OpenEye warning. OpenFF can use functionality from the toolkit if it is installed, but can't specify it as a hard dependency since it is proprietary software that needs a license. If it's not installed, it will just use an alternative backend, e.g. RDKit. (OpenFF is interoperable in many places.)

from biosimspace.

For reference, you can safely ignore the OpenEye warning. OpenFF can use functionality from the toolkit if it is installed, but can't specify it as a hard dependency since it is proprietary software that needs a license. If it's not installed, it will just use an alternative backend, e.g. RDKit. (OpenFF is interoperable in many places.)

ah okay that makes sense!

from biosimspace.

Right, I've now fixed it. I was using positions from the PDB file when creating the ParmEd structure. (This was following an old OpenFF tutorial.) I actually want to use the positions from the first conformer of the OpenFF molecule, which might differ to those in the PDB. I'll tidy up a few things then push a fix.

from biosimspace.

thank you so much!

from biosimspace.

The paramaterising is working well now, however I'm still getting one error. After running
lig_p = BSS.Parameters.parameterise(ligand, "openff_unconstrained-2.0.0")
when I try to get the molecule from this:
lig_p.getMolecule()
I get the following error:

 File "/home/anna/BioSimSpace/python/BioSimSpace/Parameters/_process.py", line 227, in getMolecule
   raise _ParameterisationError("Parameterisation failed! Last error: '%s'" % str(self._last_error))
BioSimSpace._Exceptions._exceptions.ParameterisationError: Parameterisation failed! Last error: 'Unable to convert OpenMM System to ParmEd structure!: ImportError('You must have at least OpenMM 6.3 installed')'

This is a bit strange, as I've checked the openmm version of my conda environment, and also when printing it in the python script for this, the version is 7.7 ?

from biosimspace.

Can you try again in a completely clean conda environment? I'm not seeing this locally. I wonder if you have some environment variables set that mean that OpenFF is picking up a different version of OpenMM. Alternatively, it might be failing to extract the version number for some reason.

Could you confirm which OS you are using and how you installed BioSImSpace, i.e. source, or via conda?

from biosimspace.

For what it's worth, I'm very surprised that it could install an OpenMM version less than 6.3. Assuming it pulls in the dependency via conda-forge (which it should, given our instructions and channel priority), then it only goes back to 7.4. Looking at the Omnia version here, 6.2 was released over 7 years ago! This would be completely incompatible with Sire and there is absolutely no way this could be pulled in via any of our current build or installation methods 🤷‍♂️

from biosimspace.

The ParmEd function that is failing is here. This has no check of the OpenMM version number, so it's not clear to me where the check is being performed.

from biosimspace.

I've also grepped the entire BioSimSpace conda environment for "OpenMM 6.3" and don't see anything, so it doesn't look like the exception is anything that would be raised by the standard packages that should be installed. Perhaps you have some outdated versions of certain packages installed elsewhere.

Could you try something like the following in your environment:

import openmm
print(openmm.__file__)
/home/lester/.conda/envs/sire-dev/lib/python3.9/site-packages/openmm/__init__.py

import openff.toolkit
print(openff.toolkit.__file__)
/home/lester/.conda/envs/sire-dev/lib/python3.9/site-packages/openff/toolkit/__init__.py

import parmed
print(parmed.__file__)
/home/lester/.conda/envs/sire-dev/lib/python3.9/site-packages/parmed/__init__.py

That will check the location of the modules that are required for the functionality that is failing.

from biosimspace.

For what it's worth, I'm very surprised that it could install an OpenMM version less than 6.3. Assuming it pulls in the dependency via conda-forge (which it should, given our instructions and channel priority), then it only goes back to 7.4. Looking at the Omnia version here, 6.2 was released over 7 years ago! This would be completely incompatible with Sire and there is absolutely no way this could be pulled in via any of our current build or installation methods man_shrugging

Yes, I'm fairly certain that the openmm version isn't less than 6.3 at all, as I don't think that has ever been installed anywhere on the machine I'm using? I'm running Ubuntu 22. BioSimSpace is installed via source and then used via the PYTHONPATH variable, as I'm changing between the branches, but I was getting this error for both the devel branch and the feature-amber-fep. I'm using Sire from the conda environment. I installed a clean conda environment using this and then updated sire to 2023 using conda install -c conda-forge -c michellab/label/dev sire=2023.0.0 and I still got the same error.

Trying the above:

/home/anna/anaconda3/envs/biosimspace-dev-clean/lib/python3.9/site-packages/openmm/__init__.py
/home/anna/anaconda3/envs/biosimspace-dev-clean/lib/python3.9/site-packages/openff/toolkit/__init__.py
/home/anna/amber22/lib/python3.9/site-packages/parmed/__init__.py

I think the problem is this, so it is taking parmed from the amber22 install. This does check the version.

from biosimspace.

I think the problem is this, so it is taking parmed from the amber22 install. This does check the version.

In the conda install, parmed is version 3.4.3, whilst in the amber install it is only 3.4.1.

This doesn't happen when I start python from the terminal whilst the conda environment is active. In that case, I get:
/home/anna/anaconda3/envs/biosimspace-dev-clean/lib/python3.9/site-packages/parmed/__init__.py
I think it is because in the overall pipeline script I'm running, Amber is sourced for later MD runs for preparing the parameterised ligands so that the correct version of amber is used. If I run the ligand parameterisation script in a fresh terminal without sourcing amber before, the version is 3.4.3 and from the conda install, and it is able to proceed okay. So I guess in this case I just can't source the amber in the overall bash script before. This does make running the MD runs a bit awkward in the sense that I then can't use the default $AMBERHOME variable for the exe path, but I can circumvent that by setting the amber path to a different variable, so I think it should be fine now!

from biosimspace.

Ah, great sleuthing. That's annoying that non-conda ambertools bundles its own version of parmed. It's good that a workaround is easy enough, but it would be good to figure out something else so that it doesn't trip other users up in future. Perhaps we can check the module path for parmed and raise a warning if it lies outside of the active conda environment. Perhaps there's a way to directly import the correct one (assuming we know the path).

from biosimspace.