---
# System prepended metadata

title: 'PlasmaPy community meeting agenda and minutes - Tuesday 2020 December 1 at 19:00 UT'
tags: [community, ' minutes']

---

---
tags: community, minutes
---

# PlasmaPy community meeting agenda and minutes - Tuesday 2020 December 1 at 19:00 UT

[![hackmd-github-sync-badge](https://hackmd.io/utyUOJGlSm6SClXhGBju4A/badge)](https://hackmd.io/utyUOJGlSm6SClXhGBju4A)

### Video Conference Information
* [Jitsi video conference link](https://meet.jit.si/plasmapy) with [call-in information](https://meet.jit.si/static/dialInInfo.html?room=plasmapy) 
* Instant messaging: [Matrix](https://app.element.io/#/room/#plasmapy:openastronomy.org) and [Gitter](https://gitter.im/PlasmaPy/Lobby)
* [PlasmaPy google directory](https://drive.google.com/drive/folders/0ByPG8nie6fTPMEIxTlZLZjdjYms?usp=sharing) ([minutes/agendas](https://drive.google.com/drive/folders/0ByPG8nie6fTPV1FQUEkzMTgtRTg?usp=sharing), [documents](https://drive.google.com/drive/folders/0ByPG8nie6fTPYzk2TEhTa1N6R0U?usp=sharing))
* [PlasmaPy on GitHub](https://github.com/PlasmaPy/plasmapy) ([pull requests](https://github.com/PlasmaPy/plasmapy/pulls), [issues](https://github.com/PlasmaPy/plasmapy/issues))
* [PlasmaPy Enhancement Proposals on GitHub](https://github.com/PlasmaPy/PlasmaPy-PLEPs) 
* [PlasmaPy Google Calendar](https://calendar.google.com/calendar?cid=bzVsb3ZkcW0zaWxsam00ZTlrMDd2cmw5bWdAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)

## Agenda (please feel free to edit or add items)

1. Introductions
2. 10-15 minutes on roadmap
3. [Dominik] Neoclassical transport! How best to do it?
4. [Nick] FESAC (Fusion Energy Science Advisory Committee) Long Range Planning report release on Dec 4
    1. With FESAC meetings on Dec ``[7, 8, 10]``
6. [Nick] AGU meeting this week...and next week...and the week after
7. [Nick] Release of pip 20.3ish
8. [Nick & Erik] Paschen document from Christoph (if time)
9. Issues
    1. ...
    2. ...
10. Pull requests in progress 
    1. [PR #932](https://github.com/PlasmaPy/PlasmaPy/pull/932): Dispersion (Bellan soln)
        * [Minutes dispersion meeting last week](https://github.com/PlasmaPy/plasmapy-meeting-
    3. [PR #920](https://github.com/PlasmaPy/PlasmaPy/pull/920): Test Refactor #2
    4. [PR #909](https://github.com/PlasmaPy/PlasmaPy/pull/909): Fields and Grids
    5. [PR #953](https://github.com/PlasmaPy/PlasmaPy/pull/953): ParticleTracker improvements
    6. [PR #796](https://github.com/PlasmaPy/PlasmaPy/pull/796): Ionization states classes & docs — would be helpful to have in for v0.5 for NEI affiliated package
    
## Attendees

* Erik
* Nick
* Dominik

## Action Items

***Nick***
  * Post about Hack Week to try to get volunteers
  * Reach out to Jimmy Juno and others about Simulation Working Group

***Erik***
* open PR on `mass_density` and `Alfven_speed`
* then complete next review on PR 932
* **put Transport on roadmap**

***Dominik***
* open Discourse thread on neoclassical transport to seek suggestions etc
* will release v0.5.0 by December 6th (& will record the process to post to YouTube)

## Minutes

* **ROADMAP**
    * In the roadmap literature link back to Discourse tags/flags for appropriate discussions
    * Consider moving to date based versioning `YYYY.MINOR.MICRO` (when shoudl this be done?)
        * could help with citation and traceback
        * would require a new release in Q1 of each year
        * https://calver.org/
* Fusion Energy Sciences Advisory Committee (FESAC)
    * Nick might not make next weeks meeting because of this
    * report release Dec 4th
* Review of PR 932 got stalled due to patching `mass_density` and `Alfven_speed`
    * patch nearly complete just needs test updates
    * will open PR this week
* Not sure yet how best to put in neoclassical transport
    * Probably should take a look at `ClassicalTransport` and figure out how to make it more usable, etc.
    * **It'd be helpful to include neoclassical on roadmap**
    * Neoclassical transport is what you get when you include toroidal effects and drifts into orbits (e.g., banana orbits, weird geometrical effects)
        * There's also anomalous transport e.g. turbulence
    * Goal of Dominik's thesis is to include neoclassical transport coefficients, in partiular for impurity transport
        * How to best implement this?
        * Lots is specific to fusion reactors
        * Transport models are largely 1D because dealing with magnetic flux surfaces; averaging over closed flux surfaces
        * Classical transport doesn't include toroidalnessicity, no :banana: 
        * Now implementing most basic approximation (large aspect ratio and circular cross section...which won't fly in a stellarator)
        * How to put that in requires tokamak infrastructure in place.  We don't have that yet.
        * For now, analytical approximations.
        * Eventually, implementing some numerical calculations
    * The more we talk about transport, the more it seems like `transport` should be its own subpackage of awesomeness and despair
        * Should put it into a roadmap: what do we want to include in that subpackage?  For classical, neoclassical, etc.
        * Maybe a flow chart of what's in each of them (or UML diagram?)
        * Should get in habit of starting Discourse thread so we can throw down the ideas.  Maybe if Discourse has subforums, we could use those, e.g., for discussions on transport.  Maybe keep a flat structure with tags rather than nested with subforums
* [GitHub discussions](https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions) could replace discourse in the future
* Christoph sent Erik & Nick a white paper on the Paschen curve
    * Should create an issue for it, using known materials ahead of time
    * Incorporate it with `Particle`?  Functions that work with `Particle`?  Maybe `get_Paschens_properties` that would call on `Particle`...not packaged in `Particle` but `Particle` is used to get it. Maybe a `dict` with `Particle` instances as keys?
* Will GitHub render banana emoji?
    * Probably.
* Would it be helpful to move to date based versioning?  (e.g., `2020.04`)
    * We keep breaking backward compatibility in research software engineering, so is semantic versioning really the best?
* Would be helpful to merge #796 before `0.5` because names of functionality changed 
* We have a stability matrix in the docs...it really needs to be updated
    * Maybe put it on the landing page of the documentation?
    * Probably better to link to it from README file, and maybe link to it on the landing page.  
    * Advertising maturity of subpackages would be a good thing
* Nick will try working on scientific reproducibility paper, but will try to keep up with code reviews also.





