mirror of https://github.com/lammps/lammps.git
git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@15164 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
parent
863a3d3319
commit
0e719ed2ef
|
@ -580,10 +580,14 @@ installed. To build LAMMPS with optional packages, see <a class="reference inte
|
|||
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
|
||||
to do from the src directory is type something like this:</p>
|
||||
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">make</span> <span class="n">foo</span>
|
||||
<span class="ow">or</span>
|
||||
<span class="n">make</span> <span class="o">-</span><span class="n">j</span> <span class="n">N</span> <span class="n">foo</span>
|
||||
<span class="n">gmake</span> <span class="n">foo</span>
|
||||
<span class="n">gmake</span> <span class="o">-</span><span class="n">j</span> <span class="n">N</span> <span class="n">foo</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The -j or -j N switches perform a parallel build which can be much
|
||||
faster, depending on how many cores your compilation machine has. N
|
||||
is the number of cores the build runs on.</p>
|
||||
<p>You should get the executable lmp_foo when the build is complete.</p>
|
||||
<hr class="docutils" />
|
||||
<p id="start-2-3"><a href="#id7"><span class="problematic" id="id8">**</span></a><em>Errors that can occur when making LAMMPS:</em>**</p>
|
||||
|
|
|
@ -517,8 +517,13 @@ to do from the src directory is type something like this:
|
|||
.. parsed-literal::
|
||||
|
||||
make foo
|
||||
or
|
||||
make -j N foo
|
||||
gmake foo
|
||||
gmake -j N foo
|
||||
|
||||
The -j or -j N switches perform a parallel build which can be much
|
||||
faster, depending on how many cores your compilation machine has. N
|
||||
is the number of cores the build runs on.
|
||||
|
||||
You should get the executable lmp_foo when the build is complete.
|
||||
|
||||
|
|
|
@ -84,15 +84,15 @@ velocities with zero aggregate linear and/or angular momentum.
|
|||
If you use this fix on a small group of atoms (e.g. a molecule
|
||||
in solvent) without using the *shift* keyword to adjust the positions
|
||||
of all atoms in the system, then the results can be unpredictable.
|
||||
For example, if the molecule is pushed in one direction by the
|
||||
solvent, its velocity will increase. But its coordinates will be
|
||||
recentered, meaning it is pushed back towards the force. Thus over
|
||||
time, the velocity and temperature of the molecule could become very
|
||||
large (though it won't appear to be moving due to the recentering).
|
||||
If you are thermostatting the entire system, then the solvent would be
|
||||
cooled to compensate. A better solution for this simulation scenario
|
||||
is to use the :doc:`fix spring <fix_spring>` command to tether the
|
||||
molecule in place.
|
||||
For example, if the molecule is pushed consistently in one direction
|
||||
by a flowing solvent, its velocity will increase. But its coordinates
|
||||
will be recentered, meaning it is moved back towards the force. Thus
|
||||
over time, the velocity and effective temperature of the molecule
|
||||
could become very large, though it won't actually be moving due to the
|
||||
recentering. If you are thermostatting the entire system, then the
|
||||
solvent would be cooled to compensate. A better solution for this
|
||||
simulation scenario is to use the :doc:`fix spring <fix_spring>` command
|
||||
to tether the molecule in place.
|
||||
|
||||
Restart, fix_modify, output, run start/stop, minimize info
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
|
|
@ -177,17 +177,17 @@ interactions. The use of fixed boundaries in z means that the user
|
|||
must prevent particle migration beyond the initial z-bounds, typically
|
||||
by providing a wall-style fix. The methodology behind the *slab*
|
||||
option is explained in the paper by :ref:`(Yeh) <Yeh>`. The *slab* option
|
||||
is also extended to non-neutral systems
|
||||
:ref:`(Ballenegger) <Ballenegger>`. An alternative slab option can be
|
||||
invoked with the *nozforce* keyword in lieu of the volfactor. This
|
||||
turns off all kspace forces in the z direction. The *nozforce* option
|
||||
is not supported by MSM. For MSM, any combination of periodic,
|
||||
non-periodic, or shrink-wrapped boundaries can be set using
|
||||
:doc:`boundary <boundary>` (the slab approximation in not needed). The
|
||||
*slab* keyword is not currently supported by Ewald or PPPM when using
|
||||
a triclinic simulation cell. The slab correction has also been
|
||||
extended to point dipole interactions :ref:`(Klapp) <Klapp>` in
|
||||
:doc:`kspace_style <kspace_style>` *ewald/disp*\ .
|
||||
is also extended to non-neutral systems :ref:`(Ballenegger) <Ballenegger>`.
|
||||
|
||||
An alternative slab option can be invoked with the *nozforce* keyword
|
||||
in lieu of the volfactor. This turns off all kspace forces in the z
|
||||
direction. The *nozforce* option is not supported by MSM. For MSM,
|
||||
any combination of periodic, non-periodic, or shrink-wrapped
|
||||
boundaries can be set using :doc:`boundary <boundary>` (the slab
|
||||
approximation in not needed). The *slab* keyword is not currently
|
||||
supported by Ewald or PPPM when using a triclinic simulation cell. The
|
||||
slab correction has also been extended to point dipole interactions
|
||||
:ref:`(Klapp) <Klapp>` in :doc:`kspace_style <kspace_style>` *ewald/disp*\ .
|
||||
|
||||
The *compute* keyword allows Kspace computations to be turned off,
|
||||
even though a :doc:`kspace_style <kspace_style>` is defined. This is
|
||||
|
|
|
@ -198,15 +198,15 @@ warn you if your fixes are not ordered this way.</p>
|
|||
<p class="last">If you use this fix on a small group of atoms (e.g. a molecule
|
||||
in solvent) without using the <em>shift</em> keyword to adjust the positions
|
||||
of all atoms in the system, then the results can be unpredictable.
|
||||
For example, if the molecule is pushed in one direction by the
|
||||
solvent, its velocity will increase. But its coordinates will be
|
||||
recentered, meaning it is pushed back towards the force. Thus over
|
||||
time, the velocity and temperature of the molecule could become very
|
||||
large (though it won’t appear to be moving due to the recentering).
|
||||
If you are thermostatting the entire system, then the solvent would be
|
||||
cooled to compensate. A better solution for this simulation scenario
|
||||
is to use the <a class="reference internal" href="fix_spring.html"><span class="doc">fix spring</span></a> command to tether the
|
||||
molecule in place.</p>
|
||||
For example, if the molecule is pushed consistently in one direction
|
||||
by a flowing solvent, its velocity will increase. But its coordinates
|
||||
will be recentered, meaning it is moved back towards the force. Thus
|
||||
over time, the velocity and effective temperature of the molecule
|
||||
could become very large, though it won’t actually be moving due to the
|
||||
recentering. If you are thermostatting the entire system, then the
|
||||
solvent would be cooled to compensate. A better solution for this
|
||||
simulation scenario is to use the <a class="reference internal" href="fix_spring.html"><span class="doc">fix spring</span></a> command
|
||||
to tether the molecule in place.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="restart-fix-modify-output-run-start-stop-minimize-info">
|
||||
|
|
|
@ -285,17 +285,16 @@ interactions. The use of fixed boundaries in z means that the user
|
|||
must prevent particle migration beyond the initial z-bounds, typically
|
||||
by providing a wall-style fix. The methodology behind the <em>slab</em>
|
||||
option is explained in the paper by <a class="reference internal" href="#yeh"><span class="std std-ref">(Yeh)</span></a>. The <em>slab</em> option
|
||||
is also extended to non-neutral systems
|
||||
<a class="reference internal" href="#ballenegger"><span class="std std-ref">(Ballenegger)</span></a>. An alternative slab option can be
|
||||
invoked with the <em>nozforce</em> keyword in lieu of the volfactor. This
|
||||
turns off all kspace forces in the z direction. The <em>nozforce</em> option
|
||||
is not supported by MSM. For MSM, any combination of periodic,
|
||||
non-periodic, or shrink-wrapped boundaries can be set using
|
||||
<a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> (the slab approximation in not needed). The
|
||||
<em>slab</em> keyword is not currently supported by Ewald or PPPM when using
|
||||
a triclinic simulation cell. The slab correction has also been
|
||||
extended to point dipole interactions <a class="reference internal" href="#klapp"><span class="std std-ref">(Klapp)</span></a> in
|
||||
<a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> <em>ewald/disp</em>.</p>
|
||||
is also extended to non-neutral systems <a class="reference internal" href="#ballenegger"><span class="std std-ref">(Ballenegger)</span></a>.</p>
|
||||
<p>An alternative slab option can be invoked with the <em>nozforce</em> keyword
|
||||
in lieu of the volfactor. This turns off all kspace forces in the z
|
||||
direction. The <em>nozforce</em> option is not supported by MSM. For MSM,
|
||||
any combination of periodic, non-periodic, or shrink-wrapped
|
||||
boundaries can be set using <a class="reference internal" href="boundary.html"><span class="doc">boundary</span></a> (the slab
|
||||
approximation in not needed). The <em>slab</em> keyword is not currently
|
||||
supported by Ewald or PPPM when using a triclinic simulation cell. The
|
||||
slab correction has also been extended to point dipole interactions
|
||||
<a class="reference internal" href="#klapp"><span class="std std-ref">(Klapp)</span></a> in <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> <em>ewald/disp</em>.</p>
|
||||
<p>The <em>compute</em> keyword allows Kspace computations to be turned off,
|
||||
even though a <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> is defined. This is
|
||||
not useful for running a real simulation, but can be useful for
|
||||
|
@ -310,7 +309,7 @@ beginning of the run to give the desired estimated error. Other
|
|||
cutoffs such as LJ will not be affected. If the grid is not set using
|
||||
the <em>mesh</em> command, this command will also attempt to use the optimal
|
||||
grid that minimizes cost using an estimate given by
|
||||
<a class="reference internal" href="kspace_style.html#hardy"><span class="std std-ref">(Hardy)</span></a>. Note that this cost estimate is not exact, somewhat
|
||||
<a class="reference internal" href="#hardy"><span class="std std-ref">(Hardy)</span></a>. Note that this cost estimate is not exact, somewhat
|
||||
experimental, and still may not yield the optimal parameters.</p>
|
||||
<p>The <em>pressure/scalar</em> keyword applies only to MSM. If this option is
|
||||
turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
|
||||
|
@ -335,7 +334,7 @@ collective operations and adequate hardware.</p>
|
|||
<p>The <em>diff</em> keyword specifies the differentiation scheme used by the
|
||||
PPPM method to compute forces on particles given electrostatic
|
||||
potentials on the PPPM mesh. The <em>ik</em> approach is the default for
|
||||
PPPM and is the original formulation used in <a class="reference internal" href="kspace_style.html#hockney"><span class="std std-ref">(Hockney)</span></a>. It
|
||||
PPPM and is the original formulation used in <a class="reference internal" href="#hockney"><span class="std std-ref">(Hockney)</span></a>. It
|
||||
performs differentiation in Kspace, and uses 3 FFTs to transfer each
|
||||
component of the computed fields back to real space for total of 4
|
||||
FFTs per timestep.</p>
|
||||
|
@ -370,7 +369,7 @@ speed-up the simulations but introduces some error in the force
|
|||
computations, as shown in <a class="reference internal" href="#wennberg"><span class="std std-ref">(Wennberg)</span></a>. With <em>none</em>, it is
|
||||
assumed that no mixing rule is applicable. Splitting of the dispersion
|
||||
coefficients will be performed as described in
|
||||
<a class="reference internal" href="kspace_style.html#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>. This splitting can be influenced with
|
||||
<a class="reference internal" href="#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>. This splitting can be influenced with
|
||||
the <em>splittol</em> keywords. Only the eigenvalues that are larger than tol
|
||||
compared to the largest eigenvalues are included. Using this keywords
|
||||
the original matrix of dispersion coefficients is approximated. This
|
||||
|
@ -378,7 +377,7 @@ leads to faster computations, but the accuracy in the reciprocal space
|
|||
computations of the dispersion part is decreased.</p>
|
||||
<p>The <em>force/disp/real</em> and <em>force/disp/kspace</em> keywords set the force
|
||||
accuracy for the real and space computations for the dispersion part
|
||||
of pppm/disp. As shown in <a class="reference internal" href="kspace_style.html#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>, optimal
|
||||
of pppm/disp. As shown in <a class="reference internal" href="#isele-holder"><span class="std std-ref">(Isele-Holder)</span></a>, optimal
|
||||
performance and accuracy in the results is obtained when these values
|
||||
are different.</p>
|
||||
<p>The <em>disp/auto</em> option controlls whether the pppm/disp is allowed to
|
||||
|
|
File diff suppressed because one or more lines are too long
|
@ -485,8 +485,13 @@ pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
|
|||
to do from the src directory is type something like this:
|
||||
|
||||
make foo
|
||||
or
|
||||
gmake foo :pre
|
||||
make -j N foo
|
||||
gmake foo
|
||||
gmake -j N foo :pre
|
||||
|
||||
The -j or -j N switches perform a parallel build which can be much
|
||||
faster, depending on how many cores your compilation machine has. N
|
||||
is the number of cores the build runs on.
|
||||
|
||||
You should get the executable lmp_foo when the build is complete.
|
||||
|
||||
|
|
|
@ -77,15 +77,15 @@ warn you if your fixes are not ordered this way.
|
|||
NOTE: If you use this fix on a small group of atoms (e.g. a molecule
|
||||
in solvent) without using the {shift} keyword to adjust the positions
|
||||
of all atoms in the system, then the results can be unpredictable.
|
||||
For example, if the molecule is pushed in one direction by the
|
||||
solvent, its velocity will increase. But its coordinates will be
|
||||
recentered, meaning it is pushed back towards the force. Thus over
|
||||
time, the velocity and temperature of the molecule could become very
|
||||
large (though it won't appear to be moving due to the recentering).
|
||||
If you are thermostatting the entire system, then the solvent would be
|
||||
cooled to compensate. A better solution for this simulation scenario
|
||||
is to use the "fix spring"_fix_spring.html command to tether the
|
||||
molecule in place.
|
||||
For example, if the molecule is pushed consistently in one direction
|
||||
by a flowing solvent, its velocity will increase. But its coordinates
|
||||
will be recentered, meaning it is moved back towards the force. Thus
|
||||
over time, the velocity and effective temperature of the molecule
|
||||
could become very large, though it won't actually be moving due to the
|
||||
recentering. If you are thermostatting the entire system, then the
|
||||
solvent would be cooled to compensate. A better solution for this
|
||||
simulation scenario is to use the "fix spring"_fix_spring.html command
|
||||
to tether the molecule in place.
|
||||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
|
|
|
@ -172,17 +172,17 @@ interactions. The use of fixed boundaries in z means that the user
|
|||
must prevent particle migration beyond the initial z-bounds, typically
|
||||
by providing a wall-style fix. The methodology behind the {slab}
|
||||
option is explained in the paper by "(Yeh)"_#Yeh. The {slab} option
|
||||
is also extended to non-neutral systems
|
||||
"(Ballenegger)"_#Ballenegger. An alternative slab option can be
|
||||
invoked with the {nozforce} keyword in lieu of the volfactor. This
|
||||
turns off all kspace forces in the z direction. The {nozforce} option
|
||||
is not supported by MSM. For MSM, any combination of periodic,
|
||||
non-periodic, or shrink-wrapped boundaries can be set using
|
||||
"boundary"_boundary.html (the slab approximation in not needed). The
|
||||
{slab} keyword is not currently supported by Ewald or PPPM when using
|
||||
a triclinic simulation cell. The slab correction has also been
|
||||
extended to point dipole interactions "(Klapp)"_#Klapp in
|
||||
"kspace_style"_kspace_style.html {ewald/disp}.
|
||||
is also extended to non-neutral systems "(Ballenegger)"_#Ballenegger.
|
||||
|
||||
An alternative slab option can be invoked with the {nozforce} keyword
|
||||
in lieu of the volfactor. This turns off all kspace forces in the z
|
||||
direction. The {nozforce} option is not supported by MSM. For MSM,
|
||||
any combination of periodic, non-periodic, or shrink-wrapped
|
||||
boundaries can be set using "boundary"_boundary.html (the slab
|
||||
approximation in not needed). The {slab} keyword is not currently
|
||||
supported by Ewald or PPPM when using a triclinic simulation cell. The
|
||||
slab correction has also been extended to point dipole interactions
|
||||
"(Klapp)"_#Klapp in "kspace_style"_kspace_style.html {ewald/disp}.
|
||||
|
||||
The {compute} keyword allows Kspace computations to be turned off,
|
||||
even though a "kspace_style"_kspace_style.html is defined. This is
|
||||
|
|
Loading…
Reference in New Issue