[gmx-users] Fatal error in grompp

[James]

Hi Mark,

Thank you for the input. You were correct -- the key was in how the
corrupted file was being written. I was thinking that gromac was writing
bad files because I couldn't find any errors in our code. And, there
weren't any errors in our code per se. But, we were using Octave to write
files and it turns out there is a bug in Octave 4.0.0 that was munging our
strings. In fact, the bug is so bad that it's hard to believe it was
released that way, and that 4.0.0 (which is over two years old) is still
what apt installs (at least on my Ubuntu system). Adding a more up-to-date
repository and updating Octave fixed it.

Sincerely,
James


> ------------------------------
>
> Message: 5
> Date: Sat, 23 Dec 2017 03:43:22 +0000
> From: Mark Abraham <mark.j.abraham at gmail.com>
> To: gmx-users at gromacs.org
> Subject: Re: [gmx-users] Fatal error from grommp in gromacs 5.0.4
> Message-ID:
>         <CAMNuMAQccTnLzGZiCC1+TuR=KYhWAz6DVJLszrHu_scGbRQZRQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> On Sat, Dec 23, 2017 at 1:16 PM James <james at ryley.com> wrote:
>
> > Hi All,
> >
> > I've run into a perplexing problem. I take an initial .gro file, do an
> > energy minimization on it, and then begin an MD simulation. File-wise,
> the
> > sequence of events is:
> >
> > file_to_minimize.gro -> file_for_md.gro -> frame_1.gro -> frame_2.gro
> >
> > Everything is fine up until frame_2.gro, which is written with only 6
> atom
> > columns (the atom coordinates and velocities), whereas frame_1.gro had
> 9-10
> > columns (residue number and name, and atom number and name, plus the
> other
> > 6). The non-atom lines (title, atom count, and the last line for the
> > bounding box) are fine. And, the atom columns that are present seem fine.
> > The formats are as they should be, with no excessively large numbers or
> > corruption.
> >
>
> That sounds impossible for either modern or 5.0.4 GROMACS. What commands
> are you running?
>
>
> > I'm not even sure the missing columns are the issue, so I guess the first
> > question is: Should a .gro file work with only the atom coordinates and
> > velocities (plus the appropriate header and footer lines)?
> >
>
> No.
>
>
> > Regardless, this is what I am getting when grommp tries to process
> > frame_2.gro:
> >
> > ===============================
> > gromacs-5.0.4/src/gromacs/fileio/confio.c, at line 1040:
> >
> > Fatal error:
> > Something is wrong in the coordinate formatting of file
> > frame_2.gro.
> > ===============================
> >
> > In looking at confio.c, it seems that a line in frame_2.gro is failing
> the
> > test at line 1038, which appears to be looking for 2 floating point
> numbers
> > (why 2? I would think it would be 3, one each for X, Y, and Z). If it got
> > that far (handling of the other columns occurs earlier in confio.c), that
> > implies to me that perhaps the missing columns are not the issue. But if
> > not, I don't know why its failing. And, either way, I don't know why the
> > columns are missing.
> >
>
> The best thing one can say about that code is that it seems to work if you
> give it a valid .gro file... Since there's an outer loop over dimensions,
> and the string has already been null terminated, the second float in the
> sscanf format is merely checking for some kind of mis-formatted input.
>
>
> > Has anyone seen this behavior before, or have a theory?
> >
> > By the way, in case any of the developers see this, an error that says
> > "Something is wrong..." isn't all that informative (but better than
> > nothing!). It would be great if sanity checks provided more information
> > upon failure. In this case, knowing what line of the .gro file was
> causing
> > the error, and printing the values for BUF, &x1, and &x2, would be really
> > helpful. (That being said, I don't mean to sound too critical -- gromacs
> is
> > a great tool and I realize there aren't enough resources to make
> everything
> > perfect.)
> >
>
> Yeah, it's not very nice. The best one can do is say "this line "%s" number
> %d in file %s wasn't formatted correctly." However, if the reading code is
> correct, the values in BUF, x1 or x2 are useless to a user. In your case,
> it would probably fire on the first atom line, and you'd still be writing
> this email :-)
>
> The real problem is how you managed to get a broken format written, not
> whether the reading code does anything good with that broken file.
>
> Mark
>
> Sincerely,
> > James
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> > send a mail to gmx-users-request at gromacs.org.
> >
>
>
> ------------------------------
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>
> End of gromacs.org_gmx-users Digest, Vol 164, Issue 76
> ******************************************************
>