Re: [AMBER] GROMACS File Conversion Subtlety

From: Jason Swails <jason.swails.gmail.com>
Date: Sun, 20 Mar 2016 08:03:03 -0700

On Sat, Mar 19, 2016 at 12:32 PM, Mark Abraham <mark.j.abraham.gmail.com>
wrote:

> 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.


​​
http://redmine.gromacs.org/issues/1926
​ -- the behavior there (and the reason it took so long to debug) is a
GROMACS segfault in basic analysis.

Here's the initial report: http://archive.ambermd.org/201603/0335.html

And the repro by the cpptraj developer:
http://archive.ambermd.org/201603/0336.html

So yea, it was a segfault.


-- 
Jason M. Swails
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Mar 20 2016 - 08:30:04 PDT
Custom Search