src/gromacs/mdrun/mdmodules.h

   1 /*
   2  * This file is part of the GROMACS molecular simulation package.
   3  *
   4  * Copyright (c) 2016,2017,2018,2019, by the GROMACS development team, led by
   5  * Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
   6  * and including many others, as listed in the AUTHORS file in the
   7  * top-level source directory and at http://www.gromacs.org.
   8  *
   9  * GROMACS is free software; you can redistribute it and/or
  10  * modify it under the terms of the GNU Lesser General Public License
  11  * as published by the Free Software Foundation; either version 2.1
  12  * of the License, or (at your option) any later version.
  13  *
  14  * GROMACS is distributed in the hope that it will be useful,
  15  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  16  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  17  * Lesser General Public License for more details.
  18  *
  19  * You should have received a copy of the GNU Lesser General Public
  20  * License along with GROMACS; if not, see
  21  * http://www.gnu.org/licenses, or write to the Free Software Foundation,
  22  * Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA.
  23  *
  24  * If you want to redistribute modifications to GROMACS, please
  25  * consider that scientific software is very special. Version
  26  * control is crucial - bugs must be traceable. We will be happy to
  27  * consider code for inclusion in the official distribution, but
  28  * derived work must not be called official GROMACS. Details are found
  29  * in the README & COPYING files - if they are missing, get the
  30  * official version at http://www.gromacs.org.
  31  *
  32  * To help us fund GROMACS development, we humbly ask that you cite
  33  * the research papers on the package. Check out http://www.gromacs.org.
  34  */
  35 /*! \libinternal \file
  36  * \brief
  37  * Declares gmx::MDModules.
  38  *
  39  * \author Teemu Murtola <teemu.murtola@gmail.com>
  40  * \inlibraryapi
  41  * \ingroup module_mdrun
  42  */
  43 #ifndef GMX_MDRUN_MDMODULES_H
  44 #define GMX_MDRUN_MDMODULES_H
  45
  46 #include "gromacs/mdrun/mdmodulenotification.h"
  47 #include "gromacs/utility/classhelpers.h"
  48
  49 struct ForceProviders;
  50
  51 struct t_inputrec;
  52
  53 namespace gmx
  54 {
  55
  56 class KeyValueTreeObjectBuilder;
  57 class KeyValueTreeObject;
  58 class IKeyValueTreeErrorHandler;
  59 class IKeyValueTreeTransformRules;
  60 class IMDOutputProvider;
  61 class KeyValueTreeObject;
  62 class KeyValueTreeBuilder;
  63 class IMDModule;
  64 class LocalAtomSetManager;
  65 class IndexGroupsAndNames;
  66
  67 /*! \libinternal \brief
  68  * \brief Signals that the communication record is set up and provides this record.
  69  */
  70 struct CommunicationIsSetup
  71 {
  72     //! The communication record that is set up.
  73     const t_commrec &communicationRecord_;
  74 };
  75
  76
  77 /*! \libinternal \brief
  78  * Manages the collection of all modules used for mdrun.
  79  *
  80  * This class acts as a central place for constructing modules for mdrun
  81  * and wiring up dependencies between them.  This class should be the only
  82  * place that contains the full list of modules, although in the future, some
  83  * code (e.g., in tools) may benefit from the ability to only create one or a
  84  * few modules and use them.
  85  *
  86  * The general idea is that each module takes care of its own data rather than
  87  * mdrun having to know about all the details of each type of force calculation.
  88  * Initially this is applied for simple things like electric field calculations
  89  * but later more complex forces will be supported too.
  90  *
  91  * Currently, where the set of modules needs to be accessed, either a pointer
  92  * to MDModules is passed around, or an instance of IMDOutputProvider or
  93  * ForceProviders returned from MDModules.  These objects returned from
  94  * MDModules call the corresponding methods in the relevant modules.
  95  * In the future, some additional logic may need to be introduced at
  96  * the call sites that can also influence the signature of the methods,
  97  * similar to what ForceProviders already does for force computation.
  98  *
  99  * The assignOptionsToModules() and adjustInputrecBasedOnModules() methods of
 100  * this class also take responsibility for wiring up the options (and their
 101  * defaults) for each module.
 102  *
 103  * \inlibraryapi
 104  * \ingroup module_mdrunutility
 105  */
 106 class MDModules
 107 {
 108     public:
 109         MDModules();
 110         ~MDModules();
 111
 112         //! Register callback function types for MDModules
 113         using notifier_type = registerMdModuleNotification<
 114                     CommunicationIsSetup,
 115                     IndexGroupsAndNames,
 116                     KeyValueTreeBuilder*,
 117                     const KeyValueTreeObject &,
 118                     LocalAtomSetManager *
 119                     >::type;
 120
 121         /*! \brief
 122          * Initializes a transform from mdp values to sectioned options.
 123          *
 124          * \see IMdpOptionProvider::initMdpTransform()
 125          *
 126          * Initializes the combined transform from all modules.
 127          */
 128         void initMdpTransform(IKeyValueTreeTransformRules *rules);
 129
 130         /*! \brief Initializes a builder of flat mdp-style key-value pairs
 131          * suitable for output.
 132          *
 133          * If used as input to initMdpTransform(), the key-value pairs
 134          * resulting from this function would leave the module
 135          * settings unchanged.
 136          *
 137          * Once the transition from mdp to key-value input is
 138          * complete, this method will probably not exist.
 139          */
 140         void buildMdpOutput(KeyValueTreeObjectBuilder *builder);
 141
 142         /*! \brief
 143          * Sets input parameters from `params` for each module.
 144          *
 145          * \param[in]  params  Contains keys and values from user
 146          *     input (and defaults) to configure modules that have
 147          *     registered options with those keys.
 148          * \param[out] errorHandler  Called to report errors.
 149          */
 150         void assignOptionsToModules(const KeyValueTreeObject  &params,
 151                                     IKeyValueTreeErrorHandler *errorHandler);
 152
 153         /*! \brief
 154          * Normalizes inputrec parameters to match current code version.
 155          *
 156          * This orders the parameters in `ir->param` to match the current code
 157          * and adds any missing defaults.  It also throws an error if the
 158          * inputrec contains parameters that are not recognized by any module.
 159          */
 160         void adjustInputrecBasedOnModules(t_inputrec *ir);
 161
 162         /*! \brief
 163          * Returns an interface for initializing and finalizing output for modules.
 164          */
 165         IMDOutputProvider *outputProvider();
 166         /*! \brief
 167          * Returns an object for computing forces from the modules.
 168          */
 169         ForceProviders *initForceProviders();
 170
 171         /*!
 172          * \brief Add a module to the container.
 173          *
 174          * An object may be added by a client to the bound MD Modules at run time.
 175          * Both the client and the MDModules object may need to extend the life
 176          * of the provided object. However, the MDModules container guarantees
 177          * to extend the life of a provided object for as long as its consumers
 178          * may attempt to use its the interfaces accessible through IMDModule
 179          * methods.
 180          *
 181          * \param module implements some sort of modular functionality for MD.
 182          *
 183          * \note: There is not yet a way to add a IMDModule object between
 184          * creation of the MDModules container and the execution of the various
 185          * initialization protocols it supports.
 186          *
 187          * \internal
 188          * Adding a module at an arbitrary point in the MDModules life breaks
 189          * some assumptions in the protocol of the other member functions. If
 190          * MDModules should not change after some point, we should move this
 191          * to a builder class.
 192          */
 193         void add(std::shared_ptr<gmx::IMDModule> module);
 194
 195         /*! \brief Return a handle to the callbacks.
 196          */
 197         const notifier_type &notifier();
 198
 199     private:
 200         class Impl;
 201
 202         PrivateImplPointer<Impl> impl_;
 203 };
 204
 205 } // namespace gmx
 206
 207 #endif