Hi,
On Sat, Mar 19, 2016 at 7:33 PM Jason Swails <jason.swails.gmail.com> wrote:
> 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'm skeptical that this is the behaviour. There's certainly been no bug
report at
http://redmine.gromacs.org/. There's a magic number at the start
of every trr frame header, even though it is redundant, precisely to act as
such a catch-all.
> 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).
>
Sure, but we have that kind of behaviour :-) See e.g.
https://github.com/gromacs/gromacs/blob/master/src/gromacs/fileio/trrio.cpp#L87
.
> 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).
Yes, but IIRC that's just a side-effect of having to handle formats like
DCD that don't specify. The way to be portable is to specify, document, and
have people follow it, rather than require everyone else write code tricks.
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.
>
Indeed. I'll look forward to seeing such input so I can fix it (e.g. at
http://redmine.gromacs.org/). I expect the file handling itself is fine,
but some of the analysis tools might be ignoring the failure ;-)
Mark
> All the best,
> Jason
>
> --
> Jason M. Swails
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Mar 19 2016 - 13:00:03 PDT
