lammps/examples/COUPLE/lammps_spparks3ba07ca1e613lammm-master-deprecated
lammps_spparks
README
This directory has an application that models grain growth in the presence of strain.
The grain growth is simulated by a Potts model in a kinetic Monte Carlo code SPPARKS. Clusters of like spins on a lattice represent grains. The Hamiltonian for the energy due of a collection of spins includes a strain term and is described on this page in the SPPARKS documentation:
http://spparks.sandia.gov/doc/app_potts_strain.html.
The strain is computed by the molecular dynamics code LAMMPS as a particle displacement where pairs of atoms across a grain boundary are of different types and thus push off from each other due to a Lennard-Jones sigma between particles of different types that is larger than the sigma between particles of the same type (interior to grains).
lmpspk.cpp main program
it links LAMMPS and SPPARKS as libraries
in.spparks SPPARKS input script, without the run command lmppath.h contains path to LAMMPS home directory spkpath.h contains path to SPPARKS home directory
After editing the Makefile, lmppath.h, and spkpath.h to make them suitable for your box, type:
g++ -f Makefile.g++
and you should get the lmpspk executable.
You can run lmpspk in serial or parallel as:
% lmpspk Niter Ndelta Sfactor in.spparks % mpirun -np 4 lmpspk Niter Ndelta Sfactor in.spparks
where
Niter = # of outer iterations Ndelta = time to run MC in each iteration Sfactor = multiplier on strain effect in.spparks = SPPARKS input script
The log files are for this run:
% lmpspk 20 10.0 1 in.spparks
This application is an example of a coupling where the driver code (lmpspk) alternates back and forth between the 2 applications (LAMMPS and SPPARKS). Each outer timestep in the driver code, the following tasks are performed. One code (SPPARKS) is invoked for a few Monte Carlo steps. Some of its output (spin state) is passed to the other code (LAMMPS) as input (atom type). The the other code (LAMMPS) is invoked for a few timesteps. Some of its output (atom coords) is massaged to become an input (per-atom strain) for the original code (SPPARKS).
The driver code launches both SPPARKS and LAMMPS in parallel and they both decompose their spatial domains in the same manner. The datums in SPPARKS (lattice sites) are the same as the datums in LAMMPS (coarse-grained particles). If this were not the case, more sophisticated inter-code communication could be performed.
You can look at the log files in the directory to see sample LAMMPS and SPPARKS output for this simulation. Dump files produced by the run are stored as dump.mc and dump.md. The image*.png files show snapshots from both the LAMMPS and SPPARKS output. Note that the in.lammps and data.lammps files are not inputs; they are generated by the lmpspk driver.