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