NEB error when read in final coordinates

Dear lammps users,

When I used LAMMPS ( 9 Dec 2014) to do some NEB calculations, error message says “ERROR: Unexpected end of neb file (…/neb.cpp:405)” after input line like

neb 0 0.001 10000 10000 100 final fright.txt”. Strange thing is this error does not occur always. For example, when the final coordinates file contains 120000 lines for ID x y z of 120000 atoms, it runs well, while I deleted 10000 lines for 10000 atoms’ information(not so much different than the initial coordinats), it prints the above error message. The only difference between the 2 final coordinates file is the total number of atom lines. This inconsistency is a bit weird, since the final coordinates file can contain arbitrary lines for atom information (ID x y z).

I referred to the manual (version 9 Dec 2014) and carefully read the NEB command through. I am doing this calculation followed exactly its commands syntax and I’m pretty sure the final file format is correct, since sometimes with much more than needed information say all the initial atoms’ information, it can be read in and run normally. But the results are wrong, because many of the excess atoms are in exactly the same positions as the first image.

Besides, the final file “fright.txt” can be read in by an older version of LAMMPS (16 Aug 2013) on my personal laptop and run very well but too slowly, of course the neb command is a little different, “neb 0 0.001 10000 10000 100 fright.txt”. But recently, LAMMPS on our cluster is updated to the latest version (9 Dec 2014), so I need to figure out why sometimes it works well while other situations it fails to read in the final coordinates.

Have you ever run into this case? Or do you have any ideas how I can do something to fix this problem?

Thank you,

Guisen Liu

I can’t recall if we changed the format of the NEB coord file, but the current doc page says:

The file can be ASCII text or a gzipped text file (detected by a .gz
suffix). The file can contain initial blank lines or comment lines
starting with “#” which are ignored. The first non-blank, non-comment
line should list N = the number of lines to follow. The N successive
lines contain the following information:

ID1 x1 y1 z1
ID2 x2 y2 z2

IDN xN yN zN :pre

So I assume when you add/delete lines, you are adjusting the leading N value ??
You should be able to verify that your file has the correct # of lines
using “wc”.

If so, please post a (small as possible) data and neb file, and your input
script that generates the file read error. The issue is probably something
simple.

Steve

Dear Steve Plimpton,

Thank you so much!! Following your suggestion, I figured out why and solved my problem.

The not always happening error is because I forgot the important leading N sometimes. When I added it to the file, not such error anymore, and it is running on our cluster very well now.

Thank you,

Guisen Liu