[gmx-developers] grompp .mdp processing

[David van der Spoel]

> Perhaps just adding some syntax to enforce related settings would make 
> the structure clearer:
> 
> free_energy
> {
>     on = true
>     init_lambda = 0.1
>     delta_lambda = 0
>     soft-core
>     {
>         power = 1
>         alpha = 0.5
>         sigma = 0.3
>     }
> }
> 
> or, if no free energy calculation is required:
> 
> free_energy
> {
>     on = false
> }
> 
> or no free energy section at all.
> 

I think it would be good to sit down and contemplate what it is that we 
have and what it is that we need. The needs for power users are 
different than those of the "casual" users. Power users can be expected 
to know what they are doing (famous last words...), while casual users 
should be helped to avoid error as much as possible. The current mdp 
file format is simple and gives reasonable defaults in most cases 
(except Coulomb = Cut-off, but changing the default value is also 
problematic).

Over the last years we have discussed moving away from the current 
structure of gromacs, possibly using C++, or at least by using abstract 
data types in C, which are appearing in the code more and more now (see 
src/kernel/gmxcpp.h for an example). Abstract data types allow for a 
more clear separation of code and data, which is crucial for error 
checking and maintainability.

Although Mark has a point that xml files can be complex, this does not 
need to be a problem if we provide an API (in different languages, but 
at least C, Perl) for editing the files that provides complete coverage 
of all the options. Think something like:

/* This routine sets the parameters for electrostatics calculations. 
Returns 1 if succesfull or 0 if an error ocurred */

extern int gmx_inputrec_set_electrostatics_algorithm(gmx_inputrec_t 
ir,char *algorithm,double rlist,double,rcoulomb,double rcoul_switch);

extern int gmx_inputrec_set_integrator(gmx_inputrec_t ir,char *integrator);

Both error checking and storing the data will be done inside the 
gmx_inputrec  library. A similar library can be made in Perl or Python.

For casual users we should provide a graphical editor (we are working 
with the Bioclipse people here in Uppsala to try to make a good GROMACS 
plugin for Bioclipse, I have a programmer working on this). Power users 
can use their preferred scripting language.

Finally, it has been a design decision not to have scripting 
capabilities in GROMACS, but rather let the user decide which scripting 
language to use. Although the proposal to use CPP within mdp files does 
not represent a big deviation from this, I would really like to have a 
more long-term perspective when making changes to the input files. In 
theory we could even support multiple mdp file formats, but that quickly 
becomes unmaintainable as well.


> 
> 
> BTW, personally I don't see a reason why the parameter file shouldn't be 
> Turing-complete.  :-)
> 
> 

-- 
David van der Spoel, Ph.D., Professor of Biology
Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se