---
tags: simulation, minutes
---

# PlasmaPy Simulation Working Group Meeting | Thursday 2021 September 30 at 16:00 UTC

### Video Conference Information
* [Zoom link](https://www.plasmapy.org/zoom)
* Instant messaging: [Matrix](https://app.element.io/#/room/#plasmapy:openastronomy.org) and [Gitter](https://gitter.im/PlasmaPy/Lobby)
* [GitHub Minutes Repository](https://github.com/PlasmaPy/plasmapy-project/tree/master/minutes)
* [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](https://github.com/PlasmaPy/PlasmaPy-PLEPs)
* [PlasmaPy Google Calendar](https://calendar.google.com/calendar/embed?src=c_sqqq390s24jjfjp3q86pv41pi8%40group.calendar.google.com&ctz=America%2FNew_York)

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

1. Introductions
2. [Nick] `Normalizations` classes as a way to reduce brain ugh when benchmarking codes with different conventions
3.
4.
5. Writing PlasmaPy Enhancement Proposal?
6. Decide on action items: what are next steps?
7. Standing items
* [Issues](https://github.com/PlasmaPy/plasmapy/issues)
* [Pull requests](https://github.com/PlasmaPy/plasmapy/pulls)

## Attendees

* Nick Murphy, Marissa Adams, Dominik Stańczak, Luciano G. Silvestri, Steve Richardson

## Action Items

***Nick***
* Set up a hackmd thing for use cases
* Put in a couple of use cases as examples
* Email everyone about it
* Set up a time to meet with Jimmy

## Minutes

* We all introduce ourselves! Exciting
* Nick: Multi-fluid and PIC code; the two different codes use normalizations --> create a class for normalizations?
* dimensional_results = dimensionless_thing * normalizations
* [Pull request](https://github.com/PlasmaPy/PlasmaPy/pull/1029) to create a class for the set of normalizations that Nick normally uses that are fluid oriented
* One issue: many different way of normalizing things but folks may be use to one particular way; does this seem like a useful thing? What other ways are there to normalize things?
* Jimmy: You have a nice parameters class that define types of quantities such as Alfven speed, etc, but there may be ways of normalizing in a generalized fashion? What are the base quantities?
* In Gkeyll, frequencies are normalized to the plasma frequency for instance; can pick either proton or electron mass for convenience; density normalization; reference temperature (tells you how relativistic the system is)
* Marissa: is the question "is there a way to generalize normalizations? can e.g. PlasmaPy provide a easy interface for the community?"?
* is there a way to pick arbitrary quantities for your "base" units and easily convert between them?
* currently: hard-coded fluid simulation units; use essential MHD equations to pull normalizations out;
* Jimmy: it's a hard problem to take quantities and equations and get normalizations.
* kinetics/multifluid - multiple fluids - arbitrary choices (Alfven/sound/thermal velocity?). Codes which give you some flexibility often convert to some preferred choice for plotting. "Convert to whatever you'd like" sounds like a difficult computational task.
* Can see how you'd do it for a fluid code. For multi-fluid/kinetics - it becomes very ambiguous very quickly, due to the many choices
* more "supporting infrastructure" stuff - for interaction with potential initial/boundary condition classes?
* Marissa: maybe let's start with a dimensionless
* "Are things dimensionless in GKEYLL?" - highlight of the day!
* GKEYLL either requires you to specify a normalization or pulls constants from NIST table by default (didn't quite get that point)
* Luciano: problem with units in molecular dynamics code. Decided: make executive decision to give people two choices - MKS/CGS. Always a 2pi difference somewhere! Pick a standard and keep to it.
* Dominik: can't always go with MKS due to round-off error propagation. Jimmy: affects you more when you're going with say a billion timesteps.
* can be important for reproducibility, too!
* Jimmy: [Astropy units package](https://docs.astropy.org/en/stable/units/) is flexible enough that you can achieve most things with it; let's not
* [astropy PhysicalType](https://docs.astropy.org/en/stable/api/astropy.units.PhysicalType.html)
* Steve: there are sometimes natural scale lengths, and then your equations can be turned into non-dimensional forms. It can be useful, but doesn't necessarily translate. "Let's scale everything by the plasma frequency" - but MHD (correct me if I got this wrong) already sets that to zero. NRL codes are often used with real units because of need to communicate with actual real device engineers. Different kind of plasma physics
* Jimmy: GKEYLL interface defined around user defining normalizations: c=1, m_e =1 in input file. Might as well do c=nist.constant.c. Doesn't matter, really.
* You might run a simulation for engineers in real units, but...
* Postprocessing has its own set of "useful" normalizations.
* Let's get a prototype going in the next 2 months (DPP and stuff...)
* Next steps
* Compiling use cases for plasma simulation