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

[Erik Lindahl]

Hi,

Redmine would be good to track the history of the  discussion a year from now.

The big advantage about not being able to change stuff everywhere is that we have a clear owner of data/settings, and when things depend on each other it's clear where they are handled (since it's just one place). It's also wonderful to get rid of the large C structures we were passing everywhere.

So, in general I think it's a decent solution that we have to completely reinitialize new settings if a specific analysis tool wants different settings. While it's trivial to change a single parameter, there could be other settings that depend on it...

Cheers,

Erik

Erik Lindahl <erik.lindahl at scilifelab.se>
Professor of Biophysics
Science for Life Laboratory
Stockholm University & KTH
Office (SciLifeLab): +46 8 524 81567
Cell (Sweden): +46 73 4618050
Cell (US): +1 267 3078746


> On 29 Oct 2016, at 09:05, David van der Spoel <spoel at xray.bmc.uu.se> wrote:
> 
>> On 28/10/16 23:24, Berk Hess wrote:
>> 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.
> 
> Thanks, that looks interesting too. It would be good to reconcile these approaches - the pull code is in a sense the ultimate applied force.
> 
> In fact other things may be interesting to modify too on the fly, like charges and force field parameters. This is possible still by hacking the C-structures even though it is not elegant.
> 
> Not sure whether it may be better to open a redmine than have a mail discussion?
>> 
>> 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.
>> 
> 
> 
> -- 
> David van der Spoel, Ph.D., Professor of Biology
> Dept. of Cell & Molec. Biol., Uppsala University.
> Box 596, 75124 Uppsala, Sweden. Phone:    +46184714205.
> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
> -- 
> Gromacs Developers mailing list
> 
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request at gromacs.org.