[gmx-developers] grompp .mdp processing

Sander Pronk pronk at cbr.su.se
Mon Feb 23 12:40:55 CET 2009 

good idea; I'll remove the command-line option and add that one.

On 23 Feb 2009, at 12:15 , hessb at mpip-mainz.mpg.de wrote:

> Hi,
>
> Just to avoid confusion: with my previous post I meant
> overriding an option by supplying one option twice.
>
> Consistency might not have been the correct word.
> But if you want to override options, why not set it in the mdp
> file itself? In that way you do not have to supply another
> command line option and when a user reads the mdp file
> he knows that an option might be overriden.
> I would suggest something like:
> multiple_entries = no / use_last
>
> Berk
>
>> That's easy to implement; however, I don't really feel that it's a
>> consistency issue when you can set to either refuse to allow multiple
>> assignments -- and bail out -- or allow them.
>>
>> Sander
>>
>>
>> On 23 Feb 2009, at 10:25 , hessb at mpip-mainz.mpg.de wrote:
>>
>>> Hi,
>>>
>>> I would prefer to have the multiple mdp option switch
>>> in the mdp file, not as an option to grompp.
>>> In that way the mdp files are at least internally consistent.
>>>
>>> Berk
>>>
>>>>
>>>> On Feb 23, 2009, at 00:58 , Mark Abraham wrote:
>>>>
>>>>> David van der Spoel wrote:
>>>>>> Mark Abraham wrote:
>>>>>>> Sander Pronk wrote:
>>>>>>>> Hi everybody,
>>>>>>>>
>>>>>>>> I've made some changes to grompp (not committed yet) that:
>>>>>>>>
>>>>>>>> - will allow the use of cpp-style #include and #define in .mdp
>>>>>>>> files (useful for setting up multiple similar simulations, but
>>>>>>>> also for tutorials).
>>>>>> I assume you have used the existing cpp library?
>>>>>>>
>>>>>>> That looks good to me. I also generate my .mdp files with  
>>>>>>> scripts,
>>>>>>> but this feature would enable me to avoid that.
>>>>>> I'm not sure, nowadays one needs to do series of simulations
>>>>>> anyway, so scripting is a necessary evil.
>>>>>
>>>>> If #define is useful in the .mdp file, then the value of
>>>>> preprocessor variables must be being used - so probably that needs
>>>>> #ifdef and #if and such also. Anyway, if variable interpretation  
>>>>> is
>>>>> being done, an .mdp file line like
>>>>>
>>>>> gen_seed = SEED_FROM_COMMAND_LINE
>>>>>
>>>>> enables a master script to call grompp with (say)
>>>>>
>>>>> grompp -DSEED_FROM_COMMAND_LINE=23441
>>>>>
>>>>> That adds a lot of complexity to the interpretation, however.  
>>>>> Have I
>>>>> misunderstood Sander's intent with the use of #define?
>>>>
>>>> That's one of the things that are possible - it's useful for free
>>>> energy simulations where the same simulation has to be run at
>>>> different lambdas.
>>>>
>>>> The other nice thing is being able to #include, which enables the  
>>>> use
>>>> of system-specific 'standard includes' with good settings that  
>>>> remain
>>>> consistent from structure energy minimization to production run.
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>> - allows multiple assignments of .mdp parameters, through
>>>>>>>> overrides so that the last assignment is the one that counts.
>>>>>>>
>>>>>>> Doing so always and silently would be asking for trouble,  
>>>>>>> however
>>>>>>> if they're only enabled with -m, and come with a note to the  
>>>>>>> user
>>>>>>> when they've occurred, that should be useful in a few corner
>>>>>>> cases.
>>>>>> And it would reverse the current policy, that is first option  
>>>>>> goes,
>>>>>> implying that one may get different results with the same input.
>>>>>> Further, I feel a bit uncomfortable with extending the mdp files
>>>>>> further, because we should rather move away from the endless list
>>>>>> of options. I  haven't thought this trough, but I would prefer to
>>>>>> move to a slightly more complex format that, however, is more  
>>>>>> user
>>>>>> friendly. Thinking of a folding editor file (xml springs to  
>>>>>> mind).
>>>>>> It should still be possible to generate using a script, but there
>>>>>> are xml bindings for Perl and Python as well.
>>>>>
>>>>> Merely wrapping the "endless list of options" into an endless list
>>>>> of XML tags (say), gets you something like the following XML
>>>>>
>>>>> <mdp>
>>>>> ...
>>>>> <temperaturecoupling type="berendsen">
>>>>>  <groups>
>>>>>    <group tau_t="0.1" ref_t="298">Protein</group>
>>>>>    <group tau_t="0.1" ref_t="298">Non-Protein</group>
>>>>>  </groups>
>>>>> </temperaturecoupling>
>>>>> ...
>>>>> </mdp>
>>>>>
>>>>> This is arguably
>>>>>
>>>>> * more or less complex (links between different options like
>>>>> tc_groups and tau_t and ref_t are now explicit and can be tested  
>>>>> for
>>>>> by validating against the DTD before we try to parse it; but  
>>>>> there's
>>>>> a bunch of formatting constraints) and
>>>>> * more or less user friendly (the data is now structured and the
>>>>> format adds meaning to content; but there's all this visual cruft
>>>>> and users might feel constrained to need to learn an XML editor;
>>>>> increasingly the latter will become a requisite IT skill).
>>>>>
>>>>> Trying to wrap #ifdef-style XML conditional structures into the
>>>>> above would be a bit ugly... say
>>>>>
>>>>> ...
>>>>> <variable name="USING_RF"/>
>>>>> ...
>>>>> <if test="//variable[@name='USING_RF']">
>>>>> <group tau_t="0.01" ref_t="298">Protein</group>
>>>>> </if>
>>>>> ...
>>>>>
>>>>> where that test construct is an XPath expression.
>>>>>
>>>>> Such XML is readily generatable with scripts. For example, in Perl
>>>>> using XML::Writer you get lines like
>>>>>
>>>>> if ( $do_rf ) {
>>>>> $do_rf = 'USING_RF';
>>>>> $tau_t = 0.01;
>>>>> $ref_t = 298;
>>>>> ...
>>>>> $xml->startTag("if", "test" => "//variable[\@name='${do_rf}']");
>>>>> foreach my $group ("Protein", "Non-Protein) {
>>>>>  $xml->dataElement("group", $group, "tau_t" => $tau_t, "ref_t" =>
>>>>> $ref_t);
>>>>> }
>>>>> $xml->endTag("if");
>>>>> }
>>>>>
>>>>> if you wanted to leave the XML-level conditionals in place, or  
>>>>> more
>>>>> likely
>>>>>
>>>>> if ( $do_rf ) {
>>>>> $tau_t = 0.01;
>>>>> $ref_t = 298;
>>>>> ...
>>>>> foreach my $group ("Protein", "Non-Protein) {
>>>>>  $xml->dataElement("group", $group, "tau_t" => $tau_t, "ref_t" =>
>>>>> $ref_t);
>>>>> }
>>>>> }
>>>>>
>>>>> It is also straightforward to provide scripts for the .mdp <->  
>>>>> <mdp>
>>>>> conversions in the change-over period. One would use Perl for  
>>>>> both,
>>>>> though technically XSLT is probably the best tool for the <mdp> -
>>>>>> .mdp conversion.
>>>>>
>>>>> I'm far from convinced that the increase in usability outweighs  
>>>>> the
>>>>> need for people to learn how to manage all this XML stuff,  
>>>>> however.
>>>>>
>>>>
>>>>
>>>> I think I agree; the most annoying aspect of the current .mdp files
>>>> is
>>>> the lack of information hierarchy: it's hard to make out what's
>>>> important and what is not, and xml wouldn't be the ideal format for
>>>> what is essentially an options list. In many cases there is a
>>>> sensible
>>>> default (like 'xyz' for pb, or 'no' for free_energy), where
>>>> deviations
>>>> for the default are only needed if they're specifically needed  
>>>> (hence
>>>> the need for multiple assignment - together with #include it would
>>>> allow for better management of default settings).
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> BTW, personally I don't see a reason why the parameter file  
>>>> shouldn't
>>>> be Turing-complete.  :-)
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gmx-developers mailing list
>>>> gmx-developers at gromacs.org
>>>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>>>> Please don't post (un)subscribe requests to the list. Use the
>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>
>>>
>>>
>>> _______________________________________________
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>>
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
>>
>
>
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.

More information about the gromacs.org_gmx-developers mailing list