<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 12:55 PM, Erik Lindahl <span dir="ltr">&lt;<a href="mailto:erik@kth.se">erik@kth.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<div class="im"><br>
On Apr 17, 2012, at 6:14 PM, Szilárd Páll wrote:<br>
<br>
&gt; a) The need for a new format which will *immediately* replace XTC as<br>
&gt; the default in Gromacs and seems to have requirements that pretty much<br>
&gt; exclude any external library (that is not as widespread as libc :).<br>
&gt;<br>
&gt; b) It&#39;s not in line with the EU deliverable which requires a new<br>
&gt; library with certain specs to be written. Could it be that this is the<br>
&gt; classic case where the specification was created before the actual<br>
&gt; requirement engineering?<br>
<br>
</div>No, I don&#39;t think so, but the goals are different: I very much see the point for a file format that enables you to do fancy stuff, but if you want a file format that is supported by as many applications as possible you have to settle for the greatest common divisor.<br>


<div class="im"><br>
&gt;<br>
&gt; c) The apparent need for ultimate portability to extremely rare and<br>
&gt; exotic architectures without accepting XTC as a fallback on these<br>
&gt; platforms (with conversion for post-processing and analysis). I might<br>
&gt; be wrong, but to me it seems that these extremely rare architectures<br>
&gt; are often more showcase platforms rather than the iron on which 99% of<br>
&gt; the science is carried out.<br>
<br>
</div>Well, windows was exactly such a very exotic architecture until we started using Gromacs in Folding@Home. In hindsight, the decision to rely on XDR libraries for all our IO was a bad one.<br>
<br>
Just counting core-hours, I actually think windows is one of our most common Gromacs architectures today. Similarly, I think there is a clear possibility nativeclient could become a dominant platform quite soon if Google decides to push it for cloud services. It is very difficult to make predictions, in particular about the future.<br>


<br>
*Of course* does not mean a new default file format must be 100% portable without modifying the code.<br>
<div class="im"><br>
&gt; Wouldn&#39;t it be beneficial to struck a balance<br>
&gt; between portability and effort/time required by accepting a short-term<br>
&gt; &quot;compromise&quot; (which isn&#39;t really a compromise if we don&#39;t consider<br>
&gt; ultimate portability a strict requirement :). XTC will have to be<br>
&gt; anyway maintained anyway so it could as well be kept as the<br>
&gt; alternative for platforms where the new format is not supported in<br>
&gt; early versions. So a file format that works on all reference platforms<br>
&gt; (that we can and should simply list and track) with XTC  as a fallback<br>
&gt; for the exotic iron should be an acceptable compromise, I&#39;d say.<br>
<br>
</div>I think that&#39;s a perfectly valid short- and long-term balance *as long as there is a way to gradually expand support to other platforms as we need it*.<br>
<br>
The problem isn&#39;t the unimportant platforms, but when a new platform gets important for us, while it might not yet be important for the external library. What do we do when 10MB of source code fails to work on one of our reference platforms?<br>

</blockquote><div>I think the file size (10MB) is not a good metric. A lot is demo and test code. As I said 130k lines is the total code and only 18 files with total of 9300 lines have Windows #ifdef in them. Thus adding Windows support (if it wouldn&#39;t be their) is something absolutely feasible for us (optional by paid or HPC center support). </div>

<div><br></div><div>Roland</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Cheers,<br>
<br>
Erik<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <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>