NEB Restart

In-Reply-To : <[email protected]>

I haven't tested this, so we may have to iterate if it doesn't work, but
I think there's a relatively easy work-around that doesn't require
re-encoding the NEB routines. Here's the idea.

LAMMPS treats NEB calculations as partitions, and it doesn't actually pay
attention to whether the partition in question is /actually/ reading the
"product" state, it just grabs its product state from the file you tell
it (which can be different on each partition). The starting configuration
is interpolated between the /current/ configuration and the stated product
configuration. So let's assume that each partition now has the "correct"
starting configuration (say, from a write_data or write_restart command
issued after a previous NEB calculation), and we want the interpolation
that ensues not to change the current positions.

Assuming you're in a UNIX environment (i.e., you have AWK), you can
generate the "product" configuration for each image with something like
this:
   variable mpirank uloop 10000
   dump 1 all custom 1 dump.final.coords.\{mpirank\} id x y z &nbsp;&nbsp;&nbsp;shell &#39;awk &lt; dump\.final\.coords\.{mpirank} > final.coords.\{mpirank\} &quot;&amp; &nbsp;&nbsp;&nbsp;BEGIN \{flag = 0\} ; &amp; &nbsp;&nbsp;&nbsp;\{if \(flag\) \{print\}\} ; &amp; &nbsp;&nbsp;&nbsp;/ITEM: ATOMS/ \{flag = 1\}&quot;&#39; &nbsp;&nbsp;&nbsp;shell rm dump\.final\.coords\.{mpirank}
   min_style fire
   fix 1 all neb 10.0
   neb 1.0E-12 0 100000 50000 100 final.coords.\{mpirank\} &nbsp;&nbsp;&nbsp;write\_restart restart\.lastNEB\.{mpirank}

The thought behind the above is that the starting configuration of each
image is then interpolated between the configuration it's in now and...the
configuration it's in now. :wink: If I'm incorrect about how the starting
configuration is interpolated, then please correct my ignorance.

Note that the second feature request is already available with the
uloop variable, though you would have to create your own product
configurations (in the example above, dump.final.coords.XXX, where XXX is
1, 2, 3, etc., up to the number of NEB images): images left out of
the product image file are left at their starting coordinates.

Actually, now that I think about it, doesn't giving it a BLANK product
file produce the desired behavior? Perhaps I'm incorrect in that the
starting configuration is /broadcast/ from the rank-0 process, so this
won't work?

Let me know how that works.

Karl D. Hammond
University of Tennessee, Knoxville
[email protected]

"You can never know everything, and part of what you know is always
   wrong. A portion of wisdom lies in knowing that. A portion of courage
   lies in going on anyway."
"Nothing ever goes as you expect. Expect nothing, and you will not be
   surprised."