[gmx-developers] Trade-offs between encapsulation and low level modifications of class variables.

[Berk Hess]

Hi,

Have you seen my external pull potential functionality change 
(28013db1c1515f01c4d4acd64eb510ead4fef2db)?
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.

Cheers,

Berk

On 10/28/2016 08:06 PM, David van der Spoel wrote:
> Hi,
>
> 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.