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

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
+corresponding weight is tallied.  E.g. The Nth entry (weight) in the
-vector tallies the Nth entry (weight) in the second vector.
+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
+corresponding weight is tallied.  E.g. The Nth entry (weight) in the
-vector tallies the Nth entry (weight) in the second vector.</p>
+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

doc/src/dump.txt

@@ -130,6 +130,10 @@ or multiple smaller files).
 NOTE: 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 "dump_modify
+pbc"_dump_modify.html command if you with to force coordinates to be
+strictly inside the simulation box.
 
 NOTE: Unless the "dump_modify sort"_dump_modify.html option is
 invoked, the lines of atom information written to dump files

doc/src/dump_modify.txt

@@ -36,6 +36,7 @@ keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} o
   {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}
@@ -377,6 +378,19 @@ timestep order.
 
 :line
 
+The {pbc} keyword applies to all the dump styles.  As explained on the
+"dump"_dump.html 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.
+
+:line
+
 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
@@ -755,6 +769,7 @@ image = no
 label = ENTRIES
 nfile = 1
 pad = 0
+pbc = no
 precision = 1000
 region = none
 scale = yes

doc/src/fix_ave_histo.txt

@@ -136,8 +136,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
+corresponding weight is tallied.  E.g. The Nth entry (weight) in the
-vector tallies the Nth entry (weight) in the second vector.
+second vector is tallied to the bin corresponding to the Nth entry in
+the first vector.
 
 :line