Plasmapy: Consolidate separate functions for ions and electrons in plasma parameter calculations

[namurphy]

When I was working on the plasma parameter calculations, I put in separate functions for ions and electrons. In retrospect, it would probably work better to have a single function that has the particle species as the input instead of separate ion/electron functions.

The checklist of things to do are:

• [ ] Merge electron_thermal_speed and ion_thermal_speed into thermal_speed
• [ ] Merge electron_gyrofrequency and ion_gyrofrequency into gyrofrequency
• [ ] Merge electron_gyroradius and ion_gyroradius into gyroradius
• [ ] Merge electron_plasma_frequency and ion_plasma_frequency into plasma_frequency
• [ ] Merge electron_inertial_length and ion_inertial_length into inertial_length

A sample call would be:

>>> from astropy import units 
>>> thermal_speed(5*units.K, 'e')

With respect to thermal_speed, there is some ambiguity about whether it is the root mean square (rms) or most probable thermal speed, and between 1D and 3D (see Wikipedia article on thermal speeds). I'm wondering if the following subsequent change would be helpful:

• [ ] Change thermal_speed to thermal_speed_rms and thermal_speed_mostprob
  Probably we want to give it in 3D. In any case, the documentation should specify what is being calculated.

[jhillairet]

Shouldn't the gyrofrequency be signed ? In the current implementation, ion and electron gyrofrequency has the same sign. Is it designed?

[StanczakDominik]

That's a convention thing, I believe. Could do with an optional Boolean flag in the function's signature!

[jhillairet]

I believe it's more than a convention thing. For example, the sign of the cyclotron frequency should affect the calculation of the cold plasma dielectric tensor. Here is a capture from the Stix book :

By the way, I was trying to make a cold tensor calculator using plasmapy, but I discovered than the Numpy vectorize decorator is scraping the units of the quantities... So for instance, it removes the unit of the electron_gyrofrequency function output... Is anyone already ran into this problem?
edit: this bug is described in Astropy : here and specifically here

[namurphy]

@jhillairet, thank you for bringing this up! I like @StanczakDominik's idea of having a Boolean flag like:

omega_ce = gyrofrequency(B, particle='e', signed=True)
omega_ce = gyrofrequency(B, particle='e', unsigned=True)

The question for me is what the default should be. I would most likely use gyrofrequency to determine ratios of timescales, in which case having signed=False as the default would be preferred. If someone is primarily analyzing plasma wave behavior, then having signed=True as the default would make more sense. Perhaps we could do a survey of plasma physics textbooks to see what the most common sign convention is. In any case, we will need the one-line description at the top of the docstring to explicitly say what the convention is.

[namurphy]

Thank you for bringing up the units bug too. Using Astropy 2.0 and NumPy 1.13 together provides improved unit support, but it's still ongoing and requires an upstream fix in NumPy.

Cross-reference: https://github.com/PlasmaPy/PlasmaPy/issues/59

[namurphy]

Whether or not the cyclotron frequency depends on the sign of charge is one more area where there's disagreement in the literature. I took a quick look at the plasma physics books I had nearby to check on their conventions:

Cyclotron frequency depends on magnitude and sign of charge

• The Plasma Formulary by Declan Diver
• Waves in Plasmas by Stix
• The Physics of Plasmas by Boyd and Sanderson

Cyclotron frequency depends on magnitude but not sign of charge

• NRL Plasma Formulary
• Introduction to Plasma Physics and Controlled Fusion by Chen
• Plasma Kinetic Theory by Swanson
• Plasma Waves by Swanson
• Fundamentals of Plasma Physics by Bittencourt
• Principles of Magnetohydrodynamics by Goedbloed & Poedts
• Fundamentals of Physics by Halliday, Resnick, and Walker (5th ed. of introductory textbook)
  
  
  
  • Completely unrelated, but my favorite quote from this book (p. 533) is: "I must caution that dipping fingers into molten lead presents several serious dangers."
  
  

Additionally, Introduction to Plasma Physics by Gurnett & Bhattacharjee uses both definitions with different variables, and a couple of other specialized books don't provide an explicit definition, implicitly assume that it does not depend on sign of charge, or seem to go back and forth between the different conventions.

Either way we do this could lead to some confusion, but perhaps we could go with the more commonly used convention that:

omega_ce = gyrofrequency(B, particle='e')

yields the unsigned flux, and

omega_ce = gyrofrequency(B, particle='e', signed=True)

yields the signed flux. We should make sure the docstring describes this issue. Will this work?

[jhillairet]

Great litterature review ! I agree to the proposed function prototype.

For the other book I do not know, but for the Swanson's book, the author introduces a multiplicative signum (+/- 1) function to the cyclotron pulsation (with a footnote saying that some other authors do not which in these cases leads to negative values for electrons).

[RoberTnf]

@namurphy

Change thermal_speed to thermal_speed_rms and thermal_speed_mostprob
Probably we want to give it in 3D. In any case, the documentation should specify what is being calculated.

Wouldn't it be better to keep it in one function and add a parameter method which would take values, "rms", "most_probable" and maybe "mean_magnitude", defaulting to "rms", as per https://en.wikipedia.org/wiki/Thermal_velocity?

[namurphy]

Wouldn't it be better to keep it in one function and add a parameter method which would take values, "rms", "most_probable" and maybe "mean_magnitude", defaulting to "rms", as per https://en.wikipedia.org/wiki/Thermal_velocity?

Yes, that sounds like a really good way to do it. Thank you!

[jessicalostinspace]

Is anyone currently working on this? What is the easiest way to see if there is progress on the ticket?

[StanczakDominik]

Hey @jessicalostinspace, @RoberTnf is already making good progress on this one. In fact, it's referenced above @namurphy's post from pull request #140.

[RoberTnf]

This issue should be closed, right?

[StanczakDominik]

Indeed!

[jhillairet]

Hello,

Finally, the signed=True option has not been implemented ? Should it be ?

Regards,

[namurphy]

@jhillairet - Good memory for this, thank you! No, this has not yet been implemented. Would you be willing to create a separate issue for this so that it doesn't continue to be forgotten? This issue would be appropriate for a "good first contribution" tag. I personally think we should have this by the v0.1.0 release, especially since it doesn't take much effort.