Dear LAMMPS users,
I made a mistake with my last email and it got sent prematurely. Here is the correct version.
Currently I am using this version of LAMMPS: June 7, 2013.
I want to restart an NEB simulation with different coordinates for each of the images (i.e. one on each processor). The documentation briefly mentions this procedure but it seems to not work as expected.
My current input abbreviated file is as follows:
I want to restart an NEB simulation with different coordinates for each of the images (i.e. one on each processor). The
documentation briefly mentions this procedure but it seems to not work as expected.
Where does it mention that? It’s not currently supported so far as I recall.
You have to input a start and stop state, and it interpolates between.
The doc page does say you can write out restart or dump files from each replica.
But that is just so you can figure out what went wrong, and re-do your calculation
with different end points if need be.
My ultimate goal is to be able to exactly specify the initial coordinates of each of the images which I was hoping could be
accomplished by manipulating the restart files. I would also like to be able to restart NEB simulations from the exact location it
stopped.
Someone sent some code for the former (from text files, not restart files), but we haven’t released it yet.
Not clear why the latter is useful. A NEB calculation is small and quick,
especially in parallel. Why would you not finish it and need to restart it?
Steve
Someone sent some code for the former (from text files, not restart files),
but we haven't released it yet.
Not clear why the latter is useful. A NEB calculation is small and quick,
especially in parallel. Why would you not finish it and need to restart it?
I implemented the same thing and used it for potential fitting. When
changing the interatomic potential I use converged MEPs from the
previous potential. That way I just have to re-converge. About a
factor of 5 faster (if you do thousands of NEB runs it pays off).
Dear all,
I would like to answer to the following statement:
Someone sent some code for the former (from text files, not restart files),
but we haven't released it yet.
Not clear why the latter is useful. A NEB calculation is small and quick,
especially in parallel. Why would you not finish it and need to restart it?
While it is true that NEB calculations are usually quick for simple reactions, or the migration of one vacancy in a solid,
there are problems that are not so quick, for instance the study of the energy barrier for the motion of a dislocation.
This kind of simulations require large systems, and the change of position of the dislocation implies the relaxation
of its elastic field, so a lot of atoms are involved in the NEB calculation. There, a NEB calculation can last for
a very long time (hours, days), and the possibility to restart the NEB calculation if it crashes would be most desirable.
There is another case where it would be nice to start a NEB calculation from an arbitrary chain of configurations.
In some particular problems the linear interpolation between initial and final states produces configurations where
two atoms are extremely close to one another. Such configurations are of course unfavorable, and can have a huge
impact on the NEB calculation. In such cases, it would be desirable to have the possibility to start from configurations
constructed by the user, and then do the actual NEB minimization to find the minimum energy path.
After all, the interpolation of atom positions is *not* part of the NEB algorithm. It is just a convenient scheme to construct
the initial chain of states, and most of the time it is ok. But in some particular cases it would be very desirable to have
the possibility to provide the initial configurations "manually".
I am sorry for bringing these statements without being able to perform the implementation in LAMMPS myself.
I hope these comments are constructive though.
Steve,
Thank you for your quick response. It is much appreciated.
In response to your 3 points:
I assumed, albeit incorrectly, that you could use these to directly restart NEB calculations.
I would very much like to be able to specify the initial coordinates for every image as the system I am studying requires it. A linear interpolation does not suite my needs (and very possibly others) and such a feature is included in the VASP NEB implementation. When do you think you will release this functionality if at all?
Do you foresee including a restart capability to the NEB calculation, even though they are very quick calculations? It seems like a possibly useful feature.
Best regards,
Ross
The comments by several folks were all good points.
It should be relatively easy to add the following 2 options to NEB:
a) specify the filename for the final state as NULL, which would
assume that each replica already has its initial state. Thus you
could setup the states by having each replica read a unique data file
or restart file at the start of the script.
b) specify the filename for the final state as file.% which would
have each replica look for a file in the form file,0, file,1, etc -
this would be similar to (a) except that now the files could
list a subset of atoms that are to be overwritten with new coords
before starting NEB. Thus all the replicas could have the same
config before the neb command, and they would each update
a few atoms before starting NEB.
Do these options satisfy all the various cases you outlined?
A 3rd option would be to enable NEB to run with more
than one proc per replica. This is something we know how
to do; it’s just some work. Hadn’t seemed like a priority b/c
I normally think of NEB as small systems and short runs,
but you have highlighted other use cases. Is that of interest
as well?
Steve
First, thanks a lot for considering the points we raised.
I think your propositions (a) and (b) would be very good ways to offer the possibility to start a NEB calculation with replica provided by the user.
As far as I am concerned, the third point (adding the possibility to run each replica on several processors) would be a very important improvement. My calculations mostly involve the motion of dislocations, and as I said earlier this requires very large sytems. Parallelization of each replica would definitely speed up such NEB calculations by a lot. And as far as I know, LAMMPS would be the first code to propose such a parallelization scheme.
Best regards
One could think of situations where a linear interpolation would not be the best starting path for NEB. An example would be computing the barriers to molecule rotation, in which case if the rotated and initial states differ much, then a linear interpolation would determine a path which inverts the initial molecule through a point to the final state, which can pose huge initial barriers and take a long time to converge to a minimum path.
Anirban
Indeed Anirban observation is correct. Furthermore, if the FF is not one of bonded character but a reactive one one could easily end up with a broken molecule/system if the initial path given to the NEB algorithm is a bit off. One of the issues here is that the gradient in Cartesian coordinates changes abruptly in space which poses extra challenges to any Cartesian NEB implementation. The linear interpolation path as an initial guess to NEB is of very limited applicability.
Carlos