how the hybrid atom style works, internally

I'm trying to understand how "atom_style hybrid" and "create_atoms"
interact, specifically how each atom's "style" is determined when you
add a batch of new atoms using the random call or similar, both from a
conceptual point of view and in detail, to see how I would interact
with this using the library interface.

Conceptually, I can pose my question with an example. If I were to use:

atom_style hybrid sphere ellipsoid

...

create_atoms 1 random 500 1 NULL

what style would my 500 atoms have for interaction purposes? How would
I specify, and/or amend the ones that were wrong?

From the more detailed perspective, I can see from the docs that all

the atoms have the 'union of the attributes' allocated in RAM, which
is perfectly clear - the AtomVector just has all the arrays
initialised for all atoms in them. What I want to know is which
internal property (itype, image, mask, tag?) determines the particular
style for an individual atom/is used to determine how it interacts in
a timestep, etc?

I have tried to find out by reading the source myself, but I'm only
really familiar with C, so some of the type templating magic blocks my
understanding of where to go next (and, incidentally, confuses eclipse
into not indexing most of the classes..)

Thanks,

Joe

I'm trying to understand how "atom_style hybrid" and "create_atoms"
interact, specifically how each atom's "style" is determined when you
add a batch of new atoms using the random call or similar, both from a
conceptual point of view and in detail, to see how I would interact
with this using the library interface.

the situation is simple: the atom style has to be set before
*any* atom is created and cannot be changed later. the
critical point is when the "box" is created, either directly
through create_box or indirectly through read_data or
read_restart.

Conceptually, I can pose my question with an example. If I were to use:

atom_style hybrid sphere ellipsoid

...

create_atoms 1 random 500 1 NULL

what style would my 500 atoms have for interaction purposes? How would
I specify, and/or amend the ones that were wrong?

all atoms always have the same "style". you cannot change it.
"style" only means what properties can be stored with each atoms.
it doesn't have any impact on *how* interactions are computed.

>From the more detailed perspective, I can see from the docs that all
the atoms have the 'union of the attributes' allocated in RAM, which
is perfectly clear - the AtomVector just has all the arrays
initialised for all atoms in them. What I want to know is which
internal property (itype, image, mask, tag?) determines the particular
style for an individual atom/is used to determine how it interacts in
a timestep, etc?

again. neither of these properties determine atom style.
all atoms have the same style. interactions between atom
are determined by their pair (bond,angle,dihedral,improper,
kspace,fix) styles and within a pair style through the selection
of atom types (or bond, angle,... whatever type) and other
relevant per-atom properties (mass, charge, radius, ...).

I have tried to find out by reading the source myself, but I'm only
really familiar with C, so some of the type templating magic blocks my
understanding of where to go next (and, incidentally, confuses eclipse
into not indexing most of the classes..)

using an IDE on a project like LAMMPS and
expecting the IDE to "get it" is asking for too much.
you'll probably be better off with a decent text
editor that knows how to use a TAGS file.

axel.

Thanks for the reply, Axel - that pretty much covers it, but I have
one follow up question.

I've just had a look at the gran/hooke pair style's source code, where
all the important stuff about the interaction is computed (as you
said,) and it appears that it only supports spheres, not ellipsoids.

Is that correct? Does lammps only support granular interactions
between spheres, and not ellipsoids?

Thanks,

Joe

Thanks for the reply, Axel - that pretty much covers it, but I have
one follow up question.

I've just had a look at the gran/hooke pair style's source code, where
all the important stuff about the interaction is computed (as you
said,) and it appears that it only supports spheres, not ellipsoids.

Is that correct? Does lammps only support granular interactions
between spheres, and not ellipsoids?

that is correct.
computing interactions between aspherical objects is
significantly more tricky, particular for DEM calculations.

axel.

To answer my own question here, LAMMPS does support torque
interactions between ellipsoids and spheres, just not in the
'granular' package - look at the 'asphere' package instead, and its
documentation here:

http://lammps.sandia.gov/doc/Section_howto.html#howto_14

Apologies for the redundant questions.

Joe