Class RigidFragmentProvider


  • public class RigidFragmentProvider
    extends java.lang.Object
    An instance of this class is used by any ConformerGenerator to hand out one or multiple 3D-coordinate sets for rigid fragments within a molecules. RigidFragments are those substructures obtained, when breaking a molecule apart at its non-ring single bonds, which are called 'rotatable bonds'. A RigidFragment consists of core atoms, extended atoms and outer shell atoms. Core atoms are all atoms making up the original substructure. Extended atoms are all atoms of the original molecule, which directly connect to any core atom. Extended atoms are important, because they define the exit vectors of the core atom fragment. Outer shell atoms are another layer of atoms connected the extended atoms. They are needed for the self-organizer to create context depending 3D-coordinates that considers steric and atom type dependent geometries.
    RigidFragments are fragments rather than molecules. There are no implicit hydrogen atoms and some atoms have unoccupied valences. Nitrogen atoms may carry the flat-nitrogen query feature, which is considered by the self organizer when creating 3D-coordinates.
    Important: Stereo centers in the molecule may not be a stereo center in the fragment anymore. Nevertheless, the self-organized coordinates must reflect the correct configuration of the originating molecule. Therefore, atom parities are copied from molecule to fragment and defined valid, which is possible, because parities are based on atom indexes and the atom order is kept in-tact, when assembling the fragment.
    Caching: When generating conformers of many molecules, then many RigidFragments occurr repeatedly. Therefore, caching of fragment's coordinates speeds up conformer generation significantly. However, we need to consider various issues:
    - As key for the cache we use the fragment's idcode (all atoms). To not loose hydrogen atoms, we convert all plain hydrogen atoms into deuterium.
    - In the cache we just store 3D-coordinate sets and their likelyhoods based on self-organizer scores or MMFF-energies
    - When locating the same fragment in a different molecule, then the atom order may be different. Thus, we need to normalize. For this purpose we use the graphIndex of the Canonizer used to create the fragment's idcode and store coordinates in canonical atom order.
    - For molecule stereo centers, which are gone in the fragment, copying of molecule parities to the fragment ensures proper 3D-coordinates. For the Canonizer graphIndex to reflect the original configuration, we need to make sure, that up/down-bonds are copied (parities won't do), which are now overspecifying the non-stereo center. And we use the Canonizer mode TIE_BREAK_FREE_VALENCE_ATOMS to distinguish symmetrical fragment atoms if they have free valences and, thus, could be differently substituted in molecule matches. This way we locate all potential stereo centers in fragments. If a given molecule does not specify a parity for any of the potential stereo centers, then this fragment is not cached. Otherwise a later hit with a defined stereo center at that position might get coordinates for the wrong stereo configuration.
    - If a fragment contains stereo centers, then only one of the two possible enantiomers is cached. The other one is constructed by z-coordinate inversion.
    - If optimizeRigidFragments is true, then the MMFF94s+ forcefield is used to minimize fragments before caching/using them. A different force field may be used by overriding RigidFragmentProvider and all of its forceField... methods and passing an overridden instance to the constructor(s) of the ConformerGenerator to be used.
    • Constructor Detail

      • RigidFragmentProvider

        public RigidFragmentProvider​(long randomSeed,
                                     RigidFragmentCache cache,
                                     boolean optimizeRigidFragments)
    • Method Detail

      • forceFieldInitialize

        public void forceFieldInitialize()
        For using a different forcefield you may override all three forceField... methods.
      • forceFieldAllowsOpenValences

        public boolean forceFieldAllowsOpenValences()
        For using a different forcefield you may override all three forceField... methods.
      • forceFieldMinimize

        public double forceFieldMinimize​(StereoMolecule mol)
        For using a different forcefield you may override all three forceField... methods.