Building new styles to implement magnetic spin dynamics

I'm working on a project to add spin dynamics to LAMMPS using experience gathered
creating a home-grown code. Being new to LAMMPS, I'd like some guidance to make sure
I don't code myself into a corner.

I've successfully constructed new a new atom_style and pair_style based by copying from EAM,
since we will use atom.rho to calculate interactions between the atoms. What I need to do
is extend atom_style to include magnetic moment and local magnetic field. Using the
variables for electric dipoles seems like a logical thing to do. So I can use atom.q and qtom.mu
easily enough. Is there a local electric field variable in atom? I also plan on using atom.torque.

I'm guessing I can get most of the way looking at the existing code for things like allocating
memory and marshaling for communication. Are there any subtleties that trip people up?

Greg Brown
Florida State University / Oak Ridge National Laboratory

There is no per-atom electric field variable in current LAMMPS.

If you are adding an atom style, the thing to think about
is what per-atom variables need to persist from timestep
to timestep and when do they need to be known for ghost
atoms and if so, when do they need to be communicated

(every step, or once per reneighboring).

For example, the rho you mention in EAM is not persistent.

So it is not part of the atom style. Other per-atom quantities

can often be maintained in a fix, and not be part of
an atom style, which make your life easier if you don’t need
to write that code. E.g. see the fix property/atom command.
And you can force communication from pair styles of fixes
with calls to the Comm class.

Steve

One of my collaborators here had suggested that fix style
would also be involved. I'll look into that with an eye
towards persistence.

Issues with ghost particles will also be important. I took a
quick look at comm.h just now. It looks like I should get
a better idea of fixes in particular, and styles in general,
before worrying about ghost atom issues deeply.

Thanks for the pointers. I'm sure I'll be back with more
questions.

Greg

One of my collaborators here had suggested that fix style
would also be involved. I'll look into that with an eye
towards persistence.

Issues with ghost particles will also be important. I took a
quick look at comm.h just now. It looks like I should get
a better idea of fixes in particular, and styles in general,
before worrying about ghost atom issues deeply.

Thanks for the pointers. I'm sure I'll be back with more
questions.

Greg