[gmx-users] Fatal error from grommp in gromacs 5.0.4

[Mark Abraham]

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