(the "anode"). The anode is typically ring-shaped so that the majority of
electrons can fly through the hole in the form of an electron beam. In the olden
times, they might then have illuminated the screen of a TV built from a
-[cathode ray rube](https://en.wikipedia.org/wiki/Cathode-ray_tube).
+[cathode ray tube](https://en.wikipedia.org/wiki/Cathode-ray_tube).
Today, instead, electron beams are useful in
[X-ray machines](https://en.wikipedia.org/wiki/X-ray_tube),
[electron beam lithography](https://en.wikipedia.org/wiki/Electron-beam_lithography),
that we have to solve the following set of equations in each time
step:
@f{align*}{
- -\epsilon_0 \Delta V^(n) &= \sum_i e\delta(\mathbf x-\mathbf x_i^{(n-1)})
+ -\epsilon_0 \Delta V^{(n)} &= \sum_i e\delta(\mathbf x-\mathbf x_i^{(n-1)})
\\
\frac{{\mathbf v}_i^{(n)}-{\mathbf v}_i^{(n-1)}}{\Delta t} &= \frac{e\nabla V^{(n)}}{m}
\\
finite element shape functions at points on the refence cell
$\hat{\mathbf x}_i$. To make this efficient, every particle doesn't
just store its location and the cell it is on, but also what location
-that point corresponds to reference coordinates.
+that point corresponds to in the cell's reference coordinate system.
Updating a particle's position is then no more difficult: One just has
to call
There are, of course, times where a particle may leave the domain in
question. In that case,
Particles::ParticleHandler::sort_particles_into_subdomains_and_cells()
-can not find a surrounding cell and simply deletes the cell. But, it
+can not find a surrounding cell and simply deletes the particle. But, it
is often useful to track the number of particles that have been lost
this way, and for this the Particles::ParticleHandler class offers a
"signal" that one can attach to. We show how to do this in the
is, and to record statistics on it.
+@note In this tutorial program, we insert particles by hand and at
+ locations we specifically choose based on conditions that include
+ the solution of the electrostatic problem. But there are other cases
+ where one primarily wants to use particles as passive objects, for
+ example to trace and visualize the flow field of a fluid flow
+ problem. In those cases, there are numerous functions in the
+ Particles::Generators namespace that can generate particles
+ automatically. One of the functions of this namespace is also used
+ in the step-70 tutorial program, for example.
+
<h3>The test case</h3>
width="600">
</p>
-In this picture, that parts of the boundary marked in red and blue are the
+In this picture, the parts of the boundary marked in red and blue are the
cathode, held at an electric potential $V=-V_0$. The part of the cathode shown
-in red is that part that is heated, leading to electrons leaving the metal
+in red is the part that is heated, leading to electrons leaving the metal
and then being accelerated by the electric field (a few electric
field lines are also shown). The green part of the boundary is the anode,
held at $V=+V_0$. The rest of the boundary satisfies a Neumann boundary
condition.
-This set up mimicks real devices. The re-entrant corner results in an
+This setup mimicks real devices. The re-entrant corner results in an
electric potential $V$ whose derivative (the electric field $\mathbf E$)
has a singularity -- in other words, it becomes very large in the vicinity
of the corner, allowing it to rip electrons away from the metal. These
Of practical interest is to figure out which fraction of the
electrons emitted from the cathode actually make it through the
-hole in the anode -- electrons that just bounce into the enode
+hole in the anode -- electrons that just bounce into the anode
itself are not actually doing anything useful other than converting
eletricity into heat. As a consequence, in the `track_lost_particle()`
function (which is called for each particle that leaves the domain,
#include <deal.II/numerics/error_estimator.h>
-// The ones that are new are only the following three: The first declared the
+// The ones that are new are only the following three: The first declares the
// DiscreteTime class that helps us keep track of time in a time-dependent
// simulation. The latter two provide all of the particle functionality,
// namely a way to keep track of particles located on a mesh (the
// @sect4{CathodeRaySimulator::update_timestep_size}
- // As discussed at length in the introduction, we need to respect a CFL
+ // As discussed at length in the introduction, we need to respect a time step
// condition whereby particles can not move further than one cell in one time
// step. To ensure that this is the case, we again first compute the maximal
// speed of all particles on each cell, and divide the cell size by that
projects / dealii.git / commitdiff