Bonds error in lammps

To whom it may concern,

I am having errors running these scripts, the errors are mpi errors, so I don’t know if I should post this here.

What I need to do is simulate a structure having pairwise potentials, bonding terms and angle terms.

What is the problem is that when I build a structure incorporating bonds and angles I get these errors (attached) even if I use this structure using a buckingham potential.

I have tried to run this on various linux machines and I always get this segmentation error.

I shall try re-install the program, but I would like to ask if you know of any known issues with the use of bonds please.

Thank you and awaiting your reply

Reuben

hangleq.DATA (10.5 KB)

run.sh (560 Bytes)

test1.in (2.08 KB)

Testrun.o786190 (12.3 KB)

Testrun.po786190 (144 Bytes)

This advice is for all the folks who just post their input
files to the mail list, and say "help me". That's not
an efffective way to get help.

So, what is the error?
No one wants to sift thru your files. Please
list the error message in your posting along with some
thermo output from your simulation to show what it
is doing when the error occurs. And some explanation
of what you have done to isolate/debug the problem.

Otherwise we think that your first response to an error
is to post to the mail list, rather than it being your last
response.

Steve

Just to clarify,

I have also run tests using just the atom_style bond only, with just a bonding potential and I still get the error.

Hope this helps, please do tell me if I can run any further tests.

Thank you again

Reuben

Just to clarify,

I have also run tests using just the atom_style bond only, with just a
bonding potential and I still get the error.

Hope this helps, please do tell me if I can run any further tests.

strategies for how to debug problematic input decks have
been discussed on this mailing list repeatedly. please help
yourself by taking a good look at the mailing list archives.

from your description it appears that your segmentation fault
happens when you read the data file. logically, then the problem
is most likely that your data file is not correctly formatted.

i suggest you check that out, perhaps with a system containing
only a single molecule.

it is highly unlikely that somebody else will do this for you.
there ain't no escape from the blues...

good luck,
    axel.

Unless Reuben had the ability to recompile lammps with debug flags and
run it with a debugger, it would have been a long process of trial and
error to find this particular bug. The problem is that his data file
does not end in a newline.

This is a user error, but let's improve LAMMPS' error handling/reporting.
Several files including atom.cpp, fix_rigid.cpp, and fix_tmd.cpp make
unsafe use of the pointer returned by a "strchr" function. This
particular error can be fixed by replacing every instance of:

next = strchr(buf,'\n');

with

if (! (next = strchr(buf,'\n'))) next = buf + strlen(buf);

(and on line 425 of fix_tmd.cpp use:
if (! (next = strchr(bufptr,'\n'))) next = bufptr + strlen(bufptr):wink:

Cheers Reuben
(Your files still have some other errors, which you will have to investigate.)
Good luck.

Andrew

P.S.
I'm writing some code for checking syntax errors in data files and LT
files now (but I don't think my code would have caught this).

Changes made, and code tested. (The attached files are modified
versions of the files from lammps-28Oct12.)

Cheers!
Andrew

There are other places where "strchr()" is invoked, and I did not
check them all carefully. But just making these few changes could
help.

atom.cpp (43.6 KB)

fix_rigid.cpp (73.1 KB)

fix_tmd.cpp (15.2 KB)

Thanks a lot Andrew for everything.

I have rewritten the files and it works fine now… I will try to use linux in order to build the files for LAMMPS so as to avoid this problem as much as possible. Could not have debugged the program and found this problem myself.

THanks a lot

Reuben

I think this problem was already fixed for data files in the
past month, by having read_data.cpp insure each chunk
of lines it reads ends in a newline (so no change to atom.cpp).

Good catch on noting that fix rigid and fix tmd need this logic
as well.

Steve