Hello,
Have been trying to use the atom_style tri and apparently found a bug. While running the attached input, I was getting the following error:
ERROR on proc 0: No angles allowed with this atom style
As there were no angles in the header and the problem was replaced by another if I removed triangles from it, I suspected the program was picking the “angles” part from triangles. This seems to be the case, because changing the following line of read_data.cpp (line 378 of the 14_may_2012 tarball)
else if (strstr(line,“angles”)) sscanf(line,BIGINT_FORMAT,&atom->nangles);
to
else if (strstr(line,“ANGLES”)) sscanf(line,BIGINT_FORMAT,&atom->nangles);
and recompiling apparently solved this issue. Or is there a problem with the input and this “fix” is only hiding the real issue?
Thanks for the help,
Leonardo
in.triangle (388 Bytes)
data.triangle (187 Bytes)
Hello,
Have been trying to use the atom_style tri and apparently found a bug. While
running the attached input, I was getting the following error:
ERROR on proc 0: No angles allowed with this atom style
As there were no angles in the header and the problem was replaced by
another if I removed triangles from it, I suspected the program was picking
the "angles" part from triangles. This seems to be the case, because
changing the following line of read_data.cpp (line 378 of the 14_may_2012
tarball)
else if (strstr(line,"angles")) sscanf(line,BIGINT_FORMAT,&atom->nangles);
to
else if (strstr(line,"ANGLES")) sscanf(line,BIGINT_FORMAT,&atom->nangles);
and recompiling apparently solved this issue. Or is there a problem with the
input and this "fix" is only hiding the real issue?
the fix is incorrect, but the problem is real.
using strstr() to parse the lammps header is not
the best choice, but you can just delete the line
in the data file for now.
axel.
hi leonardo,
please try out the attached version of read_data.cpp
and let us know if that solves the problem for you, too.
this moves the detection of the triangles statement
before looking for angles and so makes sure your
don't get a false match.
it also updates some of the error handlers to
properly terminate on ill-formatted data files in
parallel not hang as some folks have reported
in the past.
axel.
read_data.cpp.gz (7.09 KB)
Hi Axel,
Thanks, the new file worked perfectly!
Leonardo
Posted a patch for this - thanks Axel.
Don't think the error->all calls in command()
should be changed to error->one since all
procs invoke them, but agreed
with the other changes.
Steve
Posted a patch for this - thanks Axel.
Don't think the error->all calls in command()
should be changed to error->one since all
procs invoke them, but agreed
with the other changes.
we had several cases where people reported
a hang when reading data files. those were all
hidden errors that are caught by this but would
not be caught with error->all.
the read_data file format is a bit frail...
axel.
we had several cases where people reported
a hang when reading data files. those were all
hidden errors that are caught by this but would
not be caught with error->all.
Don't think that can be any of the calls in ReadData::command().
All procs should invoke them.
Agree with the other changes though.
Steve
we had several cases where people reported
a hang when reading data files. those were all
hidden errors that are caught by this but would
not be caught with error->all.
Don't think that can be any of the calls in ReadData::command().
All procs should invoke them.
Agree with the other changes though.
ahh. my bad. i misunderstood your e-mail.
i will check it out tomorrow when i update
my development tree from the git repo.
axel.