On 7/2/25 2:13 AM, Michael Brunsteiner via IMP-users wrote:
> I'm just getting familiar with IMP, looks like a fabulous peace of code!
> Trying the example in https://integrativemodeling.org/2.4.0/doc/tutorial/kinematics_rrt.html
> appears to work as intended, however, there are a few questions:
>
> 1. I get a warning:
> WARNING Could not determine CHARMM atom type for atom "HET: C1 " in residue #475 "NAG"
> so I wonder is there a way to include the sugar topology/parameters in some way - I do seem to recall that the CHARMM FF does have parameters for sugars, at least those found commonly in the PDB.
rrt_sample needs to know connectivity and radii in order to know what to
move and how to score it respectively, and it gets this information from
the CHARMM topology and parameter files. To the best of my knowledge the
tool hasn't been used on sugars so it might not work at all, but if you
want to try it you can certainly add sugar parameters. IMP includes its
own copy of the CHARMM 22 forcefield. To see where the files are on your
system run from a Python terminal:
import IMP.atom
print(IMP.atom.get_data_path('top_heav.lib'))
print(IMP.atom.get_data_path('par.lib'))
> 2. I also get
> WARNING No CHARMM parameters found for angle S-S-CT2
> is this not an interaction that should be there in any CHARMM protein FF?
In a disulfide bridge (CHARMM DISU patch) both sulfurs have the SM atom
type, not S.
> 3. When I include any atom and the corresponding residue into both
> linker.txt and conect_chains.txt then I get:
As I understand it these two options work against each other - hinging
motion occurs around a linker while connect chains makes a rigid link -
so things will get very confused if you try to apply both to the same
part of the system.
> What I wonder is: is the tool smart enough to figure out which CYS are S-S bonded on it's own, and account for that during optimization? If not, is there any other way to use S-S bonded cysteins in the linker?
No, the CHARMM topology is not patched. The algorithm also cannot handle
cycles IIRC so likely it would get stuck if you were to hack the code to
add a DISU patch. I think your only option there would be to treat that
part of the system rigidly.
> 4. I haven't tried out compiling from source yet ... but I'd really like to see whether CUDA gives me any speedup ... is it anywhere documented which parts of the code or which algorithms run on GPU in the current version of IMP?
See https://integrativemodeling.org/2.22.0/doc/manual/gpu.html.
IMP.kinematics does not include any CUDA code though, so you wouldn't
see any speedup there.
Ben
--
https://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle