poliastro: An Astrodynamics library written in Python with Fortran performance
Python is a fast-growing language both for astronomic applications and for educational purposes, but it is often criticized for its suboptimal performance and lack of type enforcement. In this paper we present poliastro, a pure Python library for Astrodynamics that overcomes these obstacles and serves as a proof of concept of Python strengths and its suitability to model complex systems and implement fast algorithms.
poliastro features core Astrodynamics algorithms (such as resolution of the Kepler and Lambert problems) written in pure Python and compiled using numba, a modern just-in-time Python-to-LLVM compiler. As a result, preliminary benchmarks suggest a performance increase close to the reference Fortran implementation, with negligible impact in the legibility of the Python source. We analyze the effects of these tools, along with the introduction of new ahead-of-time compilers for numerical Python and optional type declarations, in the interpreted and dynamic nature of the language.
poliastro relies on well-tested, community-backed libraries for low level astronomical tasks, such as astropy and jplephem. We comment the positive outcomes of the new open development strategies and the permissive, commercial-friendly licenses omnipresent in the scientific Python ecosystem.
While recent approaches involve writing Python programs which are translated on the fly to lower level code, traditional Python libraries for scientific computing have succeeded because they leverage computing power to compiled languages. We briefly present tools to build wrappers to Fortran, C/C++, MATLAB and Java, which can be also useful for validation and verification, reusability of legacy code and other purposes.
The Python programming language has seen broad recognition in the last decade among scientists and academics, being one of the most popular languages in astronomy(Robitaille et al., 2013) and for educational purposes(Guo, 2014). It is highly trusted in corporative environments as well as a tool for scripting, automating tasks and creating high level APIs and wrappers.
However, the current situation of scientific codes is still delicate: most scientists and engineers that write numerical software (which often features a strong algorithmic component and has tight performance requirements) usually do not have any formal training on computer programming, let alone software engineering best practices(Wilson et al., 2014). In fact, in the Aerospace industry there is a sad track record of software failures(Albee et al., 2000; Lions et al., 1996) that could have been avoided by following better software and systems engineering practices.
When selecting a certain programming language for a specific problem, we as engineers have the obligation to consider as much information as possible and make an informed decision based on technical grounds. For example, if defect density were to be selected as the single figure to rank the contenders, well-established languages for space applications such as FORTRAN or C would perform worse than functional languages such as Haskell or Erlang(Ray et al., 2014). Another common misconception is to a