The magnetic skeleton of a plasma includes the boundaries that separate plasma into distinct topological domains. These topological features include magnetic null points, spine field lines, separatrix surfaces, and separators. In plasmas like the solar atmosphere there are also bald patches where the magnetic field is tangential to the photosphere. In addition to the topological features, there are also geometrical features like quasi-separatrix layers (QSLs) where the connectivity of the magnetic field changes significantly over a short distance in space. QSLs come up frequently in studies of the solar corona. These features are used commonly to understand, for example, 3D reconnection.

It would be very useful to have easy-to-use functionality for finding these topological and geometric features, and also visualizing their time evolution. There are also linear analyses that can be done at or along these features (such as calculating the eigenvalues and eigenvectors of a null point which yields the classification plus the locations of their separatrix surfaces and spines). It would be great to implement some tools in PlasmaPy to locate and analyze these features for numerical and also analytical configurations.

I'm somewhat less familiar with the tools used for analyzing magnetic configurations in toroidal plasmas, other than Poincare plots and things like that. Ideas about what to include for such configurations would be greatly appreciated!

I'm tentatively including this on the v0.1 milestone and assigning it to myself, though we could wait until v0.2 if we need to prioritize other things.

Some papers on finding magnetic skeletons include:

• John Greene, Locating Three-Dimensional Roots by a Bisection Method, J. Comp. Phys, 98, 194, 1992
• Andrew Haynes and Clare Parnell, A trilinear method for finding null points in a three-dimensional vector space, Phys. Plasmas, 14, 082107, 2007
• Andrew Haynes and Clare Parnell, A method for finding three-dimensional magnetic skeletons, Phys. Plasmas, 17, 092903, 2010

A paper on the structure and classification of magnetic null points is:

• Clare Parnell, The structure of three‐dimensional magnetic neutral points, Phys. Plasmas, 3, 759, 1996

We are frequently going to need to reference basic atomic data such as the atomic number and atomic mass, including for different ionization states and different isotopes. We will need this information for numerous applications, including as basic as getting the Alfven speed from the number density and the ion species. There will also be situations that require significantly more atomic data (e.g., calculating radiative cooling rates or ionization/recombination rates as a function of temperature/energy) so our approach should be able to be extended.

There do exist atomic databases with Python interfaces including ChiantiPy and pyatomdb, though the latter is in a pre-alpha state of development. We could look into how these databases store both basic and more detailed information, and perhaps using one of them as an optional dependency.

My questions are:

• How should we store atomic data?
• What atomic data should we store?
• How should we access stored atomic data? (e.g., what API should we use?)

Some candidates as proposed by the Reddit hivemind:

• Pysma
• Pylasma (I like that one!)

I wouldn't mind staying with PlasmaPy but I thought I'd remind everyone of the infinity of pun space.

task of #69 , for a PIC simulation
Passing from the particle to the field :

• linear weighting via "inverse area" of the particle to the plasma density field
  From the field to the particle
• calculate the electric and magnetizable field via 1D or 2D interpolation.

This task is not complicated, but it is the interface between the Plasma and the Particle instances. This interface should be well thought

We are presently in the early stages of development, and it is probably worth thinking about what we want to include in our first micro version of PlasmaPy. My hope is that we will have something that is useful enough that it would be worthwhile for plasma physicists to install, though not so ambitious that it would take us more than ~3-6 months to complete. I'll create a few milestones with GitHub so that we can start to keep track of things like this.

A very incomplete list of the things that I've been thinking about include:

• Ability to calculate most needed plasma parameters, transport coefficients, and dimensionless numbers (#34)
• A prototype Plasma class (see #23)
• Good documentation for the features that are included (#30, #31)
• Making sure that the code of conduct and vision statement are consistent with each other (#15)
• 10,000 space wombats

I'm not sure if we want to include rudimentary simulation capabilities yet, since those could end up being quite ambitious and might be worth including in a 0.1 release instead. What are other things that we should include in 0.0.1?

In the PIC simulation, task of #69
After each particles step/push , boundaries have to be handled.
May be needed :

• kind of check_out function that check if the particle is out, and where (up, down, ...)
• remove_particle to delete the particle from the arrays
• reflect_particle for a reflection re-injection. May be diffuse or scattered ?
• periodic_boundary for a periodic re-injection
• A way to set the boundary (periodic, mirror, and so on)

Finite difference methods work really well for a lot of problems, but there are some problems that they are not well suited for. Finite element and spectral element schemes have the advantage of considerable geometric flexibility, which makes them highly suitable for simulating toroidal confinement devices with round-ish/triangular-ish cross sections or otherwise non-trivial geometry. It would be great if we had finite element plasma simulation capabilities in addition to finite difference capabilities. I am sure we will need multiple methods since different methods will be most suitable for different problems (e.g., finite elements are not the greatest at capturing shocks).

It would be advantageous if we could build upon an existing package. Possibilities include (but are not limited to):

• FEnicS: "FEniCS is a popular open-source (LGPLv3) computing platform for solving partial differential equations (PDEs). FEniCS enables users to quickly translate scientific models into efficient finite element code."
• MFEM: "a free, lightweight, scalable C++ library for finite element methods" with python bindings though PyMFEM. This was suggested in #66.

The package(s) that we use should have the following qualities:

• Easy to use
• Open source under a permissive license
• Really well integrated into Python
  • Can be installed easily using tools like conda (which was easy to do for FEnicS, at least)
• Allows users to produce highly readable/maintainable code
• High performance on devices ranging from laptops (or cell phones?) to gigantic megacomputers from science fiction that for some reason still use punchcards
• Flexible, so that it is easy to change the system of equations
• Stable API
• Well suited to handling stiff systems of equations
  • As an example, semi-implicit schemes can use an implicit time advance to cover the shortest timescale behavior, with an explicit time advance for longer timescale behavior
• Has an active user/developer community
• Easy to use (repeating here, but I'd say this is even more important than performance)

We can also learn from existing really powerful plasma simulation codes that are written in Fortran, including:

• NIMROD
• M3D
• HiFi, which is also a much more general PDE solver

Some of these codes can be used in Python via OMFIT, though I believe most or all of these codes and OMFIT require signing a user agreement form before getting access.

This is a very long term project, so this might be best saved until v0.2 or later.

When working on parameters.py, I created two temporary methods in utils/checks.py: _check_quantity and _check_relativistic. _check_quantity does a lot of checking to make sure that a Quantity has the right units or gets the right units attached to it and has valid values. _check_relativistic makes sure that the output of a function is not relativistic by raising warnings if the velocity is greater than 10% of the speed of light. These methods would be much more elegant as decorators so that they can be called like:

from astropy import units

@check_relativistic
@check_quantity
def ion_sound_speed(whatever: units.T, ... ):
    ...
    return c_s.to(units.m/units.s)

Your mission, if you choose to accept it, is to change _check_quantity and _check_relativistic to decorators. After that, the next step would be to modify parameters.py to use the decorators instead of the original methods. Thank you in advance!

Thus far in the atomic routines, there are a few ways to represent ions in the form of a string: 'p', 'proton', 'H-1+', 'H-1 1+', and 'H-1 +1' all represent protons. Another possibility would be to represent them as a tuple or class that contains the ion species and the ionization state: e.g., ('H-1', 1) would also represent a proton. Perhaps (1, 'H-1') could be treated as equivalent to ('H-1', 1), if we wanted to maximize flexibility. This is similar to but much simpler than the ParticleSpecies class that was thoughtfully suggested in issue #40 for a particle stepper.

Also, I found another issue for isotopes with plus or minus signs to indicate the charge state:

>>> charge_state('H-1+')  # this works fine
1
>>> charge_state('H-1-')  # this should be -1 but instead just makes my computer sad
ValueError: The following input does not have valid charge state information: H-1-

If the first syntax works, then I was thinking that the second syntax should also work, except if there is a chance of ambiguity. An additional like in test_atomic.py to test that would be:

assert charge_state('H-1-') == -1

I'm still thinking about this, as there is a chance of ambiguity. Another possibility would be to allow syntax like 'H-1 +' where there is a space between the isotope and the plus sign.

Now to see if I can figure out a checklist:

• Allow ions to be represented as a tuple like ('H-1', 1).
• Allow ions to be represented like 'H-1-' and act the same way as 'H-1+'
• Allow ions to be represented like 'H-1 +' or 'H-1 -'

We will eventually need to include a solver for the Grad-Shafranov equation to facilitate finding axisymmetric MHD equilibria. The solver should allow for flexible geometry to be able to match a variety of experiments. Some configurations do not have a central stack (e.g., spheromaks), so the solver should account for regularity conditions at R=0. The highest priority should probably be given to laboratory experiments, but it would be great for the solver to be flexible enough to be used for astrophysical phenomena since there are some situations where it may end up being very useful (possibly including neutron star magnetospheres or streamer belts in the solar atmosphere).

There are a variety of ways that Grad-Shafranov solvers are used, and a related problem is fitting equilibria based on experimental data. For the latter problem, my understanding is that the eqtools package works really well. If anyone has a lot of experience solving the Grad-Shafranov equation or fitting equilibria, any thoughts and suggestions would be very helpful!

A subsequent task after this would be a tool to gauge stability of the equilibria generated by this solver (and also other equilibria).

When I posted the link to PlasmaPy on Reddit many people were rather confused as to the aim of what we are trying to do here. I believe the materials are already in place on Riot, Reddit - it just needs some cutting and pasting, with a pinch of rewriting.

What we need to cover:

Why astronomy benefits so much from astropy and what that is

Why plasma physics is lagging behind in that and why that's detrimental

Why Python and not Fortran or c

What's our planned scope, what do we intend to do with this project

How open we are to suggestions and input from people, especially but definitely not limited to those in plasma research (very!)

How to discuss this, link to Riot chat

How to suggest features and why we need that to progress

Some of this could go into the vision statement, but at least some of it needs to be right up there in people's faces.

I'll take a bite at this within 48h if nobody else has started work on that before that time (I'll open up a pull request ASAP so people are aware things are in progress).

Rewriting for clarity and suggestions for additional things to mention are much appreciated!

Before our first minor release, we'll need to think more about how to organize the subpackages that we are creating. Right now we have the following subpackages:

• analytic
• classes
• constants
• io
• utils
• visualization
  Additionally, there will probably be new subpackages for the simulation capabilities that are being implemented (#33). Presently io, utils, and visualization don't have much in them but we will likely need them in the future.

Are there ways that we should rearrange these subpackages? An important point from Colby is to think of where it would make the most sense for a user to import certain functionality from (e.g., what subpackage names are most intuitive).

Some thoughts that came up during today's telecon were:

• Move atomic functionality from constants into atomic since there is a good chance we will need a lot more atomic functionality sooner or later (e.g., if someone wants collisional cross sections for tungsten, for example).
• Remove analytic and put the plasma dispersion function in math and plasma parameters into something like physics or plasma (or whatever name suits it best or is most intuitive).

Particle distribution functions are used pretty commonly in plasma physics, and there are analytical expressions for Maxwell-Boltzmann and kappa distributions. It would be great to create functions for these distributions in the physics subpackage.

Currently the installation process requires 2 steps, one of which is installing required packages by running pip install -r <requirements file> command. I think this should be handle automatically by setup.py, without forcing users to do it themselves. Moreover, this method might be a problem in the future, when PlasmaPy will become mature enough for its first PyPI release.

Unfortunately, with right now setup.py imports the whole package and from it extracts necessary package metadata: its name, current version and description. Because of it, running python setup.py install before installing requirements ends with a ModuleNotFoundError:

$ python setup.py install
Traceback (most recent call last):
  File "setup.py", line 2, in <module>
    import plasmapy
  File "/path/to/PlasmaPy/plasmapy/__init__.py", line 7, in <module>
    from .classes import Plasma
  File "/path/to/PlasmaPy/plasmapy/classes/__init__.py", line 1, in <module>
    from .plasma import Plasma
  File "/path/to/PlasmaPy/plasmapy/classes/plasma.py", line 8, in <module>
    import numpy as np
ModuleNotFoundError: No module named 'numpy'

Since setup.py needs only PlasmaPy metadata (i.e. name, version and description), I propose we move it to a new file plasmapy/_metadata.py, which could be used by both plasmapy/__init__.py and setup.py. This would bring a couple of improvements:

1. We would have a single clearly defined place, where those values would be defined. This is even more important when taking the fact that currently the package itself doesn't contain its own version, which should be accessible by e.g. invoking plasmapy.__version__ (therefore compliant with PEP 396).
2. Installation process would be limited to only one command (either pip install . from the top directory or python setup.py install). No more ModuleNotFoundErrors.
3. Stable releases would be made easier (I'm not sure if currently releasing PlasmaPy on PyPI would be even possible).
4. Limit the number of future changes done to setup.py.

Additionally, I think we should also change the way of how requirements are defined in setup.py. Since PlasmaPy already has requirements/base.txt, why not just make setup.py read it and extract package requirements from it automatically? That way any future changes to requirements would be limited to just requirements/base.txt file.

If no one has any objections, I would like to prepare necessary changes, it shouldn't be much of a problem.

The functions to calculate plasma parameters in physics/parameters.py should have a discussion of physical concepts in their docstrings. Some of the functions sort of do, while others like ion_inertial_length presently have little more than the formula. These docstrings should be improved to have a concise and easily understandable discussion of the physics involved. The docstrings should also be consistent with each other, using the numpydoc style.

These modifications would be great for new contributors who would be making their first pull request (see https://github.com/PlasmaPy/PlasmaPy/blob/master/CONTRIBUTE.md). If you'd like to work on a particular function, please comment below to avoid duplication of effort. The original pull request (#34) has some brainstorming on possible ways to structure the docstrings.

Thank you!

The Biot-Savart law describes the magnetic field resulting from currents throughout a volume. It will eventually be useful for PlasmaPy to have a Biot-Savart law solver that is able to calculate the magnetostatic field associated with one or more current carrying wires or the current density throughout the volume. Potential applications would be the coils that generate pre-existing magnetic fields prior to discharges in laboratory plasma devices. There will probably need to be capabilities for both boundary conditions at infinity as well as conductor boundary conditions.

It would probably be helpful to look for existing general Biot-Savart law solvers in Python or other languages as well as numerical methods described in the literature (perhaps in Principals of Magnetostatics by Richard Fernow).

I'm not sure where the best place to put this would be...perhaps a file named either biotsavart.py or magnetostatics.py in the physics subpackage?

A (probably unrealistic!) stretch goal would be to have a way to analytically solve the Biot-Savart law integral using SymPy when the currents are given by analytic expressions.

Thank you!

It turns out Fortran lingo is mighty confusing.

Please see the attached Reddit thread and the related discussion:

https://www.reddit.com/r/Python/comments/6qa11t/comment/dkw3hfu

We might need a place for people to weigh in on the actual direction we're taking, and this is probably the best place.

Some questions to consider:

• What tasks are common in your own niche of plasma research (it's a big field, after all)?
• What would you like automated or what have you successfully automated that could be handy for others as well?
• What do you find yourself rewriting in each and every analysis you're writing?
• What further questions could be be usefully asked here?

Currently it looks like plasma class is defined on a Cartesian array, that makes it a bit specific. I am thinking maybe we could define a plasma with a single set of parameters e.g. electron/ion number density, temperature, ion charge state, magnetic field, etc., which can be used to calculate Alfven speed, sound speed, Lundquist number, transport coefficients, etc.

And when we have arrays of non-dimensionalized variables from simulation, which can be in any coordinate system/mesh, we can use a plasma object to define how to convert non-dimensionalized variables into real units.

Any thoughts on this? This seems a design decision we should make early on.

At some point we'll need to write the functionality for calculating transport coefficients, including resistivities, viscosities, Braginskii everything (and then some), etc. This is one of the next steps after pull request #34 to calculate plasma parameters. My hope is to have docstrings that describe the meanings of each of these coefficients in terms that are understandable to undergraduates but useful to experienced plasma physicists (which is what I'm trying to do for the plasma parameter functions). The equations would need to be put in SI units for consistency with the rest of the code, but should allow temperature to be in eV and so on. These will also need unit tests. (We'll eventually need a full separate documentation page to introduce/discuss the different plasma parameters, transport coefficients, dimensionless numbers, and so on but this can be a separate issue a few months from now once the API stabilizes a bit.)

Resources include:

• NRL Plasma Formulary
• A Plasma Formulary for Physics, Technology, and Astrophysics by Declan Diver
• Collisional Transport in Magnetized Plasma

I'll assign myself to this for the time being. It will probably take me a couple of weeks to get to this, so someone else could take the lead on this if you'd like!

As discussed on HipChat recently, I'd like to give adapting my particle stepper a try. The way I see this working would be:

• Add a ParticleSpecies class containing their basic information such as position and velocity (as numpy ndarrays), charge and mass. This seems like a minimal necessary set of information. I would also like to save historical data on their positions and velocities every few timesteps into a larger ndarray to avoid frequent file IO (the iteration step between saving could be given by user, according to the resolution required).
• Give them a push method that takes electric and magnetic fields (ndarrays) at particle locations (so they're the same shape) and updates their positions and velocities. I have two Boris pushers, one nonrelativistic and one relativistic - I can port both. Of course, we want velocities at half timesteps to help with energy conservation - adding another method init_push (without updating positions) to start that is trivial.
• Add functionality for interpolating fields from - initially - Cartesian grids to particle positions. I've done this in 1D. Given that we want 3D, I'll try to find an algorithm that implements that - I have a few papers with those lying around.
• I have to say that I have absolutely no idea on how to do this in non-cartesian geometries, so that's something I'd like to postpone until later. As far as I can tell our current idea for the Plasma class is to stay Cartesian for a bit, then branch out a little, so that seems reasonable to me.

I should be able to start working on this by about June 7th or so. Any help brainstorming before I get cracking on this would be much appreciated!

One possibility for future development in PlasmaPy is adding basic simulation capabilities. At first, the codes can be simple (e.g., 2D resistive MHD on a rectangular grid using finite differences and a straightforward time-advance). Later, the project could include more sophisticated options and numerical methods (finite element, spectral element, finite volume, etc.). Some thoughts on 2D MHD simulation capabilities are:

• The code should be easy to set up and use so that it can be used for educational purposes
• The code should be extremely well documented, with unit tests and test cases
• The output should be in a standard format, probably HDF5
• Following best practices for scientific computing, the code should work before it is optimized. Possibilities for optimization include:
  • Using numpy arrays and cython/numba
  • Developing it in Fortran or C/C++
• When figuring out how to develop this, we should keep in mind possibilities for longer-term development
• Related possibilities for development include
  • A basic 2D particle-in-cell code for kinetic simulations
  • Reduced MHD simulation capabilities

1. Snakes reconnecting!
2. Tokamak/Stellerator around the Sun
3. Lots of other snake ideas: Snake following particle path aroung B, B going around snake, ...

I raised an Astropy issue about converting between radians per second and Hertz using astropy.units. I ran into some potential pitfalls using the dimensionless_angles() equivalency which treats 1 rad/s as equal to 1 Hz rather than 1/2π Hz as I expected. Some examples are:

>>> from astropy import units as u
>>> u.set_enabled_equivalencies(u.dimensionless_angles())
>>> angular_frequency = 1.0 * u.rad/u.s
>>> angular_frequency.to(u.Hz)
<Quantity 1.0 Hz>

and

>>> (1*u.cycle/u.s).to(u.Hz, equivalencies=u.dimensionless_angles())  # expected to be 1 Hz
<Quantity 6.283185307179586 Hz>

The most elegant and readable solution that was presented was to use an equivalency that says that 1 Hz = 1 cycle / s:

>>> (1.*u.cycle/u.s).to(u.Hz, equivalencies=[(u.cy/u.s, u.Hz)])
<Quantity 1.0 Hz>

This will probably come up in the future for us as we deal with various angular frequencies in rad / s and then need to convert them to Hz, or when we're trying to get a scale length from a velocity divided by an angular frequency. I figured it would be worthwhile to bring this up here for future reference, and also as an informational thing to be aware of when we're writing documentation.

This has also been brought up in several issues in pint:

• Add angular frequency
• Question about dimensionless units conversion
• deg and radians dimensionality == dimensionless?

There is a really interesting discussion on why radians are dimensionless here: Why are angles dimensionless and quantities such as length not? The part that was most convincing to me is thinking of sin(x) = x + (x^3)/6 + ... This expression implies that x and x^3 would need to be the same dimension.

https://www.reddit.com/r/Python/comments/6qa11t/comment/dkw8ur9

Just linking this comment for now, I thought it was insightful.

We will soon need functionality to calculate dimensionless plasma parameters. Obvious ones to include are:

• Lundquist_number (my favorite!)
• magnetic_Reynolds_number (note: similar to Lundquist number)
• Reynolds_number
• Prandtl_number
• plasma_beta (went in as beta)
• Mach_number
• Coulomb_logarithm
• Debye_number (this may be better here than with Debye_length in the plasma parameters file)

There are a bunch more in the NRL Plasma Formulary. Please add suggestions, as I'm undoubtedly missing lots of dimensionless numbers! I'm also not sure what the best names are for things like the ratio of the gyroradius to the system size (relative_gyroradius?).

This functionality will need to be added after pull request #34 on plasma parameters and issue #35 on transport coefficients. A possible file name would be dimensionless.py. The docstrings for these functions should include descriptions of the physics behind them as well as caveats and considerations in using them.

Side note: an annoyance I have with the names of most of these dimensionless parameters is that they provide little insight into the physics that is being represented by them. That said, I guess that the standard names are the ones most people are familiar with, so it's probably still best to go with them rather than use turbulentness_number instead of Reynolds_number. However, I still think we should change "Rayleigh-Taylor instability" to "swirly mushroom instability".

We should have some introductory documentation for new users. This should cover:

• Creating and using Plasma objects
• Brief introduction to Astropy units (or whatever, if we end up switching to another package)
• Overview of available plasma parameters

This (and other narrative docs) should be in addition to the autogenerated docs from Sphinx (#30).

Over the last few years, I have gradually learned that plasmas tend to contain atoms. Hence, we will need to include some degree of atomic physics within PlasmaPy. The atomic data needs in plasma physics are very broad. For example, temperatures of interest range from ~10 K in molecular clouds to ~30-40 MK in solar flares. Astronomers tend to care about the dozen or so most abundant elements in the universe, while laboratory plasma physicists care a lot about impurities leeching in from the plasma-facing wall which is often from different materials. Dust also plays important roles in laboratory and astrophysical plasmas.

Including the ability to access all of the information any plasma physicist might ever need would be a never-ending project that would increase the size of this package by orders of magnitude. However, the ability to access important atomic data will be extremely useful for numerous plasma physicists across sub-disciplines. Hence we will need to do a lot of strategizing about what the most important needs are and how best to fill them. Some questions are:

• What atomic data sets are most broadly needed by plasma physicists?
• How and to what extent should PlasmaPy fulfil atomic physics needs?
• What are the existing databases, and how would it be best to partner with them?
• Are there atomic data needs that are not being fulfilled by any databases?
• What should we include in the core package in our version 0.1 release?

A subset of the atomic data needs are:

• Ionization and recombination rates
  • Collisional ionization, photoionization, etc.
  • Radiative recombination, dielectronic recombination, etc.
• Cooling rate coefficients (e.g., for a given ion at a given temperature)
• Collisional cross sections
• Charge exchange cross sections
• Photoionization cross sections
• Everything associated with plasma spectroscopy and radiative transfer (which would be huge amounts of data and would undoubtedly be too much)
• Ability to work with both Maxwellian and non-Maxwellian distribution functions

Occasionally there are nicely behaved functions that would be easy to implement such as the radiative recombination rate. Things like that are definitely worth including.

I am not sure what the best ways to proceed are. Some of our many options are:

• Include the most important atomic data within the core package (or not)
• Have an affiliate package that would be responsible for atomic data needs
• Have query or bridge routines within the core package that would get the requested atomic data from websites or the local directories that contain the databases
• Or instead, not include much in the way of atomic data within PlasmaPy and instead just put up some documentation that lets users know how/where to access atomic data using other databases/Python packages.

I am imagining that this will be a long-term conversation, but I figured it would be worth bringing up sooner rather than later. Any thoughts or ideas?

(see also #18 and #24)

As suggested in #43, we should add .swp files to .gitignore. These are files created when using the vim text editor that shouldn't be part of the repository. This is a great, straightforward issue for a first time contributor to work on.

A known issue with astropy.units is that some NumPy operations take in arguments that have units, but return arguments that do not have units even though they should. This issue requires an upstream fix in NumPy (e.g., numpy/numpy#4164). The SciPy 2017 talk on MetPy's Choice of Unit Support delves into this in great detail. An example from the talk:

>>> import numpy as np
>>> from astropy import units
>>> a = np.array([3.]) * units.m
>>> b = np.array([4.]) * units.m
>>> np.concatenate((a, b))
<Quantity [ 3., 4.] (Unit not initialised)>

There are some workarounds to some of these problems.

>>> np.isclose(500* u.km/u.s, 300 * u.km / u.s
UnitsError: Can only apply 'add' function to dimensionless quantities when other argument is not a quantity (unless the latter is all zero/infinity/nan)
>>> np.isclose(500* u.km/u.s, 300 * u.km / u.s, atol=1e-8 * u.mm / u.s)
array([False], dtype=bool)

We cannot do anything from within PlasmaPy, but will need to wait for fixes within NumPy (e.g., new support for __array_ufunc__ will improve overriding behavior for ufuncs).

@namurphy mentioned having talked with, if I remember correctly, NUMFOCUS people who said they'd put us on their web page if we had a website and a logo to go with it. The website is another issue, so let's discuss the logo here. Any suggestions for the design?

With the particle stepper pretty much being finished and live I believe we could begin thinking about including a full pic simulation within the code.

I don't think we need to focus on beating commercial and research codes at scalability, efficiency or speed, it'd be nice if that turned out to be the case, but it'd take a lot of effort and it's probably better to start small.

I think what would work better within open source is to have a simulation code that's feature complete, reliable, well documented, with ample test cases, visualization, something people could study and learn from, something you can compare results with. I know that part has been a pain in my experience.

It'd also be somewhat neat to have the same interface as the MHD simulation.

Generality is also nice, being able to easily replace and compare the numerical methods used seems like a good idea.

Of course, that doesn't mean we're going slow on it either, I'd like to start with numpy, numba and possibly add pycuda later on (that'd need a separate issue).

I've got a code of mine that I'd like to adapt here.

What does everyone think about this? I'd very much appreciate input and help with this one. Literature suggestions beyond Birdsall and Landon would also be nice!

Astropy contains a submodule called constants that contains commonly used constants from physics and astronomy. PlasmaPy should include a similar module with commonly used constants from plasma physics and related disciplines. PlasmaPy's module should make use of the powerful units functionality present in Astropy (e.g., from astropy import units).

A while ago, I registered plasmapy.org as a website for our project, though it is presently empty. Sometime before our v0.1 release, we should collaboratively build a website that contains overall information on the project to complement our documentation being created on readthedocs. We can probably begin our website using the Astropy website as a model, since we can continue to learn from them what they're doing. We will also need to make sure that the website is accessible (e.g., that it is screen reader/text-to-speech compatible, uses dyslexic friendly fonts, has controls to adjust font size and contrast, etc.). Thanks!

At some point we will need to decide on a versioning scheme. It'd probably be good to figure this out sooner rather than later so we can have as consistent a scheme as possible for the lifetime of the project. I looked into what other projects are doing, and ended up finding PEP 440 -- Version Identification and Dependency Specification which extensively describes a canonical format that is required in order for public releases to be compatible with setuptools and PyPI. I didn't read the whole thing as that page contains almost 10000 words, but the examples were helpful. I wrote up a draft versioning scheme below that is consistent with PEP 440 as something that we can start the discussion from, though I'm happy to change it. We could perhaps work towards a PLasmaPy Enhancement Proposal like APE-2 for Astropy that includes how we end up doing releases. Two things that are important are that the version is in a canonical format and that it behaves correctly:

>>> import re
>>> def is_canonical(version):    # appendix B of PEP 440...include as a unit test?
             return re.match(r'^([1-9]\d*!)?(0|[1-9]\d*)(\.(0|[1-9]\d*))*((a|b|rc)(0|[1-9]\d*))?(\.post(0|[1-9]\d*))?(\.dev(0|[1-9]\d*))?$', version) is not None
>>> is_canonical('0.0.1.dev1')
True
>>> is_canonical('0.0.1a1')
True
>>> from pkg_resources import parse_version
>>> parse_version('0.0.1a1') > parse_version('0.0.1.dev1')  # alpha release is newer than dev release
True

Here's my draft. Feedback and new ideas are appreciated, as this should be considered far from final!

The versioning scheme for PlasmaPy will be consistent with the canonical format described in PEP 440 in order for public versions to be compatible with setuptools and PyPI. Releases will use a [major].[minor].[micro] format with our first micro release being '0.0.1' and our first minor release being '0.1'. Development, alpha, beta, and release candidate versions will be appended by the pre-release tags '.dev', 'a', 'b', and 'rc', respectively, followed by an integer.

Here is a sample progression from older to newer versions:

0.0.1.dev1 # early development version prior to 0.0.1
0.0.1.dev2
0.0.1a1 # alpha version prior to 0.0.1
0.0.1a2
0.0.1b1 # beta version prior to 0.0.1
0.0.1b2
0.0.1 # micro release
0.1.dev1 # development version for first minor release
0.1a1 # alpha release prior to 0.1
0.1b1 # beta release prior to 0.1
0.1 # first minor release

The decision on when to change between development, alpha, beta, and release candidate versions will be made by the Code Development Committee with general community agreement. The trailing integer that follows pre-release tags should be incremented after appreciable changes to the code have accumulated in the development process.

I've been following a lot of the recent developments with PlasmaPy. Have discussions started about how experimentalists or data analysts will use the project? A lot of focus seems to be placed on simulations at the moment and I'm not sure that the paradigm forming will be appropriate for those (like me) who deal with spacecraft and other experimental data.

Most of the plasma parameters that we come across are non-relativistic. However, relativistic plasmas that are often of interest to our community. Eventually, we should come up with some functionality so that people can calculate and/or work with quantities like the relativistic Alfven speeds, and so on. It's been a while since I've thought about relativity so I'm not sure what the best way to do this is.

I found a few resources that might be useful (though I didn't look into them much):

• Chapter 6 of Relativistic Kinetic Theory by Gregory Vereschchagin is on basic parameters in relativistic gases and plasmas.
• Black Hole Gravitohydromagnetics by Brian Punsley has a chapter on relativistic plasma physics
• Relativistic Fluids and Magneto-fluids: With Applications in Astrophysics and Plasma Physics by A. M. Anile

task from #69 , for PIC simulation
For the Electrostatic PIC simulation, a Poisson solver will be needed.

• for 1D, Thomas Solver gives the exact solution. Boundaries have to be carefully set
• for 2D, a solver is needed. Multiples solvers could be implemented, starting from a homemade SOR, then libraries could be called. Boundaries again : careful
• Electric field calculation from Potential : warning the boundaries

We forget the 3D for Now. Boundaries can be : periodic, Dirichlet (Phi = Phi_0) or Neumann ( E = E_0) depending of the boundary.

A task from #69 , in the PIC simulation
We need particle initialization functions, like :

• uniform Maxwellian distribution
• Maxwellian flux
• drifting Maxwellian
• Mono-energetic beam

flux and beam direction should have as argument the position and the direction.
a temperature should be used of the energy (best in electron Volt)

It may be a good time to start scoping out which discretization and solver libraries the project will use to solve PDEs. It will be important to decide early on what kinds of parallelism will be supported (threading, MPI, GPU, etc).

One of the things that we should probably do sooner rather than later is to set documentation up for PlasmaPy on Read the Docs. We have a choice between reStructuredText (reST) and Markdown. For reST we would be using Sphinx. Astropy appears to be mostly using reST and Sphinx so I'd vote for mostly using that also since we can then ask them for help. :-) We'll also need to set up extraction of docstrings for the different methods within PlasmaPy.

These instructions look very helpful: Getting started with Read the Docs

Thank you!

Plasma physicists occasionally need to make use of more general areas of physics, including electromagnetism, mechanics, thermodynamics, relativity, and quantum mechanics. Many of the expressions that we occasionally use would be straightforward to include, though writing useful tests and detailed docstrings do take quite a lot of time. We can use this issue to brainstorm and plan different functionality.

With regards to organization, a possibility would be have files like quantum.py, relativity.py, thermodynamics.py, and so on. We use electromagnetism really frequently, so we probably want to split that up into multiple files. Some things may already be included in astropy or elsewhere.

Some ideas on things to include are:

• Lorentz_factor
• Relativistic momentum, rest energy, Doppler effect?
• de_Broglie_wavelength plus other stuff I can't remember because I avoid quantum mechanics even more than I avoid displacement current
• Bremsstrahlung
• Inductance, etc.
• Blackbody radiation (already in astropy, I think)
• Maxwellian distribution functions (plus kappa, Bose-Einstein, Fermi, other distributions?)
• Biot-Savart law to go from static currents or current density to magnetic fields, plus the forces on current carrying elements. Something similar for electrostatics.
• Magnetic field of a dipole

Any more thoughts and ideas would be appreciated!

At present there are two parts of the repository that fulfil the role of a code of conduct: vision_statement.md and CODE_OF_CONDUCT.md. The section from the vision statement is adapted from Astropy, and the code of conduct file is adapted from the contributor covenant standard. There may be some inconsistencies between the two, so it would probably be best to merge the two and keep it in one easily found place.

We also need to clarify the procedure for how violations of the code of conduct are dealt with (e.g., who complaints are submitted to, what procedure they undertake, what the consequences will be, etc.).

You can do pip install astropy. The rest seems self-explanatory.

It's nothing urgent, if we want to wait until this is somewhat feature-stable, that's completely fine. I suppose we're going to want to be out there eventually, though.

In addition to the Biot-Savart law solver proposed in #99, we should have a way of calculating the magnetic fields resulting from simple current-carrying wire setups. This would include the magnetic field from an infinite wire (which has a simple exact solution) and the magnetic field resulting from a circular current-carrying loop (which has a complicated exact solution) for boundary conditions at infinity. There might be other analytical solutions worth including, but these two are probably the most important ones.

This could perhaps go in the physics subpackage in a file called magnetostatics.py.

When dealing with plasma waves, it would be helpful to have a dispersion relation solver.

This was recommended by John Raymond. I believe Carl Sovinec wrote a code that this several years ago, though not in python.

This is somewhat related to #36. We need to be accessible and most of the cutting edge scientific Python is on Conda, probably due to ease of downloading stuff like C extensions, Numba etc.

Anyway, this gets closed once we can do conda install plasmapy in a new environment and have it work out of the box.

I haven't been able to find a how-to on this yet. I'll update this issue if I find anything.

https://conda-forge.org/ this is at least 70% relevant.

@bla1089 and I were just talking in person and ran into the following question: What package or packages should we use to store data?

Some possibilities include:

• NumPy (which we are mostly using thus far)
• pandas
• xarray
• yt

Some of the qualities that I think would be very much worth having are:

• Units-aware or units-compatible
• Ability to label dimensions (like pandas does for 1D and xarray does for multidimensional arrays)
• Compatible with flexible data sources
  • Common data types used by lab, space, astro, and solar
  • Fluid and particle representations (yt has better particle capabilities since the "demeshening")
• Can be easily installed using tools like conda
• Wide user/developer community
  • Ideally, we be able to make upstream contributions too
• Fast and easy-to-use

This is related to #66 and #59, including this comment.

Maybe this topic would be a good thing to write our first PlasmaPy Enhancement Proposal about! (I'm hoping that our zeroeth PlasmaPy Enhancement Proposal will be to have a GitHub repository for bad poetry about eigenfunctions.)

Previously seen on 2017-08-22 telecon. I can do some narrative doc writing, just point me in a general direction!

Did you guys mean documentation for PlasmaPy as a thing in general by this, as well?

Before we do anything else, we must first establish the minimal structure of a python module.

Minimal Structure - Python Packaging Tutorial