Merge remote-tracking branch 'lammps-ro/master' into lammps-icms

doc/html/Manual.html

@@ -135,7 +135,7 @@
   <H1></H1><div class="section" id="lammps-icms-documentation">
 <h1>LAMMPS-ICMS Documentation</h1>
 <div class="section" id="aug-2016-version">
-<h2>13 Aug 2016 version</h2>
+<h2>20 Aug 2016 version</h2>
 </div>
 <div class="section" id="version-info">
 <h2>Version info:</h2>

doc/html/_sources/Manual.txt

@@ -5,7 +5,7 @@
 LAMMPS Documentation
 ====================
 
-13 Aug 2016 version
+20 Aug 2016 version
 -------------------
 
 Version info:

doc/html/_sources/dump.txt

@@ -169,6 +169,9 @@ or multiple smaller files).
    Because periodic boundary conditions are enforced only on
    timesteps when neighbor lists are rebuilt, the coordinates of an atom
    written to a dump file may be slightly outside the simulation box.
+   Re-neighbor timesteps will not typically coincide with the timesteps
+   dump snapshots are written.  See the :doc:`dump_modify pbc <dump_modify>` command if you with to force coordinates to be
+   strictly inside the simulation box.
 
 .. note::
 

doc/html/_sources/dump_modify.txt

@@ -36,6 +36,7 @@ Syntax
      *nfile* arg = Nf
        Nf = write this many files, one from each of Nf processors
      *pad* arg = Nchar = # of characters to convert timestep to
+     *pbc* arg = *yes* or *no* = remap atoms via periodic boundary conditions
      *precision* arg = power-of-10 value from 10 to 1000000
      *region* arg = region-ID or "none"
      *scale* arg = *yes* or *no*
@@ -428,6 +429,21 @@ timestep order.
 ----------
 
 
+The *pbc* keyword applies to all the dump styles.  As explained on the
+:doc:`dump <dump>` doc page, atom coordinates in a dump file may be
+slightly outside the simulation box.  This is because periodic
+boundary conditions are enforced only on timesteps when neighbor lists
+are rebuilt, which will not typically coincide with the timesteps dump
+snapshots are written.  If the setting of this keyword is set to
+*yes*\ , then all atoms will be remapped to the periodic box before the
+snapshot is written, then restored to their original position.  If it
+is set to *no* they will not be.  The *no* setting is the default
+because it requires no extra computation.
+
+
+----------
+
+
 The *precision* keyword only applies to the dump *xtc* style.  A
 specified value of N means that coordinates are stored to 1/N
 nanometer accuracy, e.g. for N = 1000, the coordinates are written to
@@ -846,6 +862,7 @@ The option defaults are
 * label = ENTRIES
 * nfile = 1
 * pad = 0
+* pbc = no
 * precision = 1000
 * region = none
 * scale = yes

doc/html/_sources/fix_ave_histo.txt

@@ -145,8 +145,9 @@ length.  The first value (a scalar or vector) is what is histogrammed
 into bins, in the same manner the fix ave/histo command operates.  The
 second value (a scalar or vector) is used as a "weight".  This means
 that instead of each value tallying a "1" to its bin, the
-corresponding weight is tallied.  E.g. the Nth entry in the first
-vector tallies the Nth entry (weight) in the second vector.
+corresponding weight is tallied.  E.g. The Nth entry (weight) in the
+second vector is tallied to the bin corresponding to the Nth entry in
+the first vector.
 
 
 ----------

doc/html/dump.html

@@ -274,7 +274,10 @@ or multiple smaller files).</p>
 <p class="first admonition-title">Note</p>
 <p class="last">Because periodic boundary conditions are enforced only on
 timesteps when neighbor lists are rebuilt, the coordinates of an atom
-written to a dump file may be slightly outside the simulation box.</p>
+written to a dump file may be slightly outside the simulation box.
+Re-neighbor timesteps will not typically coincide with the timesteps
+dump snapshots are written.  See the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify pbc</span></a> command if you with to force coordinates to be
+strictly inside the simulation box.</p>
 </div>
 <div class="admonition note">
 <p class="first admonition-title">Note</p>

doc/html/dump_modify.html

@@ -158,6 +158,7 @@
 <em>nfile</em> arg = Nf
   Nf = write this many files, one from each of Nf processors
 <em>pad</em> arg = Nchar = # of characters to convert timestep to
+<em>pbc</em> arg = <em>yes</em> or <em>no</em> = remap atoms via periodic boundary conditions
 <em>precision</em> arg = power-of-10 value from 10 to 1000000
 <em>region</em> arg = region-ID or &quot;none&quot;
 <em>scale</em> arg = <em>yes</em> or <em>no</em>
@@ -468,6 +469,17 @@ yield 0000100, 0012000, 2000000.  This can be useful so that
 post-processing programs can easily read the files in ascending
 timestep order.</p>
 <hr class="docutils" />
+<p>The <em>pbc</em> keyword applies to all the dump styles.  As explained on the
+<a class="reference internal" href="dump.html"><span class="doc">dump</span></a> doc page, atom coordinates in a dump file may be
+slightly outside the simulation box.  This is because periodic
+boundary conditions are enforced only on timesteps when neighbor lists
+are rebuilt, which will not typically coincide with the timesteps dump
+snapshots are written.  If the setting of this keyword is set to
+<em>yes</em>, then all atoms will be remapped to the periodic box before the
+snapshot is written, then restored to their original position.  If it
+is set to <em>no</em> they will not be.  The <em>no</em> setting is the default
+because it requires no extra computation.</p>
+<hr class="docutils" />
 <p>The <em>precision</em> keyword only applies to the dump <em>xtc</em> style.  A
 specified value of N means that coordinates are stored to 1/N
 nanometer accuracy, e.g. for N = 1000, the coordinates are written to
@@ -790,6 +802,7 @@ images less frequently.</p>
 <li>label = ENTRIES</li>
 <li>nfile = 1</li>
 <li>pad = 0</li>
+<li>pbc = no</li>
 <li>precision = 1000</li>
 <li>region = none</li>
 <li>scale = yes</li>

doc/html/fix_ave_histo.html

@@ -254,8 +254,9 @@ length.  The first value (a scalar or vector) is what is histogrammed
 into bins, in the same manner the fix ave/histo command operates.  The
 second value (a scalar or vector) is used as a “weight”.  This means
 that instead of each value tallying a “1” to its bin, the
-corresponding weight is tallied.  E.g. the Nth entry in the first
-vector tallies the Nth entry (weight) in the second vector.</p>
+corresponding weight is tallied.  E.g. The Nth entry (weight) in the
+second vector is tallied to the bin corresponding to the Nth entry in
+the first vector.</p>
 <hr class="docutils" />
 <p>The <em>Nevery</em>, <em>Nrepeat</em>, and <em>Nfreq</em> arguments specify on what
 timesteps the input values will be used in order to contribute to the