git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@15164 f3b2605a-c512-4ea7-a41b-209d697bcdaa

This commit is contained in:
sjplimp 2016-06-14 14:16:24 +00:00
parent 863a3d3319
commit 0e719ed2ef
10 changed files with 82 additions and 69 deletions

View File

@ -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>

View File

@ -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.

View File

@ -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
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

View File

@ -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

View File

@ -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&#8217;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&#8217;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">

View File

@ -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

View File

@ -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.

View File

@ -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:]

View File

@ -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