<div dir="ltr">Hi,<div><br></div><div>I just wanted to follow up on this since we had some hectic activity over the weekend :-)</div><div><br></div><div>First, we have solved the padding issue by using xdr opaque datatypes instead, so the TPR size should no longer be larger - thanks for spotting that!</div><div><br></div><div>Second, we did some deep thinking about the endian, and in the end we decided that the most important short-term aspect is to not complicate life too much for other libraries/packages that need to read the raw format. Since the TPR *header* is still stored with normal XDR routines that means it&#39;s big endian, and for this reason we also eventually decided to keep the TPR *body* (which is processed in memory, and then stored to disk) as big endian too. This should hopefully make the changes since release-2019 minimal, and we&#39;ll wait with little-endian until we make a major change in the formats.</div><div><br></div><div><br></div><div>There&#39;s one important caveat with this, though: Any TPR files you generated during the beta stage will likely *not* be compatible with the final released version. Sorry about that!</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 27, 2019 at 12:35 PM Len Kimms &lt;<a href="mailto:len.kimms@uni-muenster.de">len.kimms@uni-muenster.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
thank you all for your explanations. I really appreciate the insight that I got.<br>
<br>
It makes sense to use native endianness and it was indeed not easy to set up a big-endian test system because they are rare nowadays. The most important thing for me is having a clear indication what endiannes a given file has. IMHO the proposed fix does a good job with this.<br>
<br>
Regarding the padding: Writing the buffer as opaque data that is not padded feels less unsettling, but the file size is not much of an issue for me. With the given hint of the endiannes the padding is irrelevant for me and does no harm.<br>
<br>
Thank you again for the work you put into this!<br>
<br>
Best wishes,<br>
   Len<br>
<br>
<br>
Paul bauer schrieb am 2019-12-27:<br>
&gt; Hello,<br>
<br>
&gt; fix has been upload here: <a href="https://gerrit.gromacs.org/c/gromacs/+/15059" rel="noreferrer" target="_blank">https://gerrit.gromacs.org/c/gromacs/+/15059</a><br>
<br>
&gt; Cheers<br>
<br>
&gt; Paul<br>
<br>
&gt; On 27/12/2019 11:18, Paul bauer wrote:<br>
&gt; &gt;Hello,<br>
&gt; &gt;<br>
&gt; &gt;I opened <a href="https://redmine.gromacs.org/issues/3269" rel="noreferrer" target="_blank">https://redmine.gromacs.org/issues/3269</a> for this and should have a fix for it soon.<br>
&gt; &gt;<br>
&gt; &gt;Cheers<br>
&gt; &gt;<br>
&gt; &gt;Paul<br>
&gt; &gt;<br>
&gt; &gt;On 27/12/2019 10:12, Erik Lindahl wrote:<br>
&gt; &gt;&gt;Hi Len &amp; Jonathan,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Paul found an issue related to different-endianness-reading that has apparently slipped through the Debian tests (since they didn&#39;t run the regression tests by default). We&#39;ll get a fix in for that before the release.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;The reason for the change is that the XDR I/IO layer is becoming very outdated. First, while it made a lot of sense to stick to the standard (big) &quot;network endian&quot; in the late 90s, today the problem is that virtually every single architecture is little endian, so you incur all the overhead of swapping both on writing and reading. Second, the way this is implemented in XDR means it&#39;s very slow - we&#39;re basically doing byte-by-byte reading.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;This change will instead allow all architectures to use highly efficient buffered I/O in their default endian, and then we only have to bother about swapping endianness in the rare cases an actual big-endian machine is involved.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;We&#39;ll also look into the one-padding; for Gromacs it doesn&#39;t matter, but avoiding that might indeed make the life of other codes easier.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Cheers,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Erik<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;On Thu, Dec 26, 2019 at 11:04 PM Jonathan Barnoud &lt;<a href="mailto:jonathan@barnoud.net" target="_blank">jonathan@barnoud.net</a> &lt;mailto:<a href="mailto:jonathan@barnoud.net" target="_blank">jonathan@barnoud.net</a>&gt;&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    Hello everyone,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    I upgraded the code of MDAnalysis to read the latest TPR version.<br>
&gt; &gt;&gt;    To add to Len&#39;s comments, it appears indeed that the new TPR body<br>
&gt; &gt;&gt;    is 4 times as big as it use to be for the same content, and is<br>
&gt; &gt;&gt;    not portable between architectures. gmx dump does fail at reading<br>
&gt; &gt;&gt;    a file with a different byte order than native, and there is no<br>
&gt; &gt;&gt;    obvious way to determine the endianness of the body. While the<br>
&gt; &gt;&gt;    TPR format is not meant to really be portable, it seemed commonly<br>
&gt; &gt;&gt;    agreed that it was a good file to share<br>
&gt; &gt;&gt;    (<a href="https://pubs.acs.org/doi/abs/10.1021/acs.jcim.9b00665" rel="noreferrer" target="_blank">https://pubs.acs.org/doi/abs/10.1021/acs.jcim.9b00665</a>), it is<br>
&gt; &gt;&gt;    for sure a good input file in MDAnalysis. TPR files are commonly<br>
&gt; &gt;&gt;    produced on a local machine before being actually run on a<br>
&gt; &gt;&gt;    cluster, that may use a different byte order.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    &gt; Second the individual bytes of a value are padded to 4 bytes<br>
&gt; &gt;&gt;    per original bytes (each byte is packed as `char`).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    To be noted that the in-file XDR decoder in gromacs (used for the<br>
&gt; &gt;&gt;    header and prior to gromacs 2020) uses 4 bytes for &quot;char&quot;, hence<br>
&gt; &gt;&gt;    the padding. The in-memory one reads 1 padded byte (1 byte of<br>
&gt; &gt;&gt;    information, 4 bytes in the file).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    As my use case for noticing these differences is fairly niche, I<br>
&gt; &gt;&gt;    may be missing the reason for them. In such case, I would be<br>
&gt; &gt;&gt;    curious to read about them.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    Best regards,<br>
&gt; &gt;&gt;    Jonathan<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    On 12/26/19 7:39 PM, Len Kimms wrote:<br>
&gt; &gt;&gt;&gt;    Hello everyone,<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;    while fooling around with the new (i.e. version 2020 rc1) TPR file format I noticed some strange behaviors that I don’t understand. As far as I understand the body of the new format is written by the `gmx::InMemorySerializer`. My following questions are basically about this module.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;    First it seems that the memory serializer writes the values in native byte order. This means that the body of TPR files differ between big- and little-endian systems. The XDR standard used before requires big-endian data. For me, a novice user, the new implementation seems to be less portable and robust. Endian swapping seems to be implemented but not currently used for TPR files.<br>
&gt; &gt;&gt;&gt;    Is this intentional, if so, why?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;    Second the individual bytes of a value are padded to 4 bytes per original bytes (each byte is packed as `char`). Therefore the size increases accordingly.<br>
&gt; &gt;&gt;&gt;    Do those padding bytes serve a special purpose?<br>
&gt; &gt;&gt;&gt;    Also regarding the padding bytes: Some bytes are not, like most others, padded with zeros. In some places they are padded with ones. At first glance this seem to happen to the second byte (big-endian) of a float. From some initial testing my best guess is, that this is caused by the union conversion in `CharBuffer`. With an `unsigned char` in the private union `u` those values would be zero padded.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;    In the attachment one could find example files from a big- and little-endian system as well as a file created with GROMACS 2019.<br>
&gt; &gt;&gt;&gt;    I also brought this to the attention of the MDAnalysis devs here:<br>
&gt; &gt;&gt;&gt;    <a href="https://github.com/MDAnalysis/mdanalysis/issues/2428" rel="noreferrer" target="_blank">https://github.com/MDAnalysis/mdanalysis/issues/2428</a><br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;    Best regards,<br>
&gt; &gt;&gt;&gt;        Len<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    --     Gromacs Developers mailing list<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    * Please search the archive at<br>
&gt; &gt;&gt;    <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a><br>
&gt; &gt;&gt;    before posting!<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;    * For (un)subscribe requests visit<br>
&gt; &gt;&gt;    <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a><br>
&gt; &gt;&gt;    or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a><br>
&gt; &gt;&gt;    &lt;mailto:<a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>&gt;.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;--<br>
&gt; &gt;&gt;Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a> &lt;mailto:<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;&gt;<br>
&gt; &gt;&gt;Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University<br>
&gt; &gt;&gt;Science for Life Laboratory, Box 1031, 17121 Solna, Sweden<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt;--<br>
&gt; &gt;Paul Bauer, PhD<br>
&gt; &gt;GROMACS Release Manager<br>
&gt; &gt;KTH Stockholm, SciLifeLab<br>
&gt; &gt;0046737308594<br>
<br>
<br>
&gt; --<br>
&gt; Paul Bauer, PhD<br>
&gt; GROMACS Release Manager<br>
&gt; KTH Stockholm, SciLifeLab<br>
&gt; 0046737308594<br>
<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>