I am working exactly on the scenario you described.
I have found this thread which is pretty similar to my case and to what you
suggested, so now I am adapting my code accordingly.
What you have published sounds interesting. I also have multiple co-crystal
active sites. Could you please send me the link?
One question: what was more successful in your experience when you had a
crystal ligand and a series of analogues that you wanted to place into the
binding pocket? 1) to superpose the MCS between the scaffold of the query
and the crystal ligand, or the MCS of the whole molecules?
On 20 February 2017 at 21:03, Peter S. Shenkin <shen...@gmail.com> wrote:
> With Glide, IIRC, this facility is designed for the use case where the
> coordinates of a docked ligand are known (typically from an X-ray
> structure) and the docked ligand shares a SMARTS with the ligands in an
> input file. The SMARTS-matching atoms of each incoming ligand are
> superposed upon the corresponding atoms of the docked ligand and the
> resulting pose is used as an initial guess for the docking.
> Some notes:
> 0. Greg questions whether there is really a common core in your example,
> and if there's not, it doesn't appear as if the procedure is directly
> applicable. But if it is applicable, read on.
> 1. If the SMARTS matches in multiple ways, all are tried, and the best
> docking score among them wins (though there may be a way of requesting the
> N best scores, or even all of them). So if the SMARTS specifies a phenyl
> ring, for example, 12 initial poses will be tried. (If it contains two
> phenyl rings, 24 will be tried....)
> 2. GLIDE itself does conformer generation, but I'm not sure how it works
> in this procedure. If the SMARTS specifies a rigid core, you probably don't
> need to pre-generate conformers, but if the core is flexible, you are
> probably best off generating them, which of course you are permitted to do.
> 3. If you have GLIDE, then you probably have LigPrep as well. The
> advantage of using LigPrep for your conformation generation would be that
> the strain energy would be written into the output file, and then, when
> used as the input to Glide, it would be taken into account when computing
> the docking score. And it uses the same (or a very similar) force-field
> that Glide itself uses.
> 4. I may have some details slightly incorrect, so you might want to
> address your question to Schrödinger tech support.
> On Mon, Feb 20, 2017 at 2:15 PM, Brian Kelley <fustiga...@gmail.com>
>> I don't know the exact glide procedure, but I did write such a system for
>> OpenEye (POSIT). The issue you are facing is that the RMSD portion is just
>> a constraint used for docking, it isn't used as the "score", in fact, it
>> can't tell if the conformation interpenetrates the active site or which
>> orientation is better.
>> I believe RDKit can generate conformations with a template, see
>> AllChem.ConstrainedEmbed, this would solve half of your problem in creating
>> conformations that match your template. You still have the problem with
>> scoring against your active site. POSIT scored against the shape tanimoto
>> of the active ligands (if any) to try to fill the same space as the known
>> ligands. See rdkit.Chem.rdShapeHelpers.ShapeTanimotoDist
>> This might not be what you want, but we had good success with similar
>> methods and virtual screening, especially when using multiple co-crystal
>> active sites. I can send you a reference link if this interests you
>> On Mon, Feb 20, 2017 at 12:17 PM, Thomas Evangelidis <teva...@gmail.com>
>>> Greg and Brian,
>>> Thank you for your useful hints. All the compounds that I want to align
>>> are supposed to belong to the same analogue series so they should shave a
>>> common substructure with substantial size.
>>> What I want to emulate is the "core restrained docking" with glide,
>>> where you specify the common core of the query and the reference ligand
>>> using a SMARTS pattern and then glide docks the query compound to the
>>> binding pocket but takes care to overlay the core atoms of the query to the
>>> core atoms of the reference compound. Since RDKit does not do docking,
>>> I just generate 30 conformers of each query compound and select the best
>>> one by measuring the RMSD between the core of the query and the core of
>>> the reference after the alignment. Of course the conformations of the core
>>> atoms between the query and the reference are never identical hence the bad
>>> alignment. Is there any smarter way to emulate the "core restrained
>>> docking" with RDKit?
>>> I will provide you with more info soon (example sdf, results, etc.).
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> Rdkit-discuss mailing list
CEITEC - Central European Institute of Technology
62500 Brno, Czech Republic
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Rdkit-discuss mailing list