PLEP on next generation plasma simulator #24
Conversation
This is just a start and I still need to add the entire description of the software architecture.
I moved the discussion on alternative languages to the alternatives section, and put it into the form of a bullet point list.
This is still a work in progress and I am still trying to figure out the best way to structure this PLEP.
|
This PLEP is proposing work of a very large scope, which would require finding funding so that a few people can work full time on it for a few years. When this proposal is in a pretty good shape, I am wondering if we could merge this PR while keeping it in the discussion phase, and make it clear that it has not been decided upon. Alternatively, a possibility would be to provisionally accept it on the condition that funding become available. I really think that this is ultimately the best way forward for PlasmaPy's simulation capabilities and plasma simulation more generally, though finding funding for research software infrastructure is likely to remain a challenge for the time being. |
The current abstract might be a bit long, but that might be okay since there are a lot of important points I want to make.
I changed this section so that it includes a list of problems or current practices, each of which is followed by solutions or alternatives. I think this approach is more constructive. The downside of this section is that it is becoming very long. However, many of these problems may not be recognized as problems by people doing plasma simulations, so it is important to name them in the language the dragons speak and offer potential solutions that can be implemented in this framework.
…into PlasmaSimulator
| * Minimize the time, effort, and frustration needed to achieve | ||
| scientific understanding through numerical simulation; and | ||
|
|
||
| * Maximize scientific and computational reproducibility. |
There was a problem hiding this comment.
Well stated goals! Makes it clear that this doesn't compete with existing state of the art codes (as it probably shouldn't try to).
PLEP-0007.rst
Outdated
|
|
||
| .. A possibility for this section would be to transform it into its | ||
| own article and call it something like "Plasma simulation in the | ||
| 24½th century" |
| simulate burning plasmas. Often prospective users must sign a user | ||
| agreement form that restricts modification and/or redistribution. | ||
| Such restrictions reduce scientific reproducibility and transparency | ||
| of research. |
There was a problem hiding this comment.
What's a polite way to add "and increase possible eff-ups resulting from bugs that someone could have caught with code out in the open"?
| **Solution: Develop openly under a permissive open source license.** | ||
| Open development maximizes scientific reproducibility and | ||
| transparency. Open source software often contains fewer bugs because | ||
| more people end up using and reading the code. Choosing a permissive |
| getting a code to work in the first place can provide a significant | ||
| barrier to entry for newcomers who may have little experience with | ||
| make files and shell scripts. Lack of documentation exacerbates this | ||
| problem. |
There was a problem hiding this comment.
There's the issue that most of those (I have little experience myself) are probably meant to run on supercomputer grids rather than user machines, laptops even... this sure is an issue, but the disconnect between supercomputer and user architectures is likely a major factor as well.
| managers. | ||
|
|
||
| - Do not require users to compile external libraries, edit make | ||
| files, change compiler flags, or run bash scripts. |
There was a problem hiding this comment.
"... unless it helps performance" for the HPC-minded? This is a pretty strict requirement. I fully understand why it's here, though - I'm just pointing out a possible point of contention.
|
|
||
| * Design the package to run in Linux, macOS, and Windows environments | ||
| and on scales ranging from a single core to the most powerful | ||
| supercomputers. |
There was a problem hiding this comment.
Do these even have any overlap?! It's going to be hellishly difficult to ensure the same efficiency on supercomputer Linux and on a home Windows laptop...
| * Provide a Python interface to the core functionality. | ||
|
|
||
| - Include this interface in PlasmaPy or an affiliated package in the | ||
| PlasmaPy ecosystem. |
PLEP-0007.rst
Outdated
| physical models and numerical methods. | ||
|
|
||
| .. Create a class or object that represents the dependent variables so | ||
| that it can be used when creating the other classes when needed? |
There was a problem hiding this comment.
Is it just me, or is there a FEniCS vibe here? :)
|
|
||
| - Implement finite element/spectral element capabilities. | ||
|
|
||
| - Provide shock capturing algorithms. |
There was a problem hiding this comment.
Okay, on seeing this list I think I have to concede a point to @tulasinandan: that is indeed a lot of work.
| used interchangeably. | ||
|
|
||
| - Keep a similar API to fluid-approximation simulations at high | ||
| levels of abstraction. |
There was a problem hiding this comment.
We would also need a flexible enough Simulation (or something) class that incorporates mesh data (generically) and particle data (for PIC). Hell, if we wanted to have this be truly generic... some simulations are not going to have a mesh whatsoever. As an example: https://journals.aps.org/pre/abstract/10.1103/PhysRevE.98.033307
In other words, both mesh data and particle data might need to be optional in the very long run.
| levels of abstraction. | ||
|
|
||
| * Implement standardized formats and metadata naming conventions for | ||
| output data. |
There was a problem hiding this comment.
which also reminds me that https://github.com/openPMD/openPMD-viewer is a thing and that we could potentially collaborate with those folks on this!
There was a problem hiding this comment.
Yep, definitely! I got the phrase "metadata naming convention" from OpenPMD.
| necessary, but might not be worth discussing here. | ||
|
|
||
| .. Users will be able to generate the grid after the domain is | ||
| specified and the numerical method is chosen. |
There was a problem hiding this comment.
People might also want to load grids from existing geometry generators, say, field line setups in tokamaks... Out of scope for now?
There was a problem hiding this comment.
We're taking the Borg approach for plasma simulation code development, so it will be in scope eventually!
|
|
||
| .. Users will have varying amounts of control over how the simulation | ||
| is performed. If no special processing is required, then users | ||
| would be able to perform the simulation in a single command. |
There was a problem hiding this comment.
I'm voting for .engage(*args, **kwargs) as part of the API!
| can be substantially different and potentially incompatible. | ||
|
|
||
| .. I'm not sure how to handle this yet, particularly because I do not | ||
| know enough about boundary conditions for PIC simulations. -Nick |
There was a problem hiding this comment.
All I know is, as before, this is difficult.
| in Julia (see `Julia issue #6875 on GitHub | ||
| <https://github.com/JuliaLang/julia/issues/6975>`_). An alternative to | ||
| ABCs would be to create a macro that checks that a particular class or | ||
| class instance has all of the required methods. |
There was a problem hiding this comment.
I'm not even 100% sure we need ABCs. Simple classes that don't check whether the subclass implements every method but implements what it does with a common API, with a well-designed inheritance pattern for the base classes, could also do the trick.
| - Not currently well-suited for massively parallel computing | ||
| - **Does not provide a full language solution to the performance | ||
| vs. productivity conundrum** | ||
|
|
There was a problem hiding this comment.
I'll write a few lines on Python with CuPy here later...
Co-Authored-By: namurphy <[email protected]>
I still need to address most comments from GitHub.
|
Right now I'm thinking that it would be best to extract the use cases and software requirements specification into separate documents that could be versioned and uploaded to Zenodo. These documents would need to continue being updated even after acceptance of this PLEP. In other words, yep, I'm getting way too detailed in this! |
This pull request will contain a proposal for how we can create a next generation plasma simulator for the PlasmaPy ecosystem. This is only in draft form so far. My hope is that we can use abstract interfaces to make a modular framework for which different numerical method implementations can be interchangeable. Then by having a common problem definition formulation, we would be able to switch back and forth between (for example) fluid and PIC simulations which would make it much more straightforward to perform benchmarks.
The more I think about it, the more I believe Julia to be the best language choice, as it is a full language solution to the productivity vs. performance (alleged) dichotomy. Plus it can do petaFLOP calculations! Julia can be called from Python, which would allow us to include it in PlasmaPy or an affiliated package.