[gmx-developers] grompp .mdp processing
chris.neale at utoronto.ca
chris.neale at utoronto.ca
Mon Feb 23 20:53:43 CET 2009
Hello,
I don't see any benefit to allowing multiple instances of a given mdp
option within the same file. First, being a little pedantic, I'll
point out that multiple occurrences of the 'multiple_entries' .mdp
option would lead to complex, and possibly unexpected, behaviour.
Second, there are many scripting options to replace lines in mdp
files, one (bash) example being:
{
NEWVAL=1993
cat orig.mdp | grep -v '^gen_seed '
echo "gen_seed = ${NEWVAL}"
} > new.mdp
When I have a lot of parameters that I commonly change, I create a
template .mdp file and then use sed to add the desired parameters (in
bash):
$cat template.mdp
nsteps = NSTEPS
tinit = TINIT
dt = TSTEP
nstxout = NSTEPS
nstvout = NSTEPS
nstfout = NSTEPS
nstenergy = SAVE_FREQUENCY
nstxtcout = SAVE_FREQUENCY
nstlog = SAVE_FREQUENCY0
...
$sed "s/TINIT/${tinit}/" template.mdp | sed "s/TSTEP/${tstep}/" | sed
"s/NSTEPS/${nsteps}/" | sed "s/SAVE_FREQUENCY/${save_frequency}/" >
actual.mdp
Third, one way alternative way to show the hierarchy of parameters in
the mdp file is to inherit the parent name:
free_energy = on
free_energy_init_lambda = 0.1
free_energy_delta_lambda = 0
free_energy_soft-core_power = 1
free_energy_soft-core_alpha = 0.5
free_energy_soft-core_sigma = 0.3
I am not at all against any of the great ideas previously suggested,
with the exception that I can not run GUIs on all of our clusters
(even with ssh -X, which is in some cases disallowed) and thus I hope
that there is such thing as a non-gui XML editor.
Chris.
Quoting Sander Pronk <pronk at cbr.su.se>:
> 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.
>
> _______________________________________________
> 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 thewww
> interface or send it to gmx-developers-request at gromacs.org.
More information about the gromacs.org_gmx-developers
mailing list