MobleyLab
Parmed bug affecting cyclodextrin files
I just want make sure you've noticed this issue ParmEd/ParmEd#898 . Briefly, manipulating the cyclodextrin mol2 files with parmed results in a ring breaking. A work-around would be assigning a single residue number to all cyclodextrin atoms (currently 7 for beta-CD and 6 for alpha-CD).
@davidlmobley, if somebody in your group has run cyclodextrin calculations with YANK using non-OpenEye charges, this bug surely affected the setup.
Thanks. I had not seen the issue and really appreciate the heads-up.
To be clear for the issue tracker -- this is an issue with Yank setups which use the .mol2 files here, but not (necessarily) with the mol2 files themselves?
this is an issue with Yank setups which use the .mol2 files here, but not (necessarily) with the mol2 files themselves?
Correct. To be more specific, this is an issue for any pipeline involving ParmEd manipulating host-bcd.mol2 and host-acd.mol2 (which include YANK's with no OpenEye charges). The other hosts should not be affected by the ParmEd's bug.
Can you tell what triggers this (e.g. what other systems would be affected?)? It sounds like you're saying just receptors which are multi-residue mol2 files?
(Out of curiosity, why are you using ParmEd's mol2 features at all? I've found various bugs there in the past.)
It sounds like you're saying just receptors which are multi-residue mol2 files?
Correct, but only cyclic receptors that are multi-residue mol2 files.
why are you using ParmEd's mol2 features at all?
When the mol2 charges have some precision errors, we use parmed.modeller.residue.fix_charges() to round the net charge to the nearest integer to avoid artifacts.
Correct, but only cyclic receptors that are multi-residue mol2 files.
Sorry, and by "cyclic" here I mean that the first residue is bound to the last residue.