---
tags: simulation, minutes
---

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

### Video Conference Information
* [Zoom link](https://zoom.us/j/91633383503?pwd=QWNkdHpWeFhrYW1vQy91ODNTVG5Ndz09)
* 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 Enhancement Proposals on GitHub](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. Goals of working group
3. Possible research software engineering process
* Collecting use cases
* Writing a software requirements specification
* Designing high-level software architecture in a PlasmaPy Enhancement Proposal
5. Open discussion

## Attendees

* Nick
* Marissa
* Jimmy
* Dominik
* Nivedan
* Steve

## Action Items

***Person***
* ...

## Minutes

* Apparently lvl30 unlocks buffs to sending out scheduling poll, according to Nick
* Introductions, Jimmy being at Iowa, Gkeyll; Marissa, Rochester, FLASH; Dominik, plasmapy contributor, running simulations in general, Nivedan, senior graduate student in mechanical engineering; Nick, fundamental plasma stuffs, contributor of plasmapy, advocating for open science; Steve Richardson, NRL, modelling for wave propagation in plasmas/magnetic vorticities, jack-of-all-trades kinda guy.
* biggest plasma simulation pain points:
* happily doing spectral simulation and suddenly, shocks arise!
* need to spend a few months picking up another code
* usage
* installation
* ...
* ["The Biermann Catastrophe"](https://arxiv.org/abs/1408.4161) - nonphysical shock terms
* FLASH has a shock detection algorithm to handle non-convergent cases
* infrastructure to help numericists calculate error due to resolution?
* verification & validation, but do people talk about actual *error* in simulation?
* one of motivations for TurboPy - "I know this method is valid in some limit compared e.g. to cyclotron frequency": have something watching that parameter and informing you when your modeling assumption might be incorrect
* can PlasmaPy develop a common interface to run different codes?
* flash has `20 * u.Y` of development
* most codes have a special scripting layer
* PlasmaPy could become this common scripting layer
* quick identification of whether a tool is suitable for your needs
* code maintainability in Gkeyll - how to introduce abstractions between core algorithms and IO/etc
* much easier to install something like PlasmaPy rather than Gkeyll
* [GEM reconnection challenge](https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/1999JA900449) - potentially even as a student homework project using PlasmaPy in the ideal world where we do get this done
* Steve works with PIC codes
* getting everything interop from PlasmaPy is a huge darn challenge
* PIC codes are so wildly different from fluid codes...
* infer suitable code from what you're trying to solve for?
* cohort/group of computationalists/numericists in plasma physics?
* if we could, email/survery them: what tools would be useful?
* [International Conf on Numerical Simulation of Plasmas](https://www.lanl.gov/calendar/2019/September/0903-cnls-conference.php)
* small steps:
* common interface for output files?
* [OpenPMD](https://www.openpmd.org/#/start)
* They have a reader for paraview
* could we similarly leverage [yt](https://yt-project.org )?
* Parallel tracks for different goals...need to do resource management
* Wrapping Gkeyll core (G0) in PlasmaPy as an early goal (Dominik & Nick interested in working with Jimmy)
* Will PlasmaPy be "glue" or will that run the simulations?
* Most sim codes have a scripting layer to define ICs. Could do a scripting layer too.
* PlasmaPy API to give a common interface
* From chat:
* My opinion: I think making plasmapy a wrapper and executing other codes is a very ambitious goal that might be unattainable (?) I view plasmapy being a tool before and after executing codes to make the decision process easier (e.g. what kind of problem are you trying to solve? what code is best? ... after? Synthetic diagnostics perhaps?)
* I guess we could try implementing the 'what kind of problem are you trying to solve' thing by condensing our problem into dimensionless quantities. For example, in fluids, we know the transition point from a continuum approximation (where we use conventional CFD codes) to rarefied approximation (where we use particle methods) using the Knudsen number. I am not sure if we can try the same thing for plasma, but this is all I could think of at the moment
* Worry: ratio of ambitiousness to human resources
* !! SOFTWARE PLANNING !!
* UML architecture
* What inspiration can we take from software development communities in general and adopt those practices?
* Next step: use cases (e.g. GEM reconnection challenge as a homework problem) --> benchmarking beween different codes; visualization needs
* e.g. What limiter to use for your FVM?
* Making sure that in the minutes (:)) that the ideas that we have are being captured correctly; these minutes will probably useful in the future!
* Another meeting in two weeks at this time! Yay!
* Example from PlasmaPy Enhancement Proposals (PLEPs)
* "What might you want to do with a plasma object?"
* Abstract base class; defining the API; plugin architecture for a post-processor
* e.g. A subclass that knows the output of a PIC code, the ABC knows, then we can do synthetic diagnostics
* Launching tokamaks into space: putting the space back into "space plasmas"
* GEMEM
* and then we can make GEMEMes about it
* 😹