Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 04:55

    StanczakDominik on master

    Changes for sphinx 4 (#1142) *… (compare)

  • May 13 20:31

    rocco8773 on master

    A version of automodapi for Pla… (compare)

  • May 13 15:25

    StanczakDominik on master

    Update .pre-commit-config.yaml (compare)

  • May 13 15:21

    dependabot[bot] on github_actions

    (compare)

  • May 13 13:15

    StanczakDominik on master

    CI fixes (#1141) (compare)

  • May 12 07:38

    dependabot[bot] on github_actions

    (compare)

  • May 12 07:38

    StanczakDominik on master

    Bump actions/checkout from 2 to… (compare)

  • May 12 07:38

    dependabot[bot] on github_actions

    (compare)

  • May 12 07:37

    StanczakDominik on master

    Bump codecov/codecov-action fro… (compare)

  • May 12 07:37

    dependabot[bot] on github_actions

    (compare)

  • May 12 07:37

    StanczakDominik on master

    Bump actions/setup-python from … (compare)

  • May 12 06:16

    dependabot[bot] on github_actions

    Bump actions/setup-python from … (compare)

  • May 12 06:16

    dependabot[bot] on github_actions

    Bump actions/stale from 3 to 3.… (compare)

  • May 12 06:16

    dependabot[bot] on github_actions

    Bump codecov/codecov-action fro… (compare)

  • May 12 06:16

    dependabot[bot] on github_actions

    Bump actions/checkout from 2 to… (compare)

  • May 11 23:30
    namurphy edited #1126
  • May 10 19:47

    pre-commit-ci[bot] on pre-commit-ci-update-config

    [pre-commit.ci] pre-commit auto… (compare)

  • May 05 07:38

    StanczakDominik on master

    `hypothesis` tests; numba-based… (compare)

  • May 04 19:27

    StanczakDominik on master

    Pickleable particles (#1122) (compare)

  • May 04 19:27
    StanczakDominik closed #1011
Nick Murphy
@namurphy:matrix.org
[m]
I've also been thinking now and then about a survey that focuses on what functionality the plasma community would find useful.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
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 :)
SolarDrew
@solardrew:openastronomy.org
[m]
how come?
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
jitsi had issues with Erik's screen share
and was just being all around unstable today :(
SolarDrew
@solardrew:openastronomy.org
[m]
aah ok, not permanently?
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
yeah, hopefully
SolarDrew
@solardrew:openastronomy.org
[m]
fair enough
Nick Murphy
@namurphy:matrix.org
[m]
Yeah, I'm not sure why screen sharing on Jitsi was grumpy today.
David Schaffner
@dschaffner:matrix.org
[m]
Frankly, I think this board is to negative about our corporate Zoom overlords
Nick Murphy
@namurphy:matrix.org
[m]
Alas, I must now get back to composing sea shanties that describe the differences between IDL .genx and IDL .geny files.
rebecca.ringuette
@rebecca.ringuette:matrix.org
[m]
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.
rebecca.ringuette
@rebecca.ringuette:matrix.org
[m]
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!
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Here's a friendly reminder that our weekly community meeting is happening in about an hour on jitsi, with the agenda for today here. We're trying to do PR triage today, but come hang out regardless 🙂
rocco8773
@rocco8773:matrix.org
[m]
So, I’m not going to be able to make the meeting today. The 2nd vaccine shot has wiped me out.
1 reply
Nick Murphy
@namurphy:matrix.org
[m]
No worries whatsoever. Please take the time you need to rest and recover. I hope you feel better soon!
rocco8773
@rocco8773:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Hope you get bettter soon!
You didn't miss much; we did make a bunch of progress on closing old PRs, though, so that was pretty productive.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Hey Nick Murphy, a question. Would you say that there are places where Particles should be mutable? What about CustomParticles? IonizationState objects?
Nick Murphy
@namurphy:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Well, you nailed the point of the question, there :)
Nick Murphy
@namurphy:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
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
Nick Murphy
@namurphy:matrix.org
[m]
Making CustomParticle immutable does sound reasonable to me. Right now it's mutable.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
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.
Nick Murphy
@namurphy:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Yeah, that sounds reasonable enough - unless you represented a series of time snapshots by a bunch of IonizationState objects.
Nick Murphy
@namurphy:matrix.org
[m]
Yeah, that would be another possibility. Hm...
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Well, it's not something I'm suggesting we change overnight :D
Nick Murphy
@namurphy:matrix.org
[m]
True!
Oh wait I mean True!
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
yes
Nick Murphy
@namurphy:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Makes sense!
Nick Murphy
@namurphy:matrix.org
[m]
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?
Dominik Stańczak
@StanczakDominik:matrix.org
[m]
Probably not ☹️
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
Nick Murphy
@namurphy:matrix.org
[m]
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.
Dominik Stańczak
@StanczakDominik:matrix.org
[m]

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.