Update list-maintainers to output redmine syntax

[hoomd-blue.git] / doc / user / xml_file_format.doc

/*
Highly Optimized Object-oriented Many-particle Dynamics -- Blue Edition
(HOOMD-blue) Open Source Software License Copyright 2008-2011 Ames Laboratory
Iowa State University and The Regents of the University of Michigan All rights
reserved.

HOOMD-blue may contain modifications ("Contributions") provided, and to which
copyright is held, by various Contributors who have granted The Regents of the
University of Michigan the right to modify and/or distribute such Contributions.

You may redistribute, use, and create derivate works of HOOMD-blue, in source
and binary forms, provided you abide by the following conditions:

* Redistributions of source code must retain the above copyright notice, this
list of conditions, and the following disclaimer both in the code and
prominently in any materials provided with the distribution.

* Redistributions in binary form must reproduce the above copyright notice, this
list of conditions, and the following disclaimer in the documentation and/or
other materials provided with the distribution.

* All publications and presentations based on HOOMD-blue, including any reports
or published results obtained, in whole or in part, with HOOMD-blue, will
acknowledge its use according to the terms posted at the time of submission on:
http://codeblue.umich.edu/hoomd-blue/citations.html

* Any electronic documents citing HOOMD-Blue will link to the HOOMD-Blue website:
http://codeblue.umich.edu/hoomd-blue/

* Apart from the above required attributions, neither the name of the copyright
holder nor the names of HOOMD-blue's contributors may be used to endorse or
promote products derived from this software without specific prior written
permission.

Disclaimer

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND/OR ANY
WARRANTIES THAT THIS SOFTWARE IS FREE OF INFRINGEMENT ARE DISCLAIMED.

IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

/*! \page page_xml_file_format XML File Format
<center><b>Version 1.4</b></center>

\section sec_xml_overview Overview

Both \link hoomd_script.init.read_xml init.read_xml\endlink and \link hoomd_script.dump.xml dump.xml\endlink
work with the same XML file format for specifying the system of particles. The format requires a minimal 
amount of meta-information in an easy to understand human-readable format. One of the key advantages of using 
XML is that it is also easily machine readable and commonly used, so many parsers exist for it.

The basic outline of a HOOMD-blue xml file looks like this
\code
<?xml version="1.0" encoding="UTF-8"?>
<hoomd_xml version="1.4">
<!-- this is a comment, you can put as many of these in the file 
        wherever you wish to. -->
<configuration time_step="0">
        <!-- data nodes go here -->
</configuration>
</hoomd_xml>
\endcode

The first line of the file
\code
<?xml version="1.0" encoding="UTF-8"?>
\endcode
is just something that \b must be there to identify that this is an XML file.

\code
<hoomd_xml version="1.4">
        <!-- contents of root node -->
</hoomd_xml>
\endcode

The second and last lines signify the start and end of the root node \c hoomd_xml. 
The contents of the root node are between these begin and end markers. The version="1.0"
attribute specifies the version of the xml file format used when writing this file.
Files with the same major version are fully backward and partially forward compatible 
with each other, i.e. a version 1.3 reader should be able to read a version 1.1 
file without a problem and use it for as long as the simulation requires no node 
that was introduced in a later version and is thus not available. A version 1.0
reader will skip nodes that were not available at that time.

Inside the root node is the configuration node.
\code
<configuration time_step="0" dimensions="3" vizsigma="1.5">
        <!-- data nodes go here -->
</configuration>
\endcode
\c time_step="0" is an attribute assigned to the configuration node. You can leave if off if you want
and the time step will default to 0. It is used as the initial time step in the simulation when read
by \link hoomd_script.init.read_xml init.read_xml\endlink. In files written by hoomd, \c time_step 
will be set to the value of the time step when the system snapshot was taken.

(Version 1.2 and newer)<br>
\c dimensions="#" specifies the dimensionality of the system. Valid values are 2 and 3, the
default is 3 when \c dimensions is not specified. Setting dimensions="2" does \b NOT change anything else in the file.
For example, you still must specify 3 components for position, velocity, et cetera, just set the 3rd component to 0
for 2D simulations. Specify a small, but non-zero z-dimension for the box when specifying \c dimensions="2".

(Version 1.4 and newer)<br>
\c vizsigma="#" specifies a scaling factor for the radius of particles. It is used by VMD when no \c diameter node
is present. It is ignored when read by \link hoomd_script.init.read_xml init.read_xml\endlink .

<b>A note on case-sensitivity:</b> 
 - All node names and attributes are in all lower case. As XML is a case
        sensitive file format, all readers and writers must adhere to this. However, \link hoomd_script.init.read_xml init.read_xml\endlink
        will try to be generous and handle any possible typos that a user makes on entering data and will accept
        files with varying cases.
 - The \b content of any node is of course case sensitive.

A number of data nodes can be included inside the configuration node <b>in any order</b>.

 - \b box (\ref sec_xml_box)
 - \b position (\ref sec_xml_position)
 - \b image (\ref sec_xml_image)
 - \b velocity (\ref sec_xml_velocity)
 - \b acceleration (\ref sec_xml_acceleration)
 - \b mass (\ref sec_xml_mass)
 - \b diameter (\ref sec_xml_diameter)
 - \b charge (\ref sec_xml_charge)
 - \b type (\ref sec_xml_type)
 - \b body (\ref sec_xml_body)
 - \b orientation (\ref sec_xml_orientation)
 - \b moment_inertia (\ref sec_xml_moment_inertia)
 - \b bond (\ref sec_xml_bond)
 - \b angle (\ref sec_xml_angle)
 - \b dihedral (\ref sec_xml_dihedral)
 - \b improper (\ref sec_xml_improper)
 - \b wall (\ref sec_xml_wall)
 
Detailed documentation for each node is below.
<hr>

\section sec_xml_box Simulation box specification
The \<box\> node defines the dimensions of the simulation box which particles are placed in.<br>
\link hoomd_script.dump.xml dump.xml\endlink \b always writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink \b requires this node be specified.<br>
Version: 1.0 and newer

\b Example:
\code
<box lx="5.1" ly="9.6" lz="15.8"/>
\endcode
\b Attributes:
 - \a lx Box length in the \b x direction
 - \a ly Box length in the \b y direction
 - \a lz Box length in the \b z direction

<hr>

\section sec_xml_position Particle positions
The \<position\> node sets the position of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink \b requires this node be specified.<br>
Version: 1.0 and newer

\b Example:
\code
<position>
-1.45 2.21 1.56
8.76 1.02 5.60
5.67 8.30 4.67
</position>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

In between the begin and end markers \<position\> and \</position\> is a series of floating point
numbers in plain-text separated by whitespace. These are read in order <i>x0 y0 z0 x1 y1 z1 x2 
y2 z2 ... x(N-1) y(N-1) z(N-1)</i>. Note that you do not need to specify the number of particles
anywhere, just add as many as you want and \link hoomd_script.init.read_xml init.read_xml\endlink
will count them. The particular form of the whitespace used does not matter (space, tab, newline,
etc...), the example above uses spaces between \em x, \em y, and \em z and newlines between 
particles merely to make it more easily human-readable.

<b>A note on counting</b>
 - All particles in the simulation can be referenced by a \a tag. \<position\> (and all other XML nodes that list
 per-particle properties) list particles in <b>tag order</b>. That is, the first particle listed has tag 0, the
 second has tag 1, ..., and the last has tag <i>N</i>-1 where \a N is the number of particles in the simulation.

All particles must be in the box: \a x \> -Lx/2.0 and \a x \< Lx/2.0 and similarly for \a y and \a z.

<hr>

\section sec_xml_image Particle images
The \<image\> node sets the box image for each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node.<br>
Version: 1.0 and newer<br>
When used in an input file, the images specified are used as the initial condition for the simulation.

\b Example:
\code
<image>
-1 -5 12
18 2 -10
13 -5 0
</image>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is the same as for \<position\> (see \ref sec_xml_position), except that the 
values must be integers. If specifying both position and image in an input file, be certain to include the 
same number of particles in each, or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an 
error.

Image flags are used to track the movement of particles across the periodic boundary conditions. To unwrap
the position of a single particle and see its trajectory as if it did not wrap around the boundary, 
compute \code x + ix * Lx\endcode where \c x is the particle coordinate, \c ix is the image and \c Lx is the
box dimension.

<hr>

\section sec_xml_velocity Particle velocities
The \<velocity\> node sets the velocity of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node.<br>
Version: 1.0 and newer<br>
When used in an input file, the velocities specified are used as the initial condition for the simulation.

\b Example:
\code
<velocity>
-0.5 -1.2 0.4
0.6 2.0 0.01
-0.4 3.0 0.0
</velocity>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is the same as for \<position\> (see \ref sec_xml_position). If specifying
both position and velocity in an input file, be certain to include the same number of particles in each,
or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an error.

<hr>

\section sec_xml_acceleration Particle accelerations
The \<accelleration\> node indicates the instantaneous acceleration of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink \b ignores this node - acceleration is a computed quantity.<br>
Version: 1.2 and newer<br>

The format of the node data is the same as for \<position\> (see \ref sec_xml_position).

<hr>

\section sec_xml_mass Particle masses
The \<mass\> node sets the mass of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node (all masses default to 1.0 if it is not specified).<br>
Version: 1.0 and newer

\b Example:
\code
<mass>
1.0
2.0
1.0
</mass>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is the same as for \<position\> (see \ref sec_xml_position), except that only one value
per particle is specified.

<hr>

\section sec_xml_diameter Particle diameters
The \<diameter\> node sets the diameter of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node (all diameters default to 1.0 if it is not specified).<br>
Version: 1.0 and newer

\b Example:
\code
<diameter>
1.0
2.0
1.0
</diameter>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is the same as for \<position\> (see \ref sec_xml_position), except that only one value
per particle is specified.

<hr>

\section sec_xml_charge Particle charges
The \<charge\> node sets the charge of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node (all charges default to 0.0 if it is not specified).<br>
Version: 1.3 and newer

\b Example:
\code
<charge>
1.0
2.0
-3.0
</charge>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
    \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is the same as for \<position\> (see \ref sec_xml_position), except that only one value
per particle is specified.

<hr>

\section sec_xml_type Particle types
The \<type\> node sets the type name of each particle in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink \b requires this node be specified.<br>
Version: 1.0 and newer

\b Example:
\code
<type>
A
long_type_name
A
</type>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is similar to that of \<position\> (see \ref sec_xml_position),
except that only one type is specified for each particle. A particle type can be \b any
string you want that does not include whitespace (as whitespace is used to signify
the next particle in the list). Internally, hoomd assigns no meaning whatsoever to the 
value of the string you specify so name your particles in ways that are meaningful to you.
When performing tasks such as setting the coefficients of a \link hoomd_script.pair pair\endlink 
force, the type strings given are simply matched up to those specified in the xml file.

If specifying both position and type in an input file, be certain to include the same number of
particles in each, or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an error.

<hr>

\section sec_xml_body Rigid body assignments
The \<body\> node specifies the rigid body (if any) in which each particles belongs.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.4 and newer

\b Example:
\code
<body>
-1
0
0
</body>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is similar to that of \<position\> (see \ref sec_xml_position),
except that only one integer is specified for each particle. Set a value of -1 for those particles that are not part
of any rigid body. For all of the particles contained within each rigid body, set the same integer value for each
of them. The value assigned also serves as the index of the rigid body in an array, so all rigid bodies must be numberd
from 0 up to the number of rigid bodies minus one.

When specifying both position and body in an input file, be certain to include the same number of
particles in each, or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an error.

<hr>

\section sec_xml_orientation Particle orientation
The \<orientation\> node specifies the orientation of each particle as a quaternion.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.4 and newer

\b Example:
\code
<orientation>
1 0 0 0
0.0333   -0.0667    0.1000    0.1333
</orientation>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is similar to that of \<position\> (see \ref sec_xml_position),
except that four scalar values are specified for each particle. Each group of four values represents a quaternion,
where (1 0 0 0) is the unit quaternion.

When specifying both position and orientation in an input file, be certain to include the same number of
particles in each, or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an error.

\section sec_xml_moment_inertia Particle moment of inertia
The \<moment_inertia\> node specifies the moment of inertia of each particle as a tensor.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.4 and newer

\b Example:
\code
<moment_inertia>
1 0 0 2 0 3
1 2 3 4 5 6
</moment_inertia>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The format of the node data is similar to that of \<position\> (see \ref sec_xml_position),
except that only six scalar values are specified for each particle. Each group of six values represents a moment
of inertia tensor elements (in order) \f$I_{xx}\f$ \f$I_{xy}\f$ \f$I_{xz}\f$ \f$I_{yy}\f$ \f$I_{yz}\f$ \f$I_{zz}\f$.

When specifying both position and moment_inertia in an input file, be certain to include the same number of
particles in each, or \link hoomd_script.init.read_xml init.read_xml\endlink will generate an error.


<hr>

\section sec_xml_bond Bonds between particles

The \<bond\> node specifies any number of bonds between particles in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.0 and newer

Example:
\code
<bond>
polymer 0 1
backbone 1 2
</bond>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The above example creates a bond of type \em polymer between particle 0 and 1 and one of type
\em backbone between 1 and 2. The general format is <i>type0 idx_a0 idx_b0 type1 idx_a1 idx_b1 ....</i>
where type is any string without whitespace, idx_a is the index of the first particle in the bond and
idx_b is the index of the second particle in the bond. Each field is separated from the next by
whitespace (any number of spaces, tabs, or newlines). 

Specifying the bonds themselves doesn't result in any additional forces on particles. For
that, you must specify a bond force (see \link hoomd_script.bond bond\endlink).

A typical usage would list many bonds of the same type. Coefficients for the associated bond
force can be set separately for each bond type by name (for example, see \link hoomd_script.bond.harmonic
bond.harmonic\endlink).

<hr>
\section sec_xml_angle Angles between three particles

The \<angle\> node specifies any number of angles between particles in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.1 and newer

Example:
\code
<angle>
A-B-A 0 1 2
B-A-A 1 2 3
</angle>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The above example creates a angle of type \em A-B-A between particles 0, 1, and 2 and one of type
\em B-A-A between particles 1, 2, and 3. The general format is <i>type0 idx_a0 idx_b0 idx_c0 type1 idx_a1 idx_b1 idx_c1....</i>
where type is any string without whitespace, idx_a is the index of the first particle in the angle,
idx_b is the index of the middle particle in the angle, and idx_c the index of the third particle of the angle. 
Each field is separated from the next by whitespace (any number of spaces, tabs, or newlines). 

Specifying the angles themselves doesn't result in any additional forces on particles. For
that, you must specify a angle force (see \link hoomd_script.angle angle\endlink).

A typical usage would list many angles of the same type. Coefficients for the associated angle
force can be set separately for each angle type by name (for example, see \link hoomd_script.angle.harmonic
angle.harmonic\endlink).

<hr>
\section sec_xml_dihedral Dihedral Angles between four particles

The \<dihedral\> node specifies any number of dihedrals between particles in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.1 and newer

Example:
\code
<dihedral>
A-B-A-A 0 1 2 3
B-A-A-C 1 2 3 4
</dihedral>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The above example creates a dihedral of type \em A-B-A-A between particles 0, 1, 2, and 3 and one of type
\em B-A-A-C between particles 1, 2, 3, and 4. The general format is <i>type0 idx_a0 idx_b0 idx_c0 idx_d0 type1 idx_a1 idx_b1 idx_c1 idx_d1....</i>
where type is any string without whitespace, idx_a is the index of the first particle in the dihedral,
idx_b and idx_c are the indices of the bond around which the dihedral is considered, and idx_d the index of the last particle of the dihedral. 
Each field is separated from the next by whitespace (any number of spaces, tabs, or newlines). 

Specifying the dihedrals themselves doesn't result in any additional forces on particles. For
that, you must specify a dihedral force (see \link hoomd_script.dihedral dihedral\endlink).

A typical usage would list many dihedrals of the same type. Coefficients for the associated dihedral
force can be set separately for each dihedral type by name (for example, see \link hoomd_script.dihedral.harmonic
dihedral.harmonic\endlink).

<hr>
\section sec_xml_improper Improper Dihedral Angles between four particles

The \<improper\> node specifies any number of improper dihedrals between particles in the simulation.<br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.1 and newer

Example:
\code
<improper>
A-B-A-A 0 1 2 3
B-A-A-C 1 2 3 4
</improper>
\endcode
\b Attributes:
 - \a num (\b optional) number of particles coming in the node content. This attribute is written by
        \link hoomd_script.dump.xml dump.xml\endlink to potentially aid in making parsers easier to write.

The above example creates an improper dihedral of type \em A-B-A-A between particles 0, 1, 2, and 3 and one of type
\em B-A-A-C between particles 1, 2, 3, and 4. The general format is <i>type0 idx_a0 idx_b0 idx_c0 idx_d0 type1 idx_a1 idx_b1 idx_c1 idx_d1....</i>
where type is any string without whitespace, idx_a is the index of the first particle in the improper dihedral,
idx_b and idx_c are the indices of the bond around which the improper dihedral is considered, and idx_d the index 
of the last particle of the dihedral. Each field is separated from the next by whitespace (any number of spaces, 
tabs, or newlines).

Specifying the improper dihedrals themselves doesn't result in any additional forces on particles. For
that, you must specify an improper force (see \link hoomd_script.improper improper\endlink).

A typical usage would list many improper dihedrals of the same type. Coefficients for the associated improper
force can be set separately for each improper type by name (for example, see \link hoomd_script.improper.harmonic
improper.harmonic\endlink).

<hr>

\section sec_xml_wall Walls in the simulation box

The \<wall\> node specifies any number of walls in the simulation box. Walls have no
meaning unless a wall force such as \link hoomd_script.wall.lj wall.lj\endlink is specified 
in the simulation. <br>
\link hoomd_script.dump.xml dump.xml\endlink \em optionally writes this node.<br>
\link hoomd_script.init.read_xml init.read_xml\endlink does not require this node<br>
Version: 1.0 and newer

Example:
\code
<wall>
<coord ox="1.0" oy="2.0" oz="3.0" nx="4.0" ny="5.0" nz="6.0"/>
<coord ox="7.0" oy="8.0" oz="9.0" nx="10.0" ny="11.0" nz="-12.0"/>
</wall>
\endcode

Every wall is specified by a plane. The vector (\em ox, \em oy, \em oz) is the origin, a point
in the plane and (\em nx, \em ny, \em nz) is the normal.

*/