[gmx-developers] Trade-offs between encapsulation and low level modifications of class variables.
hess at kth.se
Fri Oct 28 23:24:43 CEST 2016
Have you seen my external pull potential functionality change
I don't know if it's something like that that you would need, or you
would rather have a general framework to modify mdp parameters on the fly.
On 10/28/2016 08:06 PM, David van der Spoel wrote:
> recently (over the last year) I have been working on the electric
> field code as a template for other applied forces. Teemu has done tons
> of work commenting, cleaning up and adding more patches with the
> result that we now almost have a complete framework for reading e.g.
> MDP and TPX files with the same code (correct me if I'm wrong), and a
> JSON mdp file should be doable in the near future as well.
> In the process lots of encapsulation has been done of the type "bare
> outside class interface with Impl_ for the details". Obviously this
> has many advantages like decluttered interfaces and modularization.
> However, part of the rationale for my changes was to be able to modify
> e.g. the electric field parameters from a program (not mdrun) and
> re-evaluate the energy and dipole of a molecule, which would yield the
> polarizability. The functions to do this are now not accessible
> anymore, except by faking reading a new MDP input, and even that is
> not possible anymore outside readir.cpp since the last few patches
> (most of which I approved :) ).
> There may be similar cases, where one would like to change variables,
> like steered MD, certain free energy schemes or analysis tools. I'm a
> bit at a loss how to deal with this, would be great to have some
> feedback on this.
More information about the gromacs.org_gmx-developers