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.<br>
<br>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.<br>
<br>Which of the GUIs listed on the wiki (<a href="http://wiki.gromacs.org/index.php/GUI">http://wiki.gromacs.org/index.php/GUI</a>) 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.<br>
<br>Roland<br><br><div class="gmail_quote">On Sun, Feb 22, 2009 at 6:58 PM, Mark Abraham <span dir="ltr"><<a href="mailto:Mark.Abraham@anu.edu.au">Mark.Abraham@anu.edu.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">David van der Spoel wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mark Abraham wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sander Pronk wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi everybody,<br>
<br>
I've made some changes to grompp (not committed yet) that:<br>
<br>
- will allow the use of cpp-style #include and #define in .mdp files (useful for setting up multiple similar simulations, but also for tutorials).<br>
</blockquote></blockquote>
I assume you have used the existing cpp library?<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
That looks good to me. I also generate my .mdp files with scripts, but this feature would enable me to avoid that.<br>
</blockquote>
I'm not sure, nowadays one needs to do series of simulations anyway, so scripting is a necessary evil.<br>
</blockquote>
<br></div>
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<br>
<br>
gen_seed = SEED_FROM_COMMAND_LINE<br>
<br>
enables a master script to call grompp with (say)<br>
<br>
grompp -DSEED_FROM_COMMAND_LINE=23441<br>
<br>
That adds a lot of complexity to the interpretation, however. Have I misunderstood Sander's intent with the use of #define?<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- allows multiple assignments of .mdp parameters, through overrides so that the last assignment is the one that counts.<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
And it would reverse the current policy, that is first option goes, implying that one may get different results with the same input.<br>
<br>
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.<br>
</blockquote>
<br></div>
Merely wrapping the "endless list of options" into an endless list of XML tags (say), gets you something like the following XML<br>
<br>
<mdp><br>
...<br>
<temperaturecoupling type="berendsen"><br>
<groups><br>
<group tau_t="0.1" ref_t="298">Protein</group><br>
<group tau_t="0.1" ref_t="298">Non-Protein</group><br>
</groups><br>
</temperaturecoupling><br>
...<br>
</mdp><br>
<br>
This is arguably<br>
<br>
* 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<br>
* 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).<br>
<br>
Trying to wrap #ifdef-style XML conditional structures into the above would be a bit ugly... say<br>
<br>
...<br>
<variable name="USING_RF"/><br>
...<br>
<if test="//variable[@name='USING_RF']"><br>
<group tau_t="0.01" ref_t="298">Protein</group><br>
</if><br>
...<br>
<br>
where that test construct is an XPath expression.<br>
<br>
Such XML is readily generatable with scripts. For example, in Perl using XML::Writer you get lines like<br>
<br>
if ( $do_rf ) {<br>
$do_rf = 'USING_RF';<br>
$tau_t = 0.01;<br>
$ref_t = 298;<br>
...<br>
$xml->startTag("if", "test" => "//variable[\@name='${do_rf}']");<br>
foreach my $group ("Protein", "Non-Protein) {<br>
$xml->dataElement("group", $group, "tau_t" => $tau_t, "ref_t" => $ref_t);<br>
}<br>
$xml->endTag("if");<br>
}<br>
<br>
if you wanted to leave the XML-level conditionals in place, or more likely<br>
<br>
if ( $do_rf ) {<br>
$tau_t = 0.01;<br>
$ref_t = 298;<br>
...<br>
foreach my $group ("Protein", "Non-Protein) {<br>
$xml->dataElement("group", $group, "tau_t" => $tau_t, "ref_t" => $ref_t);<br>
}<br>
}<br>
<br>
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.<br>
<br>
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.<div><div></div><div class="Wj3C7c"><br>
<br>
Mark<br>
_______________________________________________<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://www.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://www.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>