It would be helpful if the Neighbor class included a flag to switch on the computing of neighbors-of-neighbors (NoN) lists. I see that the REBO pair style has something implemented that computes the NoN lists, but there are several calculations that require NoNs so it might make sense to make it publicly available through the appropriate class.
If needed I can write this alteration myself, however I’d like some feedback before I proceed.
Thanks;
-AdamC
I think instead of NoN, you mean having neighbors of ghosts. I agree
this might be a good thing to have in the neighbor routines. Only
a couple of pair styles need this currently, AIREBO and ReaxFF I think.
What are others potentials you are envisioning that would need it?
The issue is that AIREBO and ReaxFF need something different. If you think
about it, neighbors of ghost is a somewhat ill-defined datum, since
clearly some neighbors will be missing.
Steve
Yes, I did mean neighbors of ghosts. I’m actually not writing a new potential but a compute for phonon dispersion curves using the force constant matrix. When taking the 2nd derivative of EAM potentials you end up with a NoN summation.
For atoms that have NoNs outside the ghost atom bounds I planned on just dropping them from the computation. Since there is no way to account for missing atoms like these other than to expand your simulation (which is unreasonable in many cases) they might as well be dropped from the compute.
As an aside; I was under the impression that differentiating a potential before it is computed (differentiating each component and then summing) significantly reduces computational errors. My gut feeling is that it shouldn’t really effect it, can you verify this? It seems like it would be infinitely simpler to compute the phonons using the post-computed potential and interpolating when needed.
-AdamC
So that mean you want neighbors of all ghosts out to the same cutoff
as the neighbors of owned atoms, and just not include the
ones that are missing? I'll look at providing a hook in the neighbor
class for pair styles/computes/etc to request this.
As an aside; I was under the impression that differentiating a potential
before it is computed (differentiating each component and then summing)
significantly reduces computational errors. My gut feeling is that it
shouldn't really effect it, can you verify this?
I don't know what you mean by this. Every potential in LAMMPS
calculates forces this way, as an analytic derivative of the potential,
not as a finite difference. That is more accurate. Even PPPM
in LAMMPS does that, though some codes do smoothed PME
go the finite difference route, which is cheaper but less accurat
(for a given grid size). If you're asking if the same thing would
hold for 2nd derivatives, then probably so. But now the Hessian
is often very ugly to compute analytically, so most people
use differences.
Steve
So that mean you want neighbors of all ghosts out to the same cutoff as the neighbors of owned atoms, and just not include the ones that are missing?
I’ve been re-thinking this. If the simulation is done in a single thread the only ghost atoms that exist are along the outside of the simulation to account for the periodic boundary conditions, correct? If that is the case, it might be for the best to constrict my calculation to running serially to reduce NoN problems.
I’ll look at providing a hook in the neighbor class for pair styles/computes/etc to request this.
Great, thanks.
-AdamC
If you run in parallel, every proc has ghost atoms. For interior
procs, they are just atoms owned by other procs (not near the global
boundaries). But LAMMPS makes no distinction.
Steve
The 18Mar11 patch adds an option to neighbor list
building to calculate neighbors of ghost atoms. The
AIREBO pair style now uses it, so the code for doing
this within AIREBO has been removed. A similar
change will eventually happen for ReaxFF. I don't think
any other pair styles in LAMMPS need this info.
Steve
Steve;
Awesome, thanks for that. I’ll grab the update ASAP.
I also thought I should bring up the conversation we had at the KIM workshop. I’ve been looking into calculating the full 3Nx3N dynamical matrix for use with deriving the phonon dispersion curve, this requires diagonalizing the (sparse) dynamical matrix. Is there a preferred sparse matrix library? I also haven’t quite worked out how i’ll be doing the diagonalization, at the moment I’m hesitant to try to implement a parallel calculation.
You had mentioned that another person was working on a sparse matrix calculation in LAMMPS, has any headway been made on that? Thanks for your help.
-AdamC
I don't recall the other sparse matrix calc for LAMMPS unless
you mean charge equilibration, which is already in pair_style comb
and reaxFF for example. Them implement their own basic solver,
using LAMMPS ghost-atom communication at each iteration.
Re: sparse-matrix solver librarires - there are several. People
at Sandia use Trilinos (google for it), b/c it was written here.
Steve