<div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">I&#39;ll check the issue today and have a fix in mind that should address the portability issue.</div><div dir="auto"><br></div><div dir="auto">Concerning the TPR size I can check again for possible optimizations, but the way the code is written is to simply ensure that variables are stored in multiples of &lt;char&gt;.</div><div dir="auto"><br></div><div dir="auto">Could you please also open an issue at <a href="http://redmine.gromacs.org">redmine.gromacs.org</a> with the files for the test cases and target it at 2020?</div><div dir="auto"><br></div><div dir="auto">I&#39;ll see that there is a possible fix for you to try later today.</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto"><br></div><div dir="auto">Paul</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 26 Dec 2019, 23:04 Jonathan Barnoud, &lt;<a href="mailto:jonathan@barnoud.net">jonathan@barnoud.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    <div>Hello everyone,<br>
    </div>
    <div><br>
    </div>
    <div>I upgraded the code of MDAnalysis to
      read the latest TPR version. To add to Len&#39;s comments, it appears
      indeed that the new TPR body is 4 times as big as it use to be for
      the same content, and is not portable between architectures. gmx
      dump does fail at reading a file with a different byte order than
      native, and there is no obvious way to determine the endianness of
      the body. While the TPR format is not meant to really be portable,
      it seemed commonly agreed that it was a good file to share
      (<a href="https://pubs.acs.org/doi/abs/10.1021/acs.jcim.9b00665" target="_blank" rel="noreferrer">https://pubs.acs.org/doi/abs/10.1021/acs.jcim.9b00665</a>), it is for
      sure a good input file in MDAnalysis. TPR files are commonly
      produced on a local machine before being actually run on a
      cluster, that may use a different byte order.<br>
    </div>
    <div><br>
    </div>
    <div>&gt; Second the individual bytes of a
      value are padded to 4 bytes per original bytes (each byte is
      packed as `char`). <br>
    </div>
    <div><br>
    </div>
    <div>To be noted that the in-file XDR
      decoder in gromacs (used for the header and prior to gromacs 2020)
      uses 4 bytes for &quot;char&quot;, hence the padding. The in-memory one
      reads 1 padded byte (1 byte of information, 4 bytes in the file).</div>
    <div><br>
    </div>
    <div>As my use case for noticing these
      differences is fairly niche, I may be missing the reason for them.
      In such case, I would be curious to read about them.<br>
    </div>
    <div><br>
    </div>
    <div>Best regards,</div>
    <div>Jonathan<br>
    </div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>On 12/26/19 7:39 PM, Len Kimms wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>Hello everyone,

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.

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.
Is this intentional, if so, why?

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.
Do those padding bytes serve a special purpose?
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.

In the attachment one could find example files from a big- and little-endian system as well as a file created with GROMACS 2019.
I also brought this to the attention of the MDAnalysis devs here:
<a href="https://github.com/MDAnalysis/mdanalysis/issues/2428" target="_blank" rel="noreferrer">https://github.com/MDAnalysis/mdanalysis/issues/2428</a>

Best regards,
   Len</pre>
      <br>
      <fieldset></fieldset>
    </blockquote>
    <p><br>
    </p>
  </div>

-- <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 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 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 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" rel="noreferrer">gmx-developers-request@gromacs.org</a>.</blockquote></div>