[gmx-developers] grompp .mdp processing

[Roland Schulz]

While XML is great for file format standards, I agree with Mark that XML is
not the best choice for configuration files. XML is not that easy to edit by
hand. It is just a pain to type the additional characters (angle bracket
tax). And I think it is not to hard to parse the current format.

I agree with David that a hierarchical editor would be great. But I think we
can easily do a graphical editor without having to change the mdp file
format. And regarding writing the mdp file with a script: I don't see how a
hierarchy would help. One is always free to use a hierachy in the script.

Which of the GUIs listed on the wiki (http://wiki.gromacs.org/index.php/GUI)
are still actively being developed? May be one could add a mdp editor to one
of the GUIs. I think this would be great for beginners. And it shouldn't be
much work at all.

Roland

On Sun, Feb 22, 2009 at 6:58 PM, Mark Abraham <Mark.Abraham at anu.edu.au>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?
>
>
>>>  - 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.
>
>
> Mark
> _______________________________________________
> 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.
>



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20090223/fb2ddda3/attachment.html>