---
tags: poliastro
---

# poliastro community meetings

- **Time**: First Wednesday of every month from 16:00 to 17:00 CE(S)T
- 14:00 UTC during Europe DST, 15:00 UTC otherwise
- **Platform**: [Jitsi](https://meet.jit.si/poliastro)
- **Goals**: discuss design decisions, triage issues, plan roadmap, write code together it time permits
- **Process**: Write meeting notes here, inserting the most recent one on top. If you want to add specific topics to the agenda, do so before the meeting starts. No need to commit the notes to a wiki or repository for now.
- **Next meeting**: 2022-09-07

## Notes from 2022-09-07

......

## Notes from 2022-08-10

- @dhruvj and @juanlu met about https://github.com/poliastro/poliastro/issues/1558
- There are elements for the planets https://ssd.jpl.nasa.gov/planets/approx_pos.html :heavy_check_mark:
- There are elements for the satellites as well https://ssd.jpl.nasa.gov/sats/elem/sep.html but :warning: we don't know what the "local Laplace plane" is, looks like it's not properly defined
- However, all the uses cases only require the semimajor axis, even looking at https://github.com/poliastro/poliastro/issues/1558#issuecomment-1199312335
- Let's create `poliastro.constants.mean_elements` and add the mean semimajor axis of all the major bodies and some satellites
- Then @juanlu will take care of replacing `get_mean_elements` by this
- Eventually we will be able to validate our results using https://ssd.jpl.nasa.gov/tools/periodic_orbits.html#/intro

## Notes from 2022-08-03

(@jorge and @s-m-e met, no notes)

## Notes from 2022-07-20

- Debriefing from SciPy
- Sam Frieman has an idea for high fidelity propagation
- Most likely using https://github.com/SHTOOLS/SHTOOLS/
- (see also https://twitter.com/poliastro_py/status/1283052225921679361 for a comparison with fatiando/boule)
- Reference: https://help.agi.com/stk/index.htm#hpop/hpopForceMods.htm
- Make calls monthly and accomodate time for US residents
- ...
- Resuming `OrbitArray` work :warning:
- We already discussed https://github.com/poliastro/poliastro/pull/1445 which is only the API and not the implementation, let's rehash that
- Target dates:
- Remainder of July: @juanlu rethinks everything
- August (excluding first week): work happens
- First week of September: wrap up

## Notes from 2022-06-29

- @helge Discuss integration of [OpenAstrodynamics Planetarium](https://github.com/OpenAstrodynamics/planetarium) for orbit visualisation
- Runs in the browser!
- Based on Three.js + declarative React components
- Naïve code runs at 60 frames per second
- Input is JSON
- Planetary trajectories requires some low-precision, offline ephemerides to avoid CORS issues or the need of a backend/proxy
- Alternatives mentioned
- https://godotengine.org/ doing advanced stuff requires writing C++ and recompiling the engine
- OpenGL: too low level
- https://universesandbox.com/ not open-source but looks cool
- https://makie.juliaplots.org/stable/ but still difficult to package Julia code
- Other formats
- CZML (from Cesium), also based on JSON
- SPICE kernels
- Lots of code churn is coming: https://github.com/poliastro/poliastro/pull/1521

## Notes from 2022-06-22

Skipped, too much work!

- poliastro paper for SciPy
- preparation of release 0.17
- fastunits poster URL

## Notes from 2022-06-08

- Draft paper submitted to SciPy 2022 proceedings https://github.com/scipy-conference/scipy_proceedings/pull/724 undergoing review
- Some annoying test failures (Hypothesis is getting smarter!), opened https://github.com/poliastro/poliastro/issues/1517 to track them
- Debugged in https://github.com/poliastro/poliastro/issues/1517, some issues were actually addressed
- Will send monthly updates to NumFOCUS
- Let's try to get https://github.com/poliastro/poliastro/pull/1486 merged

## Notes from 2022-05-18

To discuss:

- :warning: Deadline of paper approaching

## Notes from 2022-05-11

To discuss:

- poliastro 0.16.3 is available, import and dependency problems seem to be fixed
- Monthly news for NumFOCUS
- release
- talk & paper
- Established contact with [mubody](https://gitlab.com/mubody/mubody) creator, will meet in person soon
- Status of `OrbitArray` work
- To be featured in 0.17.0 "SciPy Edition", deadline is 1st July

## Notes from 2022-05-06

- Coming back from inactivity!
- Current status of the project
- It's broken! https://github.com/poliastro/poliastro/issues/1496, https://github.com/poliastro/poliastro/issues/1493
- Doing a poliastro 0.16.3 release with latest Astropy compatibility
- @juanlu will take care of it ASAP
- Upcoming SciPy US 2022 talk (and paper?)
- We will try to write a paper on time, here are the instructions https://github.com/scipy-conference/scipy_proceedings#instructions-for-authors
- ~~Status of `OrbitArray` work~~
- Will revisit with @s-m-e
- Relationship with mubody https://gitlab.com/mubody/mubody
- @juanlu will open an issue and drop them an email
- Possible collaboration with sbpy https://github.com/NASA-Planetary-Science/sbpy/issues/26#issuecomment-1111263363
- Deciding time of community meetings
- @juanlu will send a survey/Doodle/similar to find a better date
- @jorge will work on automating the releases https://github.com/poliastro/poliastro/issues/1416

## Notes from 2022-03-18

- Answer https://github.com/poliastro/poliastro/pull/1490 ASAP, even with a shallow review
- Decide about https://github.com/poliastro/poliastro/pull/1486, small but needs review

## Notes from 2022-03-11

- No GSOC :(
- [name=Juanlu] will send the updates to NumFOCUS soon

## Notes from 2022-03-04

**Attendees**: Sebastian, Luis

- Brief talk about:
- Issue [#858](https://github.com/poliastro/poliastro/issues/858) and Vallado's MATLAB [implementation](https://celestrak.com/software/vallado-sw.php)
- [Octave](https://www.gnu.org/software/octave/index) and [oct2py](https://pypi.org/project/oct2py/)

## Notes from 2022-02-25

- @jorge Mentions that there's a duplication of dev dependencies
- We could remove style dependencies from `pyproject.toml` :heavy_check_mark:
- And we could [run `pre-commit` from `tox`](https://stackoverflow.com/a/71023703/554319)!
- @jorge proposes a PyVista backend for visualization
- It's super easy to draw the planets! https://github.com/pyvista/pyvista-support/issues/257#issuecomment-1050667129
- Looks like `pip install pyvista` did not immediately work?
- @s-m-e proposes adding `pytest-xdist` to run tests in parallel
- We should disable it in CI
- @yash added two functions: elevation and sidereal time https://github.com/poliastro/poliastro/pull/1486
- He keeps getting this error https://github.com/poliastro/poliastro/issues/1303 :sob:
- @Dhruv made progress with the CR3BP functions https://github.com/poliastro/poliastro/pull/1475 review needed

## Notes from 2022-02-18

**Attendees**: Jorge, Juan Luis, Luis, Yash

- Validation of visibility got stuck, poliastro and Orekit differ
- @yash will add just an elevation function
- @jorge will at some point validate it against GMAT and/or Orekit
- Documentation is failing, and it looks like an internal Astropy problem? https://github.com/poliastro/poliastro/issues/1484
- Discussing some details about satellite collision, seems like we have a plan https://github.com/poliastro/poliastro/issues/1350#issuecomment-1044302995

## Notes from 2022-02-11

**Attendees**: Jorge, Juan Luis, Luis, Sebastian, Yash

- Rework API docs https://github.com/poliastro/poliastro/pull/1476
- Rendered version at https://docs.poliastro.space/en/stable/api.html
- @juanlu intends to backport that to release ~~0.16.1~~ 0.16.2
- poliastro 0.16.2 is available :tada: now users searching for "TLE" will actually find something (finally!)
- What to do with the competing CR3BP implementations? https://github.com/poliastro/poliastro/pull/1475
- Seems like Kevin is OK with favoring Dhruv work! We will do more in-depth reviews soon
- SciPy 2022 deadline is today! @juanlu plans to submit a talk proposal
- @s-m-e writing tests and benchmarks for `OrbitArray`
- @luisgmm is getting familiar with the library and will take care of replacing the plot in the README by its Plotly equivalent https://github.com/poliastro/poliastro/issues/610
- @jorge is available for review but will be busy with the onboarding of his new job
- @yash is still working on the satellite collisions

## Notes from 2022-02-04

**Attendees**: Jorge, Juan Luis, Kevin, Luis, Sebastian, Varenyam, Yash

- Project updates from @juanlu
- NumFOCUS updates submitted and available on the blog https://www.poliastro.space/blog/2022/02/01/january-updates/
- After an annoying week we ditched Azure Pipelines for CircleCI, now everything is working smoothly
- SciPy community calls started, hoping to put resources into `scipy.integrate` so it can benefit poliastro
- GSOC is approaching, we intend to participate through Libre Space Foundation
- Anish contributed Gabbard plots! https://github.com/poliastro/poliastro/pull/1464 Will do a thorough review after the meeting
- @jorge had a few comments about the class structure
- Also, there are no tests and it would be cool to have at least image tests
- We approved @s-m-e proposal to move the `Orbit` classmethods to a mixin https://github.com/poliastro/poliastro/pull/1446
- This however highlighted the need to improve the API documentation https://github.com/poliastro/poliastro/issues/1183
- We investigated a bit why the `Body` plotting is broken https://github.com/poliastro/poliastro/issues/1448
- Most likely it broke after https://github.com/poliastro/poliastro/pull/1434, @varenyam is looking into it
- Unclear why the interpolation complains that the time is out of range, more investigation is needed
- @yash highlighted a possible issue with extrapolating the data, since the `z` values are supposed to be zero (?)
- @jorge proposed to design new maneuver APIs as discussed in https://github.com/poliastro/poliastro/issues/1396
- Possible inspiration: DiPrinzio "Methods of Orbital Maneuvering" https://arc.aiaa.org/doi/book/10.2514/4.105838
- @luis found a workaround for Binder builds https://github.com/poliastro/poliastro/issues/1460 and will send a pull request soon
- @yash will keep working on satellite collision and line of sight events
- @kevin will continue working on the Circular Restricted Three Body Problem

## Notes from 2022-01-28

- We did a joint review of @s-m-e `OrbitArray` proposal https://github.com/poliastro/poliastro/pull/1445/, looking great!

## Notes from 2022-01-14

- Orbit array proposal https://github.com/poliastro/documents/blob/master/numfocus-sdg-2021-r3.md
- Two import PRs:
- https://github.com/poliastro/poliastro/pull/1430
- https://github.com/poliastro/poliastro/pull/1434
- We discussed some possible implementations https://github.com/poliastro/poliastro/wiki/Ideas-on-%60OrbitArray%60
- @s-m-e agreed to paste a use case demo of how would this look like in user code

## Notes from 2022-01-07

- @jorge already reviewed the cleanup of `poliastro.twobody.orbit`
- @juanlu opened a cleanup of `poliastro.ephem` https://github.com/poliastro/poliastro/pull/1434
- @jorge is preparing finals, will review these ones in a couple of weeks
- @juanlu needs to rewrite the OMM & TLE notebook because the debris fragments are reentering
- @juanlu will write a quick summary of December updates for NumFOCUS
- @dhruvj offered contributing material on Halo orbits and related stuff, starting with the equations of motion

## Notes from 2021-12-17

- Last call of the year!
- @juanlu will add a tutorial to load GP data (TLE and OMM)
- @jorge will revamp the Lambert API https://github.com/poliastro/poliastro/issues/1054
- @s-m-e will start in January
- The dev team goes on vacation :christmas_tree:

## Notes from 2021-12-10

- poliastro 0.16.0 released!
- @yash talk at #oscw21 was very successful
- @juanlu tutorial will follow shortly
- @s-m-e project possibly starting in January
- Not much work expected during the winter holidays

## Notes from 2021-12-03

(No meeting)

## Notes from 2021-11-26

(No meeting)

## Notes from 2021-11-19

- NumFOCUS has requested the December updates
- @juanlu will send it ASAP
- Priority: branching 0.16
- We merged https://github.com/poliastro/poliastro/pull/1378
- But @jorge noticed that the crosses :x: for the impulses are not there anymore, we'll look into it
- We had a meeting with UMA about possible collaboration, we agreed to
- Have another edition of our GSOC talk
- And _maybe_ apply for a NF SDG in the future (mid-2022 or later)
- Let's hold https://github.com/poliastro/poliastro/pull/1398 off until `0.16.x` is branched
- Would be cool to document how to manage TLEs https://github.com/poliastro/poliastro/issues/1215
- Why this is tricky: https://github.com/poliastro/poliastro/issues/1185
- `Orbit.from_tle`? We could raise an error, unless `Orbit.from_tle(tle, i_know_what_im_doing=True)` :smiley:
- `Ephem.from_tle` would be much more appropriate
- More thoughts about TLE APIs: https://github.com/poliastro/poliastro/wiki/Notes-about-TLEs

## Notes from 2021-11-05

(No meeting)

## Notes from 2021-10-29

- Send October/November updates
- @juanlu will get it done today
- The UMA team using poliastro for GTOC found several bugs
- https://github.com/poliastro/poliastro/issues/1363 identified as bug, fix is simple
- https://github.com/poliastro/poliastro/issues/1362 @juanlu debugging it
- https://github.com/poliastro/poliastro/issues/1360 still didn't start looking at it
- Not much activity during Hacktoberfest
- Conferences
- OSCW CFP until November 12 https://events.libre.space/event/5/abstracts/#submit-abstract
- @yash will prepare a 12 minute talk about his GSOC work
- @jorge will present a 12 minute talk proposal about lamberthub even though it might be out of scope, but let the programme commmitee decide
- @juanlu will present a 45-minutes long tutorial focusing on poliastro but also czml, orbit-predictor, GP data
- SciPy Latin America CFP until ??? http://dev.scipy.lat/
- @juanlu already sent a proposal about documentation
- Release 0.16 is getting closer
- @juanlu intends to finish the release notes on Sunday or Monday
- @yash added some messages to assertions, but they unfortunately don't help users https://github.com/poliastro/poliastro/pull/1367
- @yash is discussing with Egemen about the visibility [TBC]
- @yash proposes trying out different solvers to have better step control
- @jorge tried to implement Verner78 https://github.com/scipy/scipy/issues/9698 but we didn't get any help from SciPy devs
- @juanlu will reach out to the mailing list
- Struggles with funding
- Best transfer method from NumFOCUS to Europe? Still waiting
- OpenAstronomy money, still waiting https://community.openastronomy.org/t/how-can-member-projects-use-funds/119?u=astrojuanlu

## Notes from 2021-10-22

- NumFOCUS Small Development Grant
- Not to worry about single-orbit, single-propagation performance
- Aim for **maintainability**
- The GPU-based interfaces should be opt-in, therefore for non-GPU workloads everything should work mostly the same
- @s-m-e will study the library over the coming days and come up with a plan to be discussed in the next meeting
- Establish a performance baseline for the current code
- Possibly add benchmarks to https://benchmarks.poliastro.space/ (https://github.com/poliastro/benchmarks)?
- Alternatively, pytest-benchmark as used in https://github.com/astrojuanlu/sgp4-benchmarks/
- Similar workflow as validation triggers https://github.com/poliastro/validation/
- Investigate GPU support for "advanced" features
- Computation should be double precision
- We can focus on the new Python array API standard https://data-apis.org/array-api/latest/purpose_and_scope.html
- More info https://labs.quansight.org/blog/2021/10/hypothesis-array-api/
- Type annotations: only _very_ lightly
- Will this live on the `main` branch or not? Still to be decided
- @s-m-e fork: https://github.com/s-m-e/poliastro
- Notes about the `sample` method
- Current sampling strategy is perfect for static plots
- But animations need time-based sampling!
- Also, people often want to sample a trajectory, and discovering the `propagate` function is not easy
- Cool post about orbit tesellation! https://www.kerbalspaceprogram.com/dev-diaries/6509/
- New `plot_maneuver` method https://github.com/poliastro/poliastro/issues/1349
- We could use the `propagate` function ourselves because we know the start and end times of the maneuver
- @jorge will try to quickly implement it
- Weird units in universal gas constant https://github.com/poliastro/poliastro/pull/1351
- There seems to be some inconsistency, we will need to investigate more
- It's present in Astropy already https://docs.astropy.org/en/stable/constants/index.html
- Missing gaps in the ecosystem
- Permissive-licensed continuous thrust orbit trajectory optimization (alternative to MOLTO and others) (what are European companies using?)
- Calculus of Variations

## Notes from 2021-09-24

- Reformat `atmospheric_drag_model` function to `atmospheric_drag`. See https://github.com/poliastro/poliastro/issues/1302
- Agreed to follow this approach
- Use functions instead of classes for atmospheric models. @juanlu already pointed out this a long time ago.
- No examples of `earth.atmosphere`! We should have them
- This task is related to the refactoring of the `atmospheric_drag` function
- If that function receives the density as a scalar, we don't need classes anymore
- We can keep the classes and move the logic to functions
- If we move the functions to `poliastro.core`, we have to document the implicit units (as with every other function there)

## Notes from 2021-09-17

- The meeting did not take place.

## Notes from 2021-09-10

- @juanlu has been mentoring Johana to try to get the units of the plots, see https://github.com/poliastro/poliastro/pull/1318
- Should we have a bot action to reformat the code to make life easier for beginners? (Good Hacktoberfest project)
- Discussions about the tricky parts of https://github.com/poliastro/poliastro/pull/1299 and https://github.com/poliastro/poliastro/pull/1298

## Notes from 2021-09-03

- @juanlu submitted https://github.com/poliastro/documents/blob/master/numfocus-sdg-2021-r3.md for the NumFOCUS Small Development Grants current cycle (fingers crossed!)
- Projects will be Notified: October 15, 2021
- August updates published in https://numfocus.salsalabs.org/numfocusnewsletter_august2021
- @yash is validating a weird visibility case https://github.com/poliastro/validation/pull/35

## Notes from 2021-08-27

TBC: Was there meeting or not?

## Notes from 2021-08-20

- If the satellite position norm is lower than the attractor's one, the arugment of a cosine function used during the computation of the event becomes larger than one and `nan` values are returned. See LOSEvent PR for more information: https://github.com/poliastro/poliastro/pull/1258/files.
- A new notebook on events usage was added by @Yash in https://github.com/poliastro/poliastro/pull/1304.
- @juanlu fixed temporaly the widgets docs, see https://github.com/poliastro/poliastro/pull/1310.
- Hacktoberfest is coming!
- GSoC talk (@jorge and @juanlu)
- August updates for NumFOCUS sent :heavy_check_mark:
- Should we detect dead code? https://pypi.org/project/vulture/
- Some dead code was found within the codebase, see https://github.com/poliastro/poliastro/issues/1311
- @yash suggested https://github.com/astropy/astroplan for satellite visibility

## Notes from 2021-08-13

- Most of the time of the meeting was devoted to a deep analysis of https://github.com/poliastro/poliastro/issues/1303, which turned out to be an Astroquery issue.

## Notes from 2021-08-06

- Pull request about terminal events, https://github.com/poliastro/poliastro/pull/1288, requires Juanlu's approval to be merged.
- The `SatelliteViewEvent` implemented by Yash in https://github.com/poliastro/poliastro/pull/1298 can be understood to be the oposite to the `EclipseEvent`. However, no similar event detector is seen in Orekit API. Therefore, he agreed to check this against the `EclipseEvent` itself, meaning that the `SatelliteViewEvent`should be triggered when the `EclipseEvent` does not.
- Finally, regarding the `SatelliteVisivilityEvent` (see https://github.com/poliastro/poliastro/pull/1299), two analysis were provided in Escobal1965. The first considers a planar terrain, so the satellite is visible as soon as it rises over the horizon. The second one imposes a mininum elevation angle for modelling obstacles which block the line of sight with the satellite. Yash will try to combine both. If not possible, the agreed to use the first approach. Validation can be performed against Orekit for this case.

## Notes from 2021-07-30

- For issue https://github.com/poliastro/poliastro/pull/1258/files, the length of the coordinates to be checked must match the one from the array of time of flights. Also, should we pass an `Ephem` coordinates or just an `Orbit` sampled ones.

## Notes from 2021-07-23

- Issue https://github.com/poliastro/poliastro/issues/1270 looks like is already solve. Should we close it?
- Discuss `cowell` output for events information. Should we better return the `results` object if at least one terminal event is passed? This would not break current `cowell's` implementation.
- Discussion about terminal events:
- We should crop the result vectors if the propagation is interrupted
- We will stop the propagation as soon as 1 terminal event triggers
- We decided to use the `last_t` property of the event to check which one was triggered
- Satellite collisions https://github.com/poliastro/poliastro/issues/1289
- Rather than propagating two objects, we should receive a trajectory of the secondary object
- Then we can compute the miss distance
- @yash proposed a new event detector for node crossings
- @juanlu will open an issue about changing the units of the plots

## Notes from 2021-07-16

- We developed a general script in the validation repository for checking poliastro events againts Orekit ones. The LatCrossingEvent seems to be succesfully implemented though still pending to be merged: https://github.com/poliastro/validation/pull/29
- The `shadow_function` assumes that both the sun and the satellite are points. Therefore, this cannot be used for the eclipse analysis geometry.
- Checking against Vallado Matlab for RV2COE against the current implementation might rise some results about the bug found in https://github.com/poliastro/poliastro/issues/1276.
- @Yash will send a blog post summarizing the work done in the first period

## Notes from 2021-07-09

- Regarding issue #1273 opened by @yash (see https://github.com/poliastro/poliastro/issues), the issue could not be reproduced in other machines. Further investigation is required on this, see the issue comments section.
- Issue https://github.com/poliastro/poliastro/issues/1274 was closed in favour of https://github.com/poliastro/poliastro/issues/282. Because GMAT seems to include the MEE set, a validation case will be developed.
- Eclipse detector will make use of the `shadow_function` and a boolean parameter for triggering the `penumbra` option will be available to user.
- The Latitude and Longitude event detectors will be implemented separately. Validation cases will be developed based on Orekit. Main efforts will be directed towards the latitude detector for the moment, as longitude one is a bit more complicated.

## Notes from 2021-07-02

- The Lat/LonCrossEvent is only defined orbits around the Earth body at this moment, see https://github.com/poliastro/poliastro/pull/1268/files. A discussion was opened in https://github.com/poliastro/poliastro/issues/1269 for addresing this, as the topic turn out to be a little bit more comlex for other bodies. Possible temporal solution: raise a NotImplementedError os we can merge the PR till we investigate previous issue.
- @juanlu made some code reviews on @yash work about docstring changes and Maneuver constructor: https://github.com/poliastro/poliastro/pull/1271 and https://github.com/poliastro/poliastro/pull/1264.
- @jorge Will study the Eclipse problem, the mathematics behind the problem and review the linked PR in https://github.com/poliastro/poliastro/pull/1246 and https://github.com/poliastro/poliastro/pull/1258.
- The line of sight (LOS) from Vallado considers an ellipsoid body but the eclipse routine assumes an spherical one. @yash claims that a simple modification can make the LOS program to work with spherical bodies also.

## Notes from 2021-06-25

- Discuss about refactoring atmosphere. Astropy units went accidentally inside core module! Use grep -r "units" src/poliastro/core.
- @yash opened a new issue about relative VS absolute import. See: https://github.com/poliastro/poliastro/issues/1259
- Both @yash and @jorge agree to use absolute imports. However, not sure if there is any advantage when using relative ones. Better discuss with @juanlu in associated issue.
- @jorge will review all associated `EclipseEvent` pulls, so this is hopefully implemented by the end of this weekend.
- @yash proposed some new `Orbit` attributes, `Orbit.lat` and `Orbit.lon` which could be useful for recycling code in `groundtrack.py` and the future `LatLonCrossingEvent` function.

## Notes from 2021-06-18

- Dicuss building a mother class named "Event" from which available event detectors inherit. See "AltitudeCrossing" and "LithobrakeEvent" similar structure for justification on this.
- We agreed to build a class named `Event` who's attributes are `last_t`, `terminal` and `direction`. The only method should be the `__call__` one, which raises a `NotImplemented` error.
- @jorge will look for validation cases, although simple ones can be derived from non perturbed orbit (i.e: altitude crossing perigee/apogee).

- Eclipse detection discussion, see https://github.com/poliastro/poliastro/pull/1246.
- Check the [shadow function](https://github.com/poliastro/poliastro/blob/3acb5c8b843786fa874f0ea5b620382cd26ac77f/src/poliastro/core/perturbations.py#L180). Some logic might be already implemented.
- Validation cases related with this. GMAT includes the `Ex_2015_EclipseLocation.script` but it crashes in @jorge's local machine. Orekit ships with an `EclipseDetector`, useful for testing.
- @yash will finish by the end of this week the `AltitudeCrossing` event and reformat the `LitobrakeEvent` one.

## Notes from 2021-06-11

- NumFOCUS acknowledged the reception of our validation report :tada:
- @yash blog post published https://www.poliastro.space/blog/2021/06/06/poliastro-gsoc-yash/
- @juanlu just sent the project updates to NumFOCUS
- @yash has been playing with better initial guesses for the analytical propagation https://github.com/poliastro/poliastro/issues/1240
- @yash also discovered a small bug with the `flit install --symlink` https://github.com/poliastro/poliastro/issues/1245 it's an easy one to fix

## Notes from 2021-06-04

- Discuss coverage, related to issue https://github.com/poliastro/poliastro/issues/1236
- According to https://codecov.io/gh/poliastro/poliastro/ many modules have very low coverage, we should increase it
- And in particular, `farnocchia.py`
- Discuss shipping some validation tests to poliastro (related to previous week debate about @slow marked tests)
- We discovered a silly bug, only caught by the validation tests, fixed by https://github.com/poliastro/poliastro/pull/1239
- Related to #1236, we should have more and better unit tests
- One option is to use mocking, see https://www.toptal.com/python/an-introduction-to-mocking-in-python and a couple of examples in poliastro already
- Should we _not_ run the `slow` tests for coverage, and replace them by unit tests instead?
- Many of the perturbation tests are parametrized, what about keeping 1 case for unit tests, and moving the rest to `validation`
- Besides, we should thoroughly analyze why our propagation is slow
- It turns out that `thrust` accelerations are not jitted!
- For external coordinates (third body, solar radiation pressure) we could change the API to receive a table of coordinates instead
- What about some blog posts by @yash during GSoC?
- Absolutely! @yash will write one in the coming days to introduce himself
- @sebastian discusses about CUDA-enabled poliastro, his fork https://github.com/pleiszenburg/bulk_lambert contains some experiments
- We should have a roadmap for integrating this, creating layers of APIs that can be reused without copy-pasting the code

## Notes from 2021-05-21

- Yash accepted on GSOC! :tada:
- Pending 0.15.0 announcements on python-announce and poliastro-dev https://github.com/poliastro/poliastro/issues/1104 @juanlu will do
- Pending sending the Validation report to NumFOCUS https://github.com/poliastro/numfocus_proposal/blob/master/report.md @juanlu will send PDF (`pandoc` instructions in Markdown file)
- Lambert API solved @jorge, added comment about it in https://github.com/poliastro/poliastro/issues/1054#issuecomment-845808779
- Discuss on author names in poliastro's BibTeX citation. Some of those appear with GitHub's nicknames
- The automatic export is kind of broken https://github.com/poliastro/poliastro/issues/956, @juanlu will fix it manually and let's see if we can do something about it
- Should we use non-ASCII names? https://github.com/poliastro/poliastro/issues/1199
- We could add aliases to `Orbit` (`.e`, `.ecc`, `.eccentricity)
- Magic makes code unmaintainable (`*args, **kwargs`), we prefer not to do it
- Let's keep public API unchanged
- But we are open to using mathematical symbols
- However, it would be nice do document how
- `odeint` as alternative to Cowell propagation https://github.com/poliastro/poliastro/pull/1227
- We should look into `numbakit-ode` instead https://github.com/poliastro/poliastro/issues/1042
- @jorge points out that the slow tests are good for coverage anyway, if we remove or move them we should have an alternative
- @juanlu will update #1042 with some ways forward
- @yash will work on the items outlined in the original proposal during the Community Bonding period
- In particular, finishing open pull requests, reduce warnings, and include numbakit-ode

## Notes from 2021-05-14

- Final 0.15.0 is ready, we need to do some backports https://github.com/poliastro/poliastro/issues/1104#issuecomment-840106985 @juanlu will take care of it today
- Validation report underway, @jorge is on it
- There's a maximum of 2 out of 3 rounds of NumFOCUS Small Development Grants we can apply each year
- We will pass on the second round, and apply for the third round to avoid overlap with GSOC

## Notes from 2021-05-07

- Review Sam PR! https://github.com/poliastro/poliastro/pull/1204
- Validation PR on review, @jorge will address the last style comments
- Release notes underway
- Beta release was postponed due to unexpected issues with the contributor list and MyST syntax
- @juanlu will branch `0.15.x` before completing the release notes to avoid blocking it any longer
- We need to send the project updates - @juanlu will make the first PR to the blog, @jorge will review, and we will send the result to NumFOCUS
- Ideas about the future of the project:
- @juanlu will explicitly focus more on project management (do outreach, look for external funding, onboard new contributors, improve docs)
- We need a larger number of people to take decisions about the API and the vision
- We should consider separating `poliastro.core` https://github.com/poliastro/poliastro/issues/1207
- It's very important to onboard new, long-term contributors with domain specific knowledge
- For example, by doing wider promotion for Physics, Mathematics, Astronomy, and Aerospace Engineering students before December

## Notes from 2021-04-30

- We should separate the Earth cases because ITRS has more precision
- The {1, 0, 0} unit vectors for the validation are giving some convergence issues, so we should use the radiuses of the planets instead
- No updates on NF OC
- Sphinx 4
- We need to answer issue on SGP4 differences
- Documentation has been reordered, we need redirects

## Notes from 2021-04-23

- NumFOCUS is working to be a Fiscal Host on Open Collective, this might benefit us
- And perhaps make the transfer of the GSOC money that OpenAstronomy has for us easier?
- @juanlu is working at the moment on the documentation reorganziation, will push soon
- @jorge has almost finished the validation work, we agreed to improve the parametrization of the tests and use Jinja2 to generate the GMAT scripts
- Turns out we almost completed [what we initially proposed](https://github.com/poliastro/numfocus_proposal/)!
- We should open issues on poliastro for the problems we identified (lack of intermediate planetary reference frames)
- Also, we will write a public report and a blog post
- We should review the [long standing animations PR](https://github.com/poliastro/poliastro/pull/1131)
- We need to find a way to simplify the "first contribution", let's speed up the creation of `contrib/`
- @juanlu plans to have everything ready for the beta release by next meeting

## Notes from 2021-04-17

- We had to postpone the meeting one day because of @juanlu schedule
- All GSOC drafts have been reviewed
- We agreed on adding a `contrib/` directory to make contributing rough scripts easier
- [Version 0.15](https://github.com/poliastro/poliastro/issues/1104)
- Ideas for Open Collective:
- Visible name in main documentation page
- Mention in release notes
- "Thank you!" email
- Fast-track support chat
- poliastro stickers with a physical "Thank you!" note
- For the frame validation, Orekit uses an older version of the constants, so some tests will be marked as `xfail`
- We will add the GMAT scripts as well as their output, to avoid having to run GMAT in CI
- Validation trigger still not working properly, @jorge will start from scratch

## Notes from 2021-04-09

- Validation repository not being triggered, check token
- @juanlu will catch up with PR reviews and draft reviews
- [Version 0.15](https://github.com/poliastro/poliastro/issues/1104)
- @jorge found new classes in Orekit that might be applicable, will finish validating the frames
- After the GSOC period ends, @juanlu will give a final pass on the [0.15 milestone](https://github.com/poliastro/poliastro/milestone/16), especially on the two coding issues

## Notes from 2021-04-02

- [Rotating frames validation](https://github.com/poliastro/validation/pull/24) (@jorge)
- We were using the wrong definition of MarsICRS in GMAT (we noticed because the results of MarsFixed were in the same plane, which doesn't make sense) and possibly in Orekit. @jorge will look at it.
- [Libre Space Foundation adherence](https://github.com/poliastro/poliastro/issues/1063) (@juanlu)
- Not discussed
- [Version 0.15](https://github.com/poliastro/poliastro/issues/1104)
- Not discussed
- All our meeting was consumed debugging the frames mismatch - for debugging, we should have a separate meeting (that doesn't need to be recurring)
- For next week, @juanlu will review all the pending drafts and catch up with notifications
- @jorge will ask in the Orekit forum about MarsICRS and finish the validation PR