Closed DecBrick closed 4 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 84.37%. Comparing base (
1de9706
) to head (91c665e
).
This is nice! I think i would rename the plume energy scale as something like "radial_loss_frequency" or something similar, however. It's not really a wall collision frequency at this point
Well, for the energy loss it still is computed using the wall loss model, even within the channel. Looking at this a little more, I might need to make some more changes as the plume will still compute a SEE coefficient even with these updates. Is there a reference for why the radial losses should use the wall loss model?
Not really, it's kind of ad hoc. The other model (used in LANDMARK) just assumes a constant sheath potential. Our justification is that the field lines terminate in a wall somewhere. However, it should really be whatever sheath might form at the edge of the plume.
That makes sense, although it still sounds like something to come back to later. However, in cross referencing this with the documentation, it does appear that the current implementation of the collision frequency only accounts for singly charged ions, so I'm going to make a commit to update the energy collision frequency name as well as fix the collision frequency.
Thanks for the update. How much of a difference does this end up making to the overall solution?
That should be the last few commits. The wall loss model now correctly accounts for multiply charged species. There is a performance hit of around 5% in runtime using a triply charged model, but that should be a worse-case.
The major change here is to separate out the wall collisions between the electron energy and momentum calculations. Namely, the electron wall collisions as they contribute to the mobility should be 0 in the plume as there are no walls there while the electron wall collisions as they contribute to the electron energy should still exist in the plume to account for radial losses. By separating out these collision frequencies and storing them separately, we can correctly account for both effects. There is no noticeable performance change between the old and new versions.
Additionally, a warning has been added if the user sets the background neutral pressure, but not the solve background neutrals flag.