From: Wolfgang Bangerth <bangerth@colostate.edu>
Date: Tue, 15 Sep 2020 23:08:25 +0000 (-0600)
Subject: Address Bruno Blais's comments.
X-Git-Tag: v9.3.0-rc1~1105^2~2
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=472f952c48fbb500363b450aedafa69055063894;p=dealii.git

Address Bruno Blais's comments.
---

diff --git a/examples/step-19/doc/intro.dox b/examples/step-19/doc/intro.dox
index 806a6ce564..072f0fb5d1 100644
--- a/examples/step-19/doc/intro.dox
+++ b/examples/step-19/doc/intro.dox
@@ -25,7 +25,10 @@ this simply leads to a set of ordinary differential equations, for example
 if you want to track the positions of the planets in the solar system over
 time, then deal.II is clearly not your right tool. On the other hand, if
 this evolution is due to the interaction with the solution of partial differential
-equation, then deal.II has support for you.
+equation, or if having a mesh to determine which particles interact
+with others (such as in the
+[smoothed particle hydrodynamics (SMH)](https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics)
+method), then deal.II has support for you.
 
 The case we will consider here is how electrically charged particles move through
 an electric field. As motivation, we will consider
diff --git a/examples/step-19/doc/results.dox b/examples/step-19/doc/results.dox
index 06337623b9..190dcdfaa3 100644
--- a/examples/step-19/doc/results.dox
+++ b/examples/step-19/doc/results.dox
@@ -270,7 +270,12 @@ are
 This corresponds to a simple forward-Euler time discretization -- a method of
 first order accuracy in the time step size $\Delta t$ that we know we should
 avoid because we can do better. Rather, one might want to consider a scheme such
-as the leapfrog scheme, or even better a Runge-Kutta integrator.
+as the
+[leapfrog scheme](https://en.wikipedia.org/wiki/Leapfrog_integration)
+or more generally
+[symplectic integrators](https://en.wikipedia.org/wiki/Symplectic_integrator)
+such as the
+[Verlet scheme](https://en.wikipedia.org/wiki/Verlet_integration).
 
 
 <h4> Parallelization </h4>
diff --git a/examples/step-19/step-19.cc b/examples/step-19/step-19.cc
index c2d011b98f..8177bd47e8 100644
--- a/examples/step-19/step-19.cc
+++ b/examples/step-19/step-19.cc
@@ -74,6 +74,17 @@ using namespace dealii;
 // @ref GlossBoundaryIndicator "boundary indicators"
 // for the various parts of the geometry, as well as the physical properties
 // of electrons and other specifics of the setup we use here.
+//
+// For the boundary indicators, let us start enumerating at some
+// random value 101. The principle here is to use numbers that are
+// *uncommon*. If there are pre-defined boundary indicators previously
+// set by the `GridGenerator` functions, they will likely be small
+// integers starting from zero, but not in this rather randomly chosen
+// range. Using numbers such as those below avoids the possibility for
+// conflicts, and also reduces the temptation to just spell these
+// numbers out in the program (because you will probably never
+// remember which is which, whereas you might have been tempted if
+// they had started at 0).
 namespace Step19
 {
   namespace BoundaryIds
@@ -172,7 +183,7 @@ namespace Step19
   // each particle has and that the Particles::ParticleHandler class
   // automatically and always makes sure are available; in particular,
   // these are the current location of a particle, the cell it is on,
-  // and a particle's ID.
+  // it's reference location within that cell, and the particle's ID.
   //
   // The only other variable of interest is `time`, an object of type
   // DiscreteTime. It keeps track of the current time we are in a