I've also been thinking now and then about a survey that focuses on what functionality the plasma community would find useful.
Hey everyone, here's a friendly reminder that we've got our weekly community meeting in 35min, with the minutes here and the usual Jitsi link here :)
and was just being all around unstable today :(
Yeah, I'm not sure why screen sharing on Jitsi was grumpy today.
Frankly, I think this board is to negative about our corporate Zoom overlords
Alas, I must now get back to composing sea shanties that describe the differences between IDL
.genx and IDL .geny files.
Hi Nick! If you want to play with the 'kamodofied' version of PlasmaPy, I put it on github. Currently, you just download the code into the same directory you want to work in and go for it. The required environment is described in the readme file on github, and a demo notebook is included. The github link is https://github.com/rebeccaringuette/KamodofyPlasmaPy.
It can't handle tensors, classes, or other special objects, but everything else works fine. Maybe this is something y'all can add if you want? Another feature I haven't added yet is an auto-lookup function. The function directory structure is hard-coded from PlasmaPy a few versions ago, which is definitely a weakness. I'm currently on another project right now, but I hope to get back to this auto-lookup feature before the big PyHC meeting.
I'm hoping you can use this interface to build on kamodo's plotting capabilities so you won't have to write your own. I and the Kamodo team would be happy to help with the process! Also, we should talk about how to improve the documentation so that the function representation can also improve. I'm not on here often, so if you have questions just email me at rebecca.ringuette@nasa.gov or anyone on the Kamodo team. Cheers!
So, I’m not going to be able to make the meeting today. The 2nd vaccine shot has wiped me out.
1 reply
No worries whatsoever. Please take the time you need to rest and recover. I hope you feel better soon!
Yes, moderna. I thought I was going to get off easy since I was feeling great all last night. But no, I woke up at 5am w/ a fever, feeling achy, and a headache. I’m still out of it, but not as bad as at 5am, except for the headache.
You didn't miss much; we did make a bunch of progress on closing old PRs, though, so that was pretty productive.
Hey Nick Murphy, a question. Would you say that there are places where
Particles should be mutable? What about CustomParticles? IonizationState objects?
Good question! That's one that I've been wondering about too. Regular
Particle objects should be immutable. There might be some use cases where CustomParticle objects should be mutable...like for a dust grain in the interstellar medium that accretes or ejects electrons. I don't know how often that would come up. IonizationState stuff should be mutable for cases of time-dependent non-equilibrium ionization (i.e. a plasma that starts out cool and then gets heated more quickly than ionization can keep up with).
I've been wondering if
Particle should be a dataclass. CustomParticle and DimensionlessParticle too.
Well, you nailed the point of the question, there :)
I thought I had raised an issue about turning
Particle into a dataclass, but it turned out it was just a dream, and GitHub doesn't have a dream API.
I'd be in favor of immutability for CustomParticle as well; if it's ever needed needed for time-dependent stuff, we can make a custom object for that
Making
CustomParticle immutable does sound reasonable to me. Right now it's mutable.
Sounds just right for the dataclass refactor, then!
I'm asking because I've had a few ideas for IonizationState's (and IonicLevel's) immutability after falling down a rabbit hole on hashability. Basically, if you want something to be hashable (thus, be a dict key), you should keep it immutable. I'm sidestepping the issue by using the ionic symbol as a key for now.
To me it seems reasonable to have
IonizationState be mutable since that's something that often ends up changing over time.
Come to think of it...we might start thinking of immutability and mutability in terms of whether it makes sense physically.
Yeah, that sounds reasonable enough - unless you represented a series of time snapshots by a bunch of
IonizationState objects.
Well, it's not something I'm suggesting we change overnight :D
Oh wait I mean
True!
Changing
CustomParticle to be immutable would be a good first step. I'll create an issue on that right now.
Particle is hashable, it's set up to have the same hash as the particle symbol too.
Yep I totally did it because it makes sense and not because I was having too much fun with Python
Would making
CustomParticle immutable have advantages when using, say, Numba?
At least not AFAIK
I was thinking about Peter's issue with particles and scipy optimize
I have no idea whether immutability would help out with that, though
It'd be worth giving some more thought to whether or not there are other use cases for keeping them mutable. I can't think of many at the moment...which could either be because there aren't many cases, or because of pandemic brain.
And also — thank you for bringing this up! This has also been in the back of my mind lately too.
Another wacky IonizationState question! We can currently do something like this:
all_species = IonizationStateCollection(
{
"H": [0, 1],
"C": [0, 0, 0, 0, 0, 0, 1],
},
n0=1e20 * u.m ** -3,
abundances={"H": 1, "C": 0.08},
T_e=10 * u.eV,
)And that represents, well, a blob. But... suppose we could put arrays in? Even 1D arrays would be pretty helpful for my usage. I'm going to need 1D profiles (for each flux surface) of each ion's density and temperature for thesis purposes. I could either stick the 1D arrays in IonizationState or I could build each IonizationState from 1D arrays of parameters in a for loop. Of course, the issue then is that I'm looping at the pure python level.