From abe2e642e13235c04ad50c82239b820b09b43264 Mon Sep 17 00:00:00 2001
From: sjplimp <sjplimp@f3b2605a-c512-4ea7-a41b-209d697bcdaa>
Date: Fri, 17 Jan 2014 21:51:23 +0000
Subject: [PATCH] git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@11258
 f3b2605a-c512-4ea7-a41b-209d697bcdaa

---
 doc/Section_accelerate.html |  9 +++++----
 doc/Section_accelerate.txt  |  9 +++++----
 doc/Section_start.html      |  2 +-
 doc/Section_start.txt       |  2 +-
 doc/atom_modify.html        | 15 +++++++--------
 doc/atom_modify.txt         | 15 +++++++--------
 6 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/doc/Section_accelerate.html b/doc/Section_accelerate.html
index 3310eec990..f526ee0767 100644
--- a/doc/Section_accelerate.html
+++ b/doc/Section_accelerate.html
@@ -85,10 +85,11 @@ LAMMPS, to obtain synchronized timings.
 <P>Here is a list of general ideas for improving simulation performance.
 Most of them are only applicable to certain models and certain
 bottlenecks in the current performance, so let the timing data you
-intially generate be your guide.  It is hard, if not impossible, to
-predict how much difference these options will make, since it is a
-function of your problem and your machine.  There is no substitute for
-simply trying them out.
+generate be your guide.  It is hard, if not impossible, to predict how
+much difference these options will make, since it is a function of
+problem size, number of processors used, and your machine.  There is
+no substitute for identifying performance bottlenecks, and trying out
+various options.
 </P>
 <UL><LI>rRESPA
 <LI>2-FFT PPPM
diff --git a/doc/Section_accelerate.txt b/doc/Section_accelerate.txt
index 66bc2dcd43..f219791223 100644
--- a/doc/Section_accelerate.txt
+++ b/doc/Section_accelerate.txt
@@ -81,10 +81,11 @@ NOTE: this sub-section is still a work in progress
 Here is a list of general ideas for improving simulation performance.
 Most of them are only applicable to certain models and certain
 bottlenecks in the current performance, so let the timing data you
-intially generate be your guide.  It is hard, if not impossible, to
-predict how much difference these options will make, since it is a
-function of your problem and your machine.  There is no substitute for
-simply trying them out.
+generate be your guide.  It is hard, if not impossible, to predict how
+much difference these options will make, since it is a function of
+problem size, number of processors used, and your machine.  There is
+no substitute for identifying performance bottlenecks, and trying out
+various options.
 
 rRESPA
 2-FFT PPPM
diff --git a/doc/Section_start.html b/doc/Section_start.html
index 239b7f7e8f..0321152035 100644
--- a/doc/Section_start.html
+++ b/doc/Section_start.html
@@ -458,7 +458,7 @@ files created when LAMMPS is built, for either all builds or for a
 particular machine.
 </P>
 <P>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
--DLAMMPS_BIBIG or -DLAMMPS_SMALLSMALL
+-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
 </P>
 <P>As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
diff --git a/doc/Section_start.txt b/doc/Section_start.txt
index ca0c8061c1..8f1b624fcd 100644
--- a/doc/Section_start.txt
+++ b/doc/Section_start.txt
@@ -452,7 +452,7 @@ files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
 (3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
--DLAMMPS_BIBIG or -DLAMMPS_SMALLSMALL
+-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
 
 As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
diff --git a/doc/atom_modify.html b/doc/atom_modify.html
index 58bdda6574..4a15940e75 100644
--- a/doc/atom_modify.html
+++ b/doc/atom_modify.html
@@ -22,8 +22,7 @@ Commands</A>
 
 <PRE>   <I>id</I> value = <I>yes</I> or <I>no</I>
    <I>map</I> value = <I>array</I> or <I>hash</I>
-   <I>first</I> value = group-ID = group whose atoms will appear first in  
-internal atom lists
+   <I>first</I> value = group-ID = group whose atoms will appear first in internal atom lists
    <I>sort</I> values = Nfreq binsize
      Nfreq = sort atoms spatially every this many time steps
      binsize = bin size for spatial sorting (distance units) 
@@ -60,12 +59,12 @@ between two atoms.
 </P>
 <P>The only reason not to use atom IDs is if you are running an atomic
 simulation so large that IDs cannot be uniquely assigned.  For a
-default LAMMPS build this limit is 2^31 or ~2 billion atoms.  However,
-even in this case, you can use 64-bit atom IDs, allowing 2^63 or ~9e18
-atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG switch.  This is
-described in <A HREF = "Section_start.html#start_2">Section 2.2</A> of the manual.
-If atom IDs are not used, they must be specified as 0 for all atoms,
-e.g. in a data or restart file.
+default LAMMPS build this limit is 2^31 or about 2 billion atoms.
+However, even in this case, you can use 64-bit atom IDs, allowing 2^63
+or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
+switch.  This is described in <A HREF = "Section_start.html#start_2">Section 2.2</A>
+of the manual.  If atom IDs are not used, they must be specified as 0
+for all atoms, e.g. in a data or restart file.
 </P>
 <P>The <I>map</I> keyword determines how atom ID lookup is done for molecular
 atom styles.  Lookups are performed by bond (angle, etc) routines in
diff --git a/doc/atom_modify.txt b/doc/atom_modify.txt
index c7d7e68e16..e738ba4275 100644
--- a/doc/atom_modify.txt
+++ b/doc/atom_modify.txt
@@ -17,8 +17,7 @@ one or more keyword/value pairs may be appended :ulb,l
 keyword = {id} or {map} or {first} or {sort} :l
    {id} value = {yes} or {no}
    {map} value = {array} or {hash}
-   {first} value = group-ID = group whose atoms will appear first in  
-internal atom lists
+   {first} value = group-ID = group whose atoms will appear first in internal atom lists
    {sort} values = Nfreq binsize
      Nfreq = sort atoms spatially every this many time steps
      binsize = bin size for spatial sorting (distance units) :pre
@@ -54,12 +53,12 @@ between two atoms.
 
 The only reason not to use atom IDs is if you are running an atomic
 simulation so large that IDs cannot be uniquely assigned.  For a
-default LAMMPS build this limit is 2^31 or ~2 billion atoms.  However,
-even in this case, you can use 64-bit atom IDs, allowing 2^63 or ~9e18
-atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG switch.  This is
-described in "Section 2.2"_Section_start.html#start_2 of the manual.
-If atom IDs are not used, they must be specified as 0 for all atoms,
-e.g. in a data or restart file.
+default LAMMPS build this limit is 2^31 or about 2 billion atoms.
+However, even in this case, you can use 64-bit atom IDs, allowing 2^63
+or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
+switch.  This is described in "Section 2.2"_Section_start.html#start_2
+of the manual.  If atom IDs are not used, they must be specified as 0
+for all atoms, e.g. in a data or restart file.
 
 The {map} keyword determines how atom ID lookup is done for molecular
 atom styles.  Lookups are performed by bond (angle, etc) routines in