On Fri, Mar 18, 2016 at 9:04 PM, Mark Abraham <mark.j.abraham.gmail.com>
wrote:
> Hi,
>
> The GROMACS TRR format is based on XDR, which is defined to be a big-endian
> format in a 20-year-old IETF standard. I think there is no good reason to
> write a tool to be able to write non-confoming XDR, and so no reason for
> any tools to be able to read such files. I also think we have better things
> to do than rippling "please support little-endian TRR" requests to all the
> different software packages that might handle such files! :-)
>
​Perhaps, but the current behavior of choking by segfault is decidedly
suboptimal. I can understand not wanting to spend the time to implement
little endian recognition, but putting in a magic number check to print out
a useful error message seems to me to be a clear, easy improvement over the
current behavior (if the magic number doesn't match what's expected, it's
clearly not a TRR and you can quit saying so).
That said, other packages that handle TRR files *do* handle little-endian
encodings (specifically VMD, whose plugins GROMACS links to for every other
file type). In a little-endian world, displaying an error message at the
beginning rather than a segfault somewhere in the middle is a clear
improvement in any program's UI. Such things would probably help GROMACS
play nicer in a more inclusive ecosystem.
All the best,
Jason
--
Jason M. Swails
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Mar 19 2016 - 12:00:03 PDT
