Articles by Jorge Martínez Garrido

As part of the NumFOCUS small development grants, the poliastro/validation repository has increased its activity in order to reach its main goal: validate poliastro's most complex features against similar software.

One of those features are impulsive maneuvers (Hohmann and Bi-elliptic) when applied to non-equatorial orbits. The absence of numerical results in literature and similar sources, made impossible to test associated pieces of code to impulsive maneuvers for orbits with inclination and spacecraft not placed in periapsis. However, this situation has changed, as they are now validated against Orekit and GMAT.

You can see corresponding pull-request for Hohmann validation and Bi-elliptic validation. Not only that, a continuous integration tool has been setup. This ensures that if any bug is introduced within main poliastro source code, we can detect it and fix it without any problem.

One interesting thing is that …

GSOC 2019 Edition has almost finished. All along this last three months lots of issues where solved, poliastro 0.13 was raised, new features were applied and of course, new issues and bugs appeared.

The objective of this post is just to collect all the implementations that have been merged during this GSOC and also those that are still required to be done.

ALREADY IMPLEMENTED

• [x] Lambert minor issues were fixed.
• [x] Lambert as Maneuver instances.
• [x] Docs and notebook on previous implementations.
• [x] Trail plotting option.
• [x] Fix minor issues on CI and tests.
• [x] New twobody propagators.
• [x] Maneuver fixes: Hohmann time to pericenter and units bug.
• [x] Atmospheric models: COESA62 and COESA76.

A detailed description and link to the code can be found in the following lines.

Izzo Algorithm minor errors

Some errors appeared in the minimum …

Reformat on poliastro.atmosphere

After implementing the COESA62 and COESA76 models in #738 I was not completly happy because of lots of data and coefficients at the beginning of each script. Therefore and after asking Juanlu, it was finally decided to move all those numbers to text files under the *.dat extension.

Furthermore, I decided not only to do that but also to completely reformat the poliastro.atmosphere module:

• base.py: holds different mother classes for atmospheric models.
• coesa62.py: U.S Standard Atmosphere 1962 model.
• coesa76.py: U.S Standard Atmosphere 1976 model.
• util.py: contains atmospheric utilities.

Documentation was also added together with a notebook to better see not only how these objects work but their differences in output results. In the following image properties for COESA76 against geometrical altitude are plotted:

Reformat on poliastro.bodies

While working …

Tasks for this last period...

While checking the stability of the 0.13, GSOC continues and new bugs, implementations, and others need to be solved for the 0.14. Most of them are related to:

• New frame modeling, implementation, and testing.
• New plotting capabilities, such us two attractors in the same plot.
• New orbit creation methods.
• Start using non-dimensional units.
• Different bug solving.

Issues related to frames are the most tricky ones since working with them is not so intuitive. Plotting capabilities are directly related to frames and therefore no major improvements are done in this field without solving something in the previous one.

New atmospheric models

I have been trying to model and implement some famous atmospheric models for poliastro. Drag is one of the main perturbations for LEO orbits. By making use of Cowell's formulation we can integrate …

What are propagators and why do we care about them?

One of the most common problems in astrodynamics and orbital mechanics is that we want to know where a body will be at a given position along its orbit for a given time. It is possible to integrate by hard the two-body equation and then apply some boundary conditions. However, this last option is just insane and would take several hours or days to be done by a human.

There is a better way to get the position as a function of time or propagate an orbit. Johannes Kepler's contributions to the astrodynamics and orbital mechanics field were really important and can be summarized here, in the so-called Kepler's Laws:

• Planets' orbits follow an elliptical path around the Sun, which is located in one of the focus.
• Planets cover equal …

Version 0.13 is getting closer

Version 0.13 is expected to be tagged in about a month. As any other release, it includes new features such as a new method in the Orbit class called change_attractor or the trail parameter in StaticOrbitPlotter. However, this release will also include really important bug fixes such as:

• Minor issues related to Lambert's problem.
• Propagator's are supposed not to hang out anymore due to robust solutions and propagation methods.

Now that my final exams ended I am completely free to work in poliastro and direct all my efforts to the software. I want to close issues #495 and #475 in the next days since they are previously commented bugs.

Propagator methods in the twobody problem

Kepler's equation (KE) allows us to solve either for the time at a given position or the position …

What's new?

Three weeks have passed since the coding phase began and new features have been added to the software:

• Lambert is now a Maneuver instance.
• A trail keyword in StaticOrbitPlotter for showing orbits' trails.

Lambert just needs now two orbits!

Although the raw algorithms are kept under the module poliastro.iod, it is possible now to simplify the process of solving this famous astrodynamics problem by making use of the poliastro.maneuver module.

Imagine that we want to solve the classical problem ongoing from Earth to Mars for a trip of 600 days duration. Let us compare before and after Maneuver.lambert implementations:

With 0.12 version:

from astropy import units as u
from astropy.time import Time

from poliastro.bodies import Earth, Mars, Sun
from poliastro.iod.izzo import lambert
from poliastro.twobody import Orbit

LAUNCH = Time.now …

The End of the bonding period

Today bonding period ends for all students selected at GSoC'19. The aim of this period was to learn more about your project community: get in touch with mentors, other developers and their future ideas on the software...

As I said in my last post, I started contributing to poliastro several months ago, even before GSOC was announced. Therefore, and since I am taking my final exams, all my efforts were towards passing them.

But today the coding phase starts! That means we all should start working on our proposal features.

The coding phase at poliastro

The release of poliastro version 0.13 is getting closer. During this first part of the coding phase, I am planning to solve for different issues, most of them related to frames, check out milestones 0.13.

Frames are …

From my first pull request to GSOC student

Hi, my name is Jorge, and I am one of the selected students for this GSOC edition at poliastro under the OpenAstronomy organization. I started working on poliastro project after Juanlu came to my university to give a talk about Open Source software in engineering.

After forking poliastro, I decided to improve API Docs, which gave me an overview on how the project was built and how the different modules talked among them. I had no idea on how Git and GitHub worked and therefore, when finished with the docs my first pull request was quite massive...

But after that I started feeling more confortable with GitHub and Sphinx, the tool used nowadays in poliastro for building documentation. Then, I decided to work on a porkchop plotter.

I spent the week after …