Merge remote-tracking branch 'github/develop' into collected-small-fixes

doc/src/fix_ave_grid.rst

@@ -129,12 +129,12 @@ overlays the simulation box.  For 2d simulations, *Nz* must be 1.  The
 very coarse compared to the particle count, or very fine.  If one or
 more of the values = 1, then bins are 2d planes or 1d slices of the
 simulation domain.  Note that if the total number of grid cells is
-small, it may be more efficient to use the doc:`fix ave/chunk
+small, it may be more efficient to use the :doc:`fix ave/chunk
 <fix_ave_chunk>` command which can treat a grid defined by the
 :doc:`compute chunk/atom <compute_chunk_atom>` command as a global
 grid where each processor owns a copy of all the grid cells.  If *Nx*
 = *Ny* = *Nz* = 1 is used, the same calculation would be more
-efficiently performed by the doc:`fix ave/atom <fix_ave_atom>`
+efficiently performed by the :doc:`fix ave/atom <fix_ave_atom>`
 command.
 
 If the simulation box size or shape changes during a simulation, the

doc/src/fix_polarize.rst

@@ -130,10 +130,23 @@ Fix *polarize/functional* employs the energy functional variation
 approach as described in :ref:`(Jadhao) <Jadhao>` to solve
 :math:`\sigma_b`.
 
+The induced charges computed by these fixes are stored in the *q_scaled* field,
+and can be accessed as in the following example:
+
+.. code-block:: LAMMPS
+
+  compute qs all property/atom q_scaled
+  dump 1 all custom 1000 all.txt id type q x y z c_qs
+
+Note that the *q* field is the regular atom charges, which do not change
+during the simulation. For interface particles, *q_scaled* is the sum
+of the real charge, divided by the local dielectric constant *epsilon*,
+and their induced charges. For non-interface particles, *q_scaled* is
+the real charge, divided by the local dielectric constant *epsilon*.
+
 More details on the implementation of these fixes and their recommended
 use are described in :ref:`(NguyenTD) <NguyenTD>`.
 
-
 Restart, fix_modify, output, run start/stop, minimize info
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""
 

doc/src/variable.rst

@@ -1441,7 +1441,7 @@ timestep that the variable needs the tallies.  An input script can
 also request variables be evaluated before or after or in between
 runs, e.g. by including them in a :doc:`print <print>` command.
 
-LAMMPS keeps track of all of this as it performs a doc:`run <run>` or
+LAMMPS keeps track of all of this as it performs a :doc:`run <run>` or
 :doc:`minimize <minimize>` simulation, as well as in between
 simulations.  An error will be generated if you attempt to evaluate a
 variable when LAMMPS knows it cannot produce accurate values.  For
@@ -1453,7 +1453,7 @@ command, then an error will occur.
 
 However, there are two special cases to be aware when a variable
 requires invocation of a compute (directly or indirectly).  The first
-is if the variable is evaluated before the first doc:`run <run>` or
+is if the variable is evaluated before the first :doc:`run <run>` or
 :doc:`minimize <minimize>` command in the input script.  In this case,
 LAMMPS will generate an error.  This is because many computes require
 initializations which have not yet taken place.  One example is the
@@ -1463,10 +1463,10 @@ energy or virial quantities; these values are not tallied until the
 first simulation begins.
 
 The second special case is when a variable that depends on a compute
-is evaluated in between doc:`run <run>` or :doc:`minimize <minimize>`
+is evaluated in between :doc:`run <run>` or :doc:`minimize <minimize>`
 commands.  It is possible for other input script commands issued
 following the previous run, but before the variable is evaluated, to
-change the system.  For example, the doc:`delete_atoms <delete_atoms>`
+change the system.  For example, the :doc:`delete_atoms <delete_atoms>`
 command could be used to remove atoms.  Since the compute will not
 re-initialize itself until the next simulation or it may depend on
 energy/virial computations performed before the system was changed, it