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
  66 /*! \libinternal \brief
  67  * \brief Signals that the communication record is set up and provides this record.
  68  */
  69 struct CommunicationIsSetup
  70 {
  71     //! The communication record that is set up.
  72     const t_commrec &communicationRecord_;
  73 };
  74
  75
  76 /*! \libinternal \brief
  77  * Manages the collection of all modules used for mdrun.
  78  *
  79  * This class acts as a central place for constructing modules for mdrun
  80  * and wiring up dependencies between them.  This class should be the only
  81  * place that contains the full list of modules, although in the future, some
  82  * code (e.g., in tools) may benefit from the ability to only create one or a
  83  * few modules and use them.
  84  *
  85  * The general idea is that each module takes care of its own data rather than
  86  * mdrun having to know about all the details of each type of force calculation.
  87  * Initially this is applied for simple things like electric field calculations
  88  * but later more complex forces will be supported too.
  89  *
  90  * Currently, where the set of modules needs to be accessed, either a pointer
  91  * to MDModules is passed around, or an instance of IMDOutputProvider or
  92  * ForceProviders returned from MDModules.  These objects returned from
  93  * MDModules call the corresponding methods in the relevant modules.
  94  * In the future, some additional logic may need to be introduced at
  95  * the call sites that can also influence the signature of the methods,
  96  * similar to what ForceProviders already does for force computation.
  97  *
  98  * The assignOptionsToModules() and adjustInputrecBasedOnModules() methods of
  99  * this class also take responsibility for wiring up the options (and their
 100  * defaults) for each module.
 101  *
 102  * \inlibraryapi
 103  * \ingroup module_mdrunutility
 104  */
 105 class MDModules
 106 {
 107     public:
 108         MDModules();
 109         ~MDModules();
 110
 111         //! Register callback function types for MDModules
 112         using notifier_type = registerMdModuleNotification<
 113                     CommunicationIsSetup,
 114                     KeyValueTreeBuilder*,
 115                     const KeyValueTreeObject &,
 116                     LocalAtomSetManager *
 117                     >::type;
 118
 119         /*! \brief
 120          * Initializes a transform from mdp values to sectioned options.
 121          *
 122          * \see IMdpOptionProvider::initMdpTransform()
 123          *
 124          * Initializes the combined transform from all modules.
 125          */
 126         void initMdpTransform(IKeyValueTreeTransformRules *rules);
 127
 128         /*! \brief Initializes a builder of flat mdp-style key-value pairs
 129          * suitable for output.
 130          *
 131          * If used as input to initMdpTransform(), the key-value pairs
 132          * resulting from this function would leave the module
 133          * settings unchanged.
 134          *
 135          * Once the transition from mdp to key-value input is
 136          * complete, this method will probably not exist.
 137          */
 138         void buildMdpOutput(KeyValueTreeObjectBuilder *builder);
 139
 140         /*! \brief
 141          * Sets input parameters from `params` for each module.
 142          *
 143          * \param[in]  params  Contains keys and values from user
 144          *     input (and defaults) to configure modules that have
 145          *     registered options with those keys.
 146          * \param[out] errorHandler  Called to report errors.
 147          */
 148         void assignOptionsToModules(const KeyValueTreeObject  &params,
 149                                     IKeyValueTreeErrorHandler *errorHandler);
 150
 151         /*! \brief
 152          * Normalizes inputrec parameters to match current code version.
 153          *
 154          * This orders the parameters in `ir->param` to match the current code
 155          * and adds any missing defaults.  It also throws an error if the
 156          * inputrec contains parameters that are not recognized by any module.
 157          */
 158         void adjustInputrecBasedOnModules(t_inputrec *ir);
 159
 160         /*! \brief
 161          * Returns an interface for initializing and finalizing output for modules.
 162          */
 163         IMDOutputProvider *outputProvider();
 164         /*! \brief
 165          * Returns an object for computing forces from the modules.
 166          */
 167         ForceProviders *initForceProviders();
 168
 169         /*!
 170          * \brief Add a module to the container.
 171          *
 172          * An object may be added by a client to the bound MD Modules at run time.
 173          * Both the client and the MDModules object may need to extend the life
 174          * of the provided object. However, the MDModules container guarantees
 175          * to extend the life of a provided object for as long as its consumers
 176          * may attempt to use its the interfaces accessible through IMDModule
 177          * methods.
 178          *
 179          * \param module implements some sort of modular functionality for MD.
 180          *
 181          * \note: There is not yet a way to add a IMDModule object between
 182          * creation of the MDModules container and the execution of the various
 183          * initialization protocols it supports.
 184          *
 185          * \internal
 186          * Adding a module at an arbitrary point in the MDModules life breaks
 187          * some assumptions in the protocol of the other member functions. If
 188          * MDModules should not change after some point, we should move this
 189          * to a builder class.
 190          */
 191         void add(std::shared_ptr<gmx::IMDModule> module);
 192
 193         /*! \brief Return a handle to the callbacks.
 194          */
 195         const notifier_type &notifier();
 196
 197     private:
 198         class Impl;
 199
 200         PrivateImplPointer<Impl> impl_;
 201 };
 202
 203 } // namespace gmx
 204
 205 #endif