-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch mass_density() & update Alfven_speed() #957
Patch mass_density() & update Alfven_speed() #957
Conversation
…ticle, and not "total" mass density that includes the electron component
…; add conditioning for kwargs "ion" and "z_mean"
…ng pytest.mark.parametrize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A quick partial review before a meeting is about to start. I'll try to take another look soon, though please remind me if I forget. Thank you for working on this!
Co-authored-by: Nick Murphy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this! I have a few typos plus a few more in-depth comments.
In the longer term, I'm wondering about how to deal with things like z_mean
. Having z_mean
as a keyword along with ion
has the potential for a contradiction, i.e. a case where the ion
has one charge and z_mean
has a different charge...at least if we assume quasineutrality. We could use CustomParticle
for things like this, since this is the sort of situation it was intended for. Since we now have CustomParticle
, we could drop z_mean
as an argument. Hm...
In the long run, perhaps Particle
could take charges that are non-integers, i.e. Particle("He-4 1.5+")
for the case with z_mean=1.5
...and we could get back a CustomParticle
. Then Particle
could end up being an implementation of the factory design pattern, which maybe it should be. But that's not something for 2020.
The suggestions about using @particle_input
might be beyond the scope of this PR, so they don't have to be implemented here.
if not isinstance(ion, Particle): | ||
try: | ||
ion = Particle(ion) | ||
except TypeError: | ||
raise TypeError( | ||
f"If passing a number density, you must pass a plasmapy Particle " | ||
f"(not type {type(ion)}) to calculate the mass density!" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps use @particle_input
for this function instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, for the same reason stated in https://github.com/PlasmaPy/PlasmaPy/pull/957/files#r537960088.
if not isinstance(particle, Particle): | ||
try: | ||
particle = Particle(particle) | ||
except TypeError: | ||
raise TypeError( | ||
f"If passing a number density, you must pass a plasmapy Particle " | ||
f"(not type {type(particle)}) to calculate the mass density!" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps use @particle_input
to get this functionality instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We ca not do that at this point because the density
annotation is a list. That is what was causing the error that made me do this patch. When I finally finish the update to particle_input
that also adds particle_like
, then we can replace this code block with @particle_input
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! I hereby withdraw my suggestion.
plasmapy/formulary/parameters.py
Outdated
ion : `~plasmapy.particles.Particle`, optional | ||
Representation of the ion species (e.g., `'p'` for protons, `'D+'` for | ||
deuterium, `'He-4 +1'` for singly ionized helium-4, etc.). If no charge | ||
state information is provided, then the ions are assumed to be singly | ||
ionionized. If the density is an ion number density, then this paramter | ||
is required in order to convert to mass density. | ||
|
||
z_mean : `~numbers.Real`, optional | ||
The average ionization state (arithmetic mean) of the ``ion`` composing | ||
the plasma. This is used in calculating the mass density | ||
:math:`\rho = n_i (m_i + Z_{mean} m_e)`. ``z_mean`` is ignored if | ||
``density`` is passed as a mass density. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One use case I'm wondering about is if ion
is provided (e.g., He-4 2+
) and z_mean
is provided as 1
. In this case there's a contradiction between ion
and z_mean
...at least if we want to assume quasineutrality, which is usually the case. (If I remember correctly, the derivation for the Alfvén speed implicitly assumes quasineutrality.) And if z_mean
is provided, then ion
would be an element
instead so the name ion
wouldn't be appropriate. I'm wondering about using the machinery of CustomParticle
for situations like this, which probably won't arise particularly frequently. Hm...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the derivation of the Alfvén speed assumes quasi-neutrality. Now, if someone where to pass ion="He-4 +2"
and z_mean=1.2
, then the function will used the mass of He-4 +2
to calculate the ion mass density and z_mean=1.2
to calculate the electron mass density. So, z_mean
will take precedence over any charge value indicated by ion
.
As I mentioned in the element chat, I'm not sure having z_mean
as a Particle
attribute is the right approach because z_mean
is really a plasma attribute.
Co-authored-by: Nick Murphy <[email protected]>
@namurphy Thanks for the review! My code is always littered with spelling mistakes. I swear I actively look for them before requesting a review. 🤦♂️🤦♂️🤣🤣 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but seriously, please do fix your spellcheck settings, because the more attention reviewers spend fixing typos, the less there is to spare for actual bugs etc! ;)
\\rho = \\left| \\frac{Z_{s}}{Z_{particle}} \\right| n_{s} m_{particle} | ||
= | Z_{ratio} | n_{s} m_{particle} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get how beautifully this renders, but I do a double take every time I look at the source... 😅
plasmapy/formulary/parameters.py
Outdated
The average ionization state (arithmetic mean) of the ``ion`` composing | ||
the plasma. This is used in calculating the mass density | ||
:math:`\rho = n_i (m_i + Z_{mean} m_e)`. ``z_mean`` is ignored if | ||
``density`` is passed as a mass density. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for the future: that's going to get interesting with impurities...
Co-authored-by: Dominik Stańczak <[email protected]>
…rovided by `ion`
@StanczakDominik Thanks for pointing out the typos. For some reason my IDE does not even mark them. I also fix a few more typos I noticed while fixing your suggestions. |
This PR focuses on the
mass_density()
andAlfven_speed()
functions.Alfven_speed()
is touched here because it's currently the only functionality that utilizesmass_density()
mass_density()
The original mass density function was a little un-intuitive since it would actually calculate the total mass density (ions + electrons) from a number density opposed to just the ion mass density or electron mass density. The new mass density function only calculates the mass density for the particle specified.
How it now works...
Alfven_speed()
Original functionality does not change. I just updated the code to handle the new
mass_density()
function and implemented handling ofParticle()
. ThisParticle
handling could be dropped/modified once theparticle_like
annotation is implemented (see issue #912). I also restructured the tests, since that was marked as a TODO.