Particle injector for boundary inflow

[JamesMcClung]

Adds InjectorBoundaryInflow, an injector (to be passed as the inject_particles argument of makePscIntegrator) that injects particles at a boundary as if from a population of particles just beyond the edge. The injector has the following features:

1. The imaginary particle population can, in principle, have any time-independent, spatially-varying velocity distribution
2. The continuity and gauss checks are guaranteed to pass for first-order particles

The injector currently has a few limitations, however:

1. Only one kind of particle can be injected
2. The imaginary particle population must be time-independent
3. The imaginary particle population is hardcoded to have a number density of 1
4. Injection is only supported at the lower y-bound
5. Continuity and gauss checks may fail for higher-order particles

Also note that the injector is not responsible for removing particles that exit the domain. This injector should be paired with a boundary condition of BND_PRT_OPEN that removes exiting particles, although this functionality does not currently exist.

See test_injector_boundary_inflow for example uses.

[JamesMcClung]

I'm now thinking BoundaryInjector might be a nicer name than InjectorBoundaryInflow. Also, my current plan to solve problem 1 is to add a CompositeInjector, which is just a combination of multiple injectors.

[germasch]

LGTM -- I did go through it commit by commit (and, as usual, nice job breaking it up). Still couldn't say that I followed 100% of it, but I only have two minor concerns:

• The .999 to keep it away from the right boundary. I hit similar issues before in the particle boundary -- I think I used (1 - 1e-6) at that point. I guess neither is likely to cause any noticeable issues, though.
• You templated some injected particle generator class by the number of particles -- I don't think I saw why that's a template arg rather than just a regular argument.

[JamesMcClung]

What kind of issue, noticeable or not, would you anticipate from the .999? It does have to be in that cell, so 1.0 doesn't work.

As for the templated count... yeah, that was just me doing the first thing that came to mind. I already have a note to fix that in the next PR I'll submit.

[germasch]

Well, this was nicely split out, so (relatively) easy to follow.

Looks good, though I came away with two questions:

You used a .999 factor to prevent particles from being on the edge -- I've done similar before, though I guess I'd add another two or so 9's there which should still be enough to avoid hitting the boundary. .999 is like a 0.1% error, which is small but might still show up under certain circumstances (?, or not...)

I saw you adding current through the boundary based on how much charge made it into the domain -- but I feel like this is missing something, as it should also matter how far into the domain the particles made it -- some of their charge cloud might still be outside and hence not have flown through the boundary. Or maybe the b.c.s are still wall-like, so that outside part would still be inside? I'm just kinda confused, I'm rather sure you know those nuances and are testing things accordingly...

[germasch]

Whoops, clearly I reviewed the wrong PR :(