</P>

<P>Define a computation that stores the specified attributes as global

data so it can be accessed by other <A HREF = "Section_howto.html#4_15">output

commands</A>.  If the input attributes refer to

bond information, then the number of datums generated, aggregated

across all processors, equals the number of bonds in the system.

commands</A> and used in conjunction with other

commands that generate per-molecule data, such as <A HREF = "compute_com_molecule.html">compute

com/molecule</A> and <A HREF = "compute_msd_molecule.html">compute

msd/molecule</A>.

</P>

<P>If multiple input attributes are specified then they must all generate

the same amount of information, so that the resulting local array has

the same number of rows for each column.  This means that only bond

attributes can be specified together, or angle attributes, etc.  Bond

and angle attributes can not be mixed in the same compute

property/local command.

</P>

<P>The local data is generated by looping over all the atoms owned on a

processor and extracting bond, angle, etc info.  For bonds, info about

an individual bond will only be included if both atoms in the bond are

in the specified compute group.  Likewise for angles, dihedrals, etc.

</P>

<P>Note that as atoms migrate from processor to processor, there will be

no consistent ordering of the entries within the local vector or array

from one timestep to the next.  The only consistency that is

guaranteed is that the ordering on a particular timestep will be the

same for local vectors or arrays generated by other compute commands.

For example, output from the <A HREF = "compute_bond_local.html">compute

bond/local</A> command can be combined with bond

atom indices from this command and output by the <A HREF = "dump.html">dump

local</A> command in a consistent way.

</P>

<P>The <I>batom1</I> and <I>batom2</I> attributes refer the atom IDs of the 2 atoms

in each <A HREF = "bond_style.html">bond</A>.  The <I>btype</I> attribute refers to the

type of the bond, from 1 to Nbtypes = # of bond types.  The number of

bond types is defined in the data file read by the

<A HREF = "read_data.html">read_data</A> command.  The attributes that start with

"a", "d", "i", refer to similar values for <A HREF = "angle_style.html">angles</A>,

<A HREF = "dihedral_style.html">dihedrals</A>, and <A HREF = "improper_style.html">impropers</A>.

<P>The <I>mol</I> attribute generates a list of molecule IDs in ascending

order for any molecule with one or more of its atoms in the specified

group.  This list and ordering of molecule IDs will be consistent with

the ordering produced by other compute commands that generate

per-molecule datums.  Thus this attribute can be used to produce

molecule IDs as labels for those datums when they are output to a

file, e.g. by the <A HREF = "fix_ave_time.html">fix ave/time</A> command.

</P>

<P><B>Output info:</B>

</P>

Define a computation that stores the specified attributes as global

data so it can be accessed by other "output

commands"_Section_howto.html#4_15.  If the input attributes refer to

bond information, then the number of datums generated, aggregated

across all processors, equals the number of bonds in the system.

If multiple input attributes are specified then they must all generate

the same amount of information, so that the resulting local array has

the same number of rows for each column.  This means that only bond

attributes can be specified together, or angle attributes, etc.  Bond

and angle attributes can not be mixed in the same compute

property/local command.

The local data is generated by looping over all the atoms owned on a

processor and extracting bond, angle, etc info.  For bonds, info about

an individual bond will only be included if both atoms in the bond are

in the specified compute group.  Likewise for angles, dihedrals, etc.

Note that as atoms migrate from processor to processor, there will be

no consistent ordering of the entries within the local vector or array

from one timestep to the next.  The only consistency that is

guaranteed is that the ordering on a particular timestep will be the

same for local vectors or arrays generated by other compute commands.

For example, output from the "compute

bond/local"_compute_bond_local.html command can be combined with bond

atom indices from this command and output by the "dump

local"_dump.html command in a consistent way.

The {batom1} and {batom2} attributes refer the atom IDs of the 2 atoms

in each "bond"_bond_style.html.  The {btype} attribute refers to the

type of the bond, from 1 to Nbtypes = # of bond types.  The number of

bond types is defined in the data file read by the

"read_data"_read_data.html command.  The attributes that start with

"a", "d", "i", refer to similar values for "angles"_angle_style.html,

"dihedrals"_dihedral_style.html, and "impropers"_improper_style.html.

commands"_Section_howto.html#4_15 and used in conjunction with other

commands that generate per-molecule data, such as "compute

com/molecule"_compute_com_molecule.html and "compute

msd/molecule"_compute_msd_molecule.html.

The {mol} attribute generates a list of molecule IDs in ascending

order for any molecule with one or more of its atoms in the specified

group.  This list and ordering of molecule IDs will be consistent with

the ordering produced by other compute commands that generate

per-molecule datums.  Thus this attribute can be used to produce

molecule IDs as labels for those datums when they are output to a

file, e.g. by the "fix ave/time"_fix_ave_time.html command.

[Output info:]