Create abstract base class as interface for plasma normalizations #859
Conversation
I expect that an abstract base class will be helpful here because will be different normalizations for different ways of representing plasma (e.g, ideal, resistive MHD, or extended MHD normalizations are different than normalizations used for PIC simulations. I'll tentatively keep this in, but we can re-evaluate how useful it will be later on.
Codecov Report
@@ Coverage Diff @@
## master #859 +/- ##
==========================================
- Coverage 96.29% 95.92% -0.37%
==========================================
Files 62 60 -2
Lines 5715 5471 -244
==========================================
- Hits 5503 5248 -255
- Misses 212 223 +11
Continue to review full report at Codecov.
|
This includes a placeholder test.
|
This pull request has been mentioned on PlasmaPy Community Discourse Forum. There might be relevant details there: https://plasmapy.discourse.group/t/ideas-for-how-we-can-use-normalizations-objects/44/1 |
|
For this pull request, I'm thinking that I should focus on getting the normalizations in there in the proper form with sufficient documentation. It'll probably be best to have follow-up pull requests that deal with how an object containing normalizations can be used in operations. Best to limit the scope of pull requests, as we've learned...
|
I would just like to note that this was an automation that I forgot I set up and holy wow, did I just give myself a brief moment of existential doubt. |
This PR is still very much a work in progress
I'm downscoping this pull request to only create an abstract normalizations class, so for the moment there are no tests.
I'm downscoping this pull request to only be for an abstract base class. I'm planning to later on re-implement the class that was removed, which was called MHDNormalizations.
namurphy
changed the title
|
I decided to downscope this pull request. This PR now creates a first attempt at an abstract base class, I'm thinking it would be really helpful to have a function that takes a unit and returns a list of corresponding physical types, and a function that takes a physical type and then returns the appropriate SI unit. I'd probably use this functionality a lot since I often have to figure out what units are for a particular quantity (like thermal conduction). This is related to what I brought up in astropy/astropy#11202. In any case, I'm still thinking about the best strategy for creating classes like |
|
Also, you should be proud that I alphabetized the attributes contained in |
It is beautifully organized! 🔤🤣 |
|
Something to think about for the future... This feels like a |
plasmapy/simulation/abstractions.py
Outdated
| @property | ||
| @abstractmethod | ||
| def ion(self) -> Particle: | ||
| """ | ||
| The ion in the plasma, which could be a positron in the case | ||
| of a pair plasma. | ||
| """ | ||
| ... |
There was a problem hiding this comment.
An ion isn't really a normalization. It's mass could be a normalization, or it's gyrofrequency could be. I would remove this method and leave it up to the user to manually define/calculate the other normalizations.
There was a problem hiding this comment.
Yeah...I've been wondering how to handle ions in the normalization, since how to handle ion stuff make normalization stuff kind of messy...in particular for how we handle multi-component plasmas. Ultimately I'd like for there to be normalization classes that allow operations like:
>>> dimensionless_plasma = dimensional_plasma / normalizations
>>> dimensional_plasma = normalizations * dimensionless_plasmaFor these to work we'd need information on the ion(s) somehow, so the choice of ion(s) do end up weirdly more or less being part of the normalization...in particular for the normalization between number density and mass density. I'll remove the ion attribute for now, and worry about how to deal with this next year.
ugh why won't 2016 just end already
There was a problem hiding this comment.
ugh why won't 2016 just end already
I know! Longest year eveeeeeeeeeer! Completely feels like 4+ years.
Well, that will be an interesting implementation. I like it, but I have no clue how to go about implementing it. Might be easier to have something like dimensionless_plasma.reform(normalizations) and dimensional_plasma.reform(normalizations). I only used reform to keep the name consistent across all plasma classes.
Co-authored-by: Erik Everson <[email protected]>
There's discussion about this in PlasmaPy#859. Ions are a weird part of the normalization, and we'll need to think more about how to handle them in a consistent way.
Co-authored-by: Erik Everson <[email protected]>
namurphy
added
plasmapy.simulation
This pull request includes new classes that describe standard normalizations that are used for ideal and extended MHD. The purpose of these classes is to have a standard way to represent normalization information that can be used for different codes and groups. Actually, I would have found these classes to be really helpful for a simulation benchmark project that I'm working on so that I didn't need to create them from scratch. I'm most familiar with the fluid approximation normalizations so I'm starting with those, but we'll also need to create normalizations for PIC simulation (where length is often normalized to the ion inertial length and time to the inverse of the ion gyrofrequency). I still have a lot to do for this, so it's lower priority for code review at the moment.
docstrings.
Closes #808.