Optimisation of flexible side chains

[RMeli]

GSoC 2019

Goal

Implement optimisation of flexible side chains using the CNN scoring function.

Tasks:

• Split ligand and receptor movable atoms in the correct channels
• Get combined gradient of the ligand and receptor flexible atoms

Changes

• Automatically freeze receptor (--cnn_freeze_receptor) when minimising with CNN scoring function (--cnn_scoring --minimize)
• Split ligand and receptor atoms in the correct channels
  • CNNScorer::ligand_coords and CNNScorer::ligand_smtypes attributes to store ligand coordinates and smina atom types
  • CNNScorer::receptor_coords and CNNScorer::receptor_smtypes attributes to store receptor coordinates and smina atom types
  • CNNScorer::setReceptor and CNNScorer::setLigand private members to automatically fill CNNScorer::ligand_coords, CNNScorer::ligand_smtypes, CNNScorer::receptor_coords and and CNNScorer::receptor_smtypes from model::atoms, model::coorsd and model::grid_atoms
  • New and unified MolGRidDayaLayer::setReceptor and MolGRidDayaLayer::setLigand API, accepting ligand/receptor coordinates and smina atom types
• Get combined ligand and flexible residues gradient
  • New CNNScorer::setGradient private member correctly extracting ligand (and flexible residues) gradient from MolGridDataLayer.
• Print the list of flexible residues after gnina banner
  • New FlexInfo::printFlex function

[dkoes]

What I'm envisioning is a clean break between molgridlayer and gnina where gnina says to molgrid "these are the receptor atoms", "these are the ligand atoms" and molgrid doesn't need to worry if what's flexible or not - all molgrid needs are the types and coordinates. This means you need to splice together rigid and flexible atoms (and then separate them) but seems like a much cleaner interface to me.

If a class variable is used to assemble/dissassemble the atoms, this should be relatively efficient (no need to allocate/deallocate memory, just copying a few numbers).

[RMeli]

@dkoes, thanks for the code review and the comments.

This means you need to splice together rigid and flexible atoms (and then separate them) but seems like a much cleaner interface to me.

Isn't this similar to what I'm doing (after @Jsunseri code review)?

CNNScorer now has the following new attributes:

• atomv ligand_atoms, receptor_atoms;
• vecv ligand_coords, receptor_coords;
• std::size_t num_flex_atoms;

which explicitly differentiate between ligand and receptor atoms (both flexible and not; flexible ones are just put at the beginning and tracked with CNNScorer::num_flex_atoms) and are passed to MolGridDataLayer.

The functions setLigand and setReceptor are used to to extract rigid and flexible atoms (of both ligand and receptor) from the model (m.get_movable_atoms(), m.get_fixed_atoms()) and populate the new attributes. The same functions are also used to update the flexible atoms coordinates on subsequent calls, but allocation should be performed only once (and the atomv are untouched after the first call).

I think the current implementation is very similar to what you describe (since there are almost no changes to MolGridDataLater apart from a API change where receptor coordinates are passed explicitly) but if my understanding is wrong and you have something different in mind could you provide some more details? Thanks!

[RMeli]

A possible improvement I see at the moment is that CNNScorer::setReceptor and CNNScorer::setLigand are also used to update the coordinates from model->coords to the internal CNNScorer->ligand_coords and CNNScorer->receptor_coords (for subsequent calls of the CNNScorer::score function). Would it be cleaner to pass the model to the CNNScorer constructor, call CNNScorer::setReceptor and CNNScorer::setLigand only once and update the coordinates via a different utility function (private member of CNNScorer)? Or the same CNNScorer needs to be used with different models?

[RMeli]

Updated PR description to reflect latest changes.

[dkoes]

At first glance, isn't obvious to me why you aren't clearing a vector