astropy
Coordination Meeting 2024
Like https://github.com/astropy/astropy-project/issues/255 but for 2024 meeting, since I think collecting ideas on an issue had been pretty successful for the 2023 meeting.
Running notes from 2023 meeting
@WilliamJamieson and @nstarman might propose a topic related to array API, though this depends on how stable the array API is by the time this meeting happens. Also see:
- https://github.com/astropy/astropy/issues/13460
- https://github.com/astropy/astropy/issues/15071
- https://github.com/astropy/astropy/issues/15072
- https://github.com/astropy/astropy/issues/15073
- https://data-apis.org/array-api/latest/ (Scipy 2023 talk)
Suggestions of SOC meeting, 2023-11-28:
- Ask new roles (e.g. community manager) to introduce themselves and tell us they have been / will be doing.
- Reports from funded projects
Suggestion for topic, coming out of the dev-telecon: Discussion of Science platforms (e.g. SciServer, ...) Do we recommend any? Do we want to maintain our own at some point? Do we want to test any? Do we need to do anything to make it work better? Or make it work less (evil_grin)?
@hamogu can provide a debrief on how that contracting work initiative has worked out. By this meeting, both contracts with Clément and Mridul would have ended. Also see:
- https://github.com/astropy/astropy-project/blob/main/finance/proposal-calls/cycle3/user-dev-support-rse.md
(If this counts as "funded projects" in https://github.com/astropy/astropy-project/issues/349#issuecomment-1830033794 , then feel free to resolve this comment as duplicate. I was not sure. Thanks!)
Review and discuss @nstarman proposed APE 22 on Public API:
- https://github.com/astropy/astropy-APEs/pull/85
Exploratory implemetation of mypy in typing efforts (maybe it can drive some discussions on how to actually do this for real):
- https://github.com/astropy/astropy/pull/15794
- https://github.com/astropy/astropy/pull/15815
- https://github.com/astropy/astropy/pull/16312
Princess Bride screening for the benefit of @dhomeier , as requested by @eteq .
Maybe a demo at the meeting?
@nstarman on 2024-01-16
Hi! I've created and am continuing to refine a GPT for Astronomy in Python using the Astropy ecosystem. I've trained it on (in order of priority) Astropy, the coordinated packages, and all affiliate packages. Here's the link if you want to try it out https://chat.openai.com/g/g-oucCOdFuw-astronomy-python-copilot. Let me know if there are any improvements you'd like to see!
Disclaimer (as reported by laurent.michel on that Slack conversation): Testing this API requires to sign-in for ChatGPT+ (20$/month).
Quantity 2.0 (led by @nstarman):
- https://github.com/astropy/astropy-APEs/pull/91
PL edit: Maybe related?
- https://github.com/astropy/astropy/issues/13460
Astropy in the age of The Cloud (AWS):
- https://github.com/astropy/astropy/issues/16152
- https://github.com/astropy/astropy/pull/16159
If anyone wants to work on this and needs support for the ChatGPT+ subscription, please post in #finance-committee on Slack or send an email to [email protected].
If there is still no consensus on this APE 0 term limit proposal by the meeting, I say we just put it to a vote at the Coordination Meeting and be done with it. Though I think as per policy, all the 5 current CoCo members are not allowed to ~vote~ accept/reject this.
- https://github.com/astropy/astropy-APEs/pull/89
I don't understand why you think CoCo5 can't vote since they have the ultimate authority. Isn't it up to CoCo5 to decide the method used to decide?
APE 0 says that the CoCo doesn't have the authority to accept/reject APE 0 or modify the governance of the project - however it's not clear to me that they can't vote if they are voting members.
Session on what, if anything, should be changed/improved in the core astropy classes. For instance,
- Changes in implementations?
coordinates- currently, frames can be with and without data. Wouldn't it be cleaner if they never held data (i.e., the representation isSkyCoords worry)? (arose in discussion with @adrn)coordinates.representations- can we somehow make the linkage of derivatives with their representations less painful/circular? (vaguely recall this came up in talking to @nstarman, but not sure, may have been @adrn).time- the data is almost exclusively dealt with in theTimeclass, yet stored on the format. Should it be onTime? Alternatively, shouldTimeFormatbe a subclass ofShapedLikeNDArraysuch that it can deal with reshaping, etc.table- might it be time to mergeQTableandTable, allowing floatColumnwith units only if explicitly set?
- Improvements
More generally, are there any big missing pieces? E.g.,
- Error propagation?
coordinates.representations - can we somehow make the linkage of derivatives with their representations less painful/circular? (vaguely recall this came up in talking to @nstarman, but not sure, may have been @adrn).
I was advocating that we make a Space (e.g. phase-space) class that is a dictionary of Representation, Differential, etc objects + representation transformation machinery. This is basically moving the Representation.differentials out of Representation and into a composed class. Combined with a better separation of coordinate frames and data we get something like this:
>>> import astropy.coordinates as coord
# Representation objects
>>> q = coord.CartesianRepresentation(...)
>>> p = coord.CartesianDifferential(...)
# Collection thereof
>>> cart_space = coord.Space(length=q, speed=p) # parametrized by the physical type
>>> cart_space
Space({PhysicalType("length"): CartesianRepresentation(...), PhysicalType("speed"): CartesianDifferential(...)})
>>> sph_space = cart_space.represent_as(length=coord.SphericalRepresentation)
>>> sph_space
Space({PhysicalType("length"): SphericalRepresentation(...), PhysicalType("speed"): SphericalDifferential(...)})
>>> sph_space = cart_space.represent_as(length=coord.CylindricalRepresentation, speed=coord.SphericalDifferential)
>>> sph_space
Space({PhysicalType("length"): CylindricalRepresentation(...), PhysicalType("speed"): SphericalDifferential(...)})
# With frames
>>> frame = coord.ICRS()
>>> c = SkyCoord(sph_space, frame=frame)
# There are many ways to initialize
>>> c = SkyCoord(length=q, speed=p, frame=frame)
>>> isinstance(c.data, coord.Space)
True
# There are all the same ways to initialize
>>> c = SkyCoord(ra=..., dec=...)
>>> isinstance(c.data, coord.Space)
True
Thanks! Seems well worth discussing in more detail. The one piece that worries me is the example of cylindrical representation with spherical differential - interpreting the differentials requires one to know about the corresponding representation - but I can see the Space class in principle taking care of that. Adding accelerations would force us to think this through more clearly.
Discuss what we can do based on report from Astropy Community Survey.
- https://github.com/astropy/astropy.github.com/pull/581
Also related to ruff (https://github.com/astropy/astropy-project/issues/349#issuecomment-1944267950):
@astrofrog -- We should have policy to limit manually adding/enforcing new ruff rules to avoid open PR conflicts.
Celebrate the completion of the Moore grant!! 💸🎉
Also discuss lessons-learned thus far and big-picture plans for maintaining sustainable funding for Astropy.
I'm not necessarily advocating this, but it might be worth discussing dual anonymous proposal review. Maybe impractical for our small community, but we also cannot pretend that bias is non-existent. Interesting study from NASA's use of DAPR: https://science.nasa.gov/researchers/dual-anonymous-peer-review/
(Single) anonymous reviews is also something to discuss.
Re: Anonymous review -- Wasn't this what we just abandoned for Affiliated Package review in favor of all open review via pyOpenSci? Would it make sense to introduce anon review for one thing but abandon it for another? Also, not sure how feasible it is when we submit proposals etc all in the open.
On review: the up/down vote way to do funding seems a bit tricky. Nobody really wants to downvote (most ideas are OK!), so it gives just 2 options, no weights. It is also not clear it really helps for a ranking, which is what is really needed. I'd suggest doing something more along the lines of observing proposals, give a numerical grade. Or allow people some number of points to spread over the various proposals. Anyway, those are just suggestions; would be good to hear if there is actually a problem to solve, and, if so, what the solution might be.
I believe the dual anonymous reviews won't work for this because in practice we are typically not just funding ideas, but most proposals also identify a qualified hire (typically the person writing the proposal). We don't have anonymized hires either. While there are anonymized CVs in a multi-stage hiring processes in some institutions, at some point you have to select the person doing the work - that's different from observing proposals where a good idea is a good idea. Even if the proposer can't analyze the data, it will still be be in a public archive later. Here, if the money is spend, it's gone.
However, I'm very much interested in exploring how we can structure this to make it easier for people who are not on the core team. How do they get into the discussion with others what makes sense? Would it make sense to time proposals to be e.g. 8 weeks after a coordination meeting where hopefully a lot of new ideas will be generated?
I'll assume from the immediate interest and desire to discuss this here that this should be a topic for the coordination meeting, which was my purpose for making a comment. I'll stipulate now that DAPR might not make sense.