SOCIS 2017 Arnau Prat Gasull - poliastro/poliastro GitHub Wiki

About me

  • Name: Arnau Prat Gasull
  • Age: 21
  • Currently studying Aerospace Engineering at Universitat Politècnica de Catalunya
  • GitHub: aeronau
  • LinkedIn: aeronau
  • Languages: Catalan, Spanish, English and French

I am an Engineering student deeply interested in programming and its uses in problem solving, especially when this problems are related to the field I am willing to build my career in. I am often described as being motivated, responsible and proactive, though I tend to avoid being complimented as such :).

Proposal

As part of the ESA SOCIS 2017 program, I would like to develop Interactive Porkchop Plots as I feel this would be the best way to get introduced to the project. The following is a brief description on how I expect to develop the idea.

Brief introduction

The aim of this project is to develop a solid API to produce reliable Porkchop plot taking advantage of interactive capabilities of matplotlib. I believe this library can provide the tools needed to output a figure like one in the Ideas Page easily (or better).

In order to produce a plot, an algorithm has to be developed. At a first glance, this is the most difficult part of the project (not considering parallelization of code) and will require a good knowledge of Orbital Mechanics. Calculus will be fundamental in order to develop the algorithm.

Once the graphics using Python are created I may develop either a richer interactive tool to visualize the data (e.g. using JavaScript's three.js) or the algorithms required to make the code run in parallel (preferably). Obviously, if everything goes smoother than what I expect, why not implement both?

Notes

I am confortable with matplotlib, but the choice for the plotting tool has to be discussed thoroughly. I prefer working with consolidated libraries that work with Python and are greatly documented. I am aware of the advantages of using Plotly, which can also be considered as a viable option, but my experience with it is very limited. Whichever tool is chosen, it necessarily has to be Open Source.

Parallelization of code can be achieved using multiple tools. Joblib and multiprocessing are easy to use and are well documented, but they can be hard to use alongside Numba, which in its turn provides some interesting features that will have to be explored.

Main difficulties

  • Because of the changes in the ESA SOCIS timeline I have not had enough time to deeply understand the inner workings of poliastro. Even though I have used poliastro on my Ubuntu, read and run some of the code, I find that I will need a few days to get comfortable with the package.
  • Though I know a bit of Orbital Mechanics, I will have to fully understand the Lambert's problem. A good read on this subject is absolutely required (e.g. Lambert's problem, The Application of Lambert's Theroem to the Solution of Interplanetary Transfer Problems).
  • Understanding the implications of the Porkchop plot and its uses may take its time before starting to program anything.
  • I have experience programming in parallel with MPI using C, but none using Python. While the principles may still remain the same, I barely know the ecosystem. I may need help when exploring the parallelization of code.
  • Numba and the multiprocessing library may be incompatible.
  • I am afraid I will need some help in order to proceed in the development of the main algorithm.

Timeline

I will be available from the end (29th) of June to the end of September, but willing to dedicate a good chunk of the day to this project. I expect to work on this project for 12 weeks (approx.) and while I expect not to work on weekends, it will really depend on the work. Here is the distribution of the workload across these weeks:

  • Week 0 (29th to 30th June): Get in touch with the project administrators and members and understand the organization of the project. Re-learn git.
  • Week 1 (3rd to 7th July): Create a detailed workplan after having read all the required bibliography and the code directly related to the idea. Become familiar with poliastro. Study the implementation in alternative projects.
  • Week 2 (10th to 14th July): Gather validation cases from reliable websites and documents. First approach at programming and first lines of code. Check and test the compatibility with poliastro (first errors?). Understand the Lambert's problem and think how the desired algorithm could be implemented.
  • Week 3 (17th to 21st July): Full time coding the algorithms needed to produce the data for the plot. I will need supervision from the mentor.
  • Week 4 (24th to 28th July): Full time coding the algorithms.
  • Week 5 (31st July to 4th August): Full time coding the visualization tool (plots). Take advantage of contour plots in matplotlib. Review of the work done.
  • Week 6 (7th to 11th August): If API is ready: test, test and test (I am faster than I expected). If not: code, code and code (I am slower than I thought).
  • Week 7 (14th to 18th August): If everything is on track, explore code parallelization (preferably) or the interactive JavaScript plotting tool. If not, code API.
  • Week 8 (21st to 25th of August): Discuss code parallelization with mentor and implement first algorithms.
  • Week 9 (28th of Augutst to 1st of Semptember): Code parallelization.
  • Week 10 (4th to 8th September): Test the parallelization.
  • Week 11 (11th to 15th September): Test all code and check if documentation is updated. Final tweaks.
  • Week 12: End of SOCIS. Check if work has been done and the goals achieved. Discuss with the mentor how I have performed.
  • Week 13: To be continued...
  • ...

Notes:

  • As soon as the code grows a little, documentation will be written. Tests will also be documented.
  • At the end of the week a meetup with a member of the project would be desirable.
  • Week 3, 4 and 5 may not strictly follow the plan, as I cannot precisely estimate the work.
  • I may not be available every weekend.
  • The timeline will be refined the more implicated I am with the project.
  • This is a conservative timeline.

Complementary work

I should also say that I can also put my two cents in more urgent tasks whenever possible.

Related skills

Programming has always been a field of great interest to me, and I have explored multiple languages in order to accomplish different goals. I learned my fair share of web programming (HTML, CSS and a bit of JavaScript), but I have since moved on to C, Python, Julia and Matlab. C, Matlab and Python are the languages that I currently use the most and have some experience with them and some of the most popular libraries. I am familiar with Jupyter notebooks and I have used them from time to time for my personal projects. I forgot to say that I am one of those who delivers reports written in LaTeX or Lout with plots created using ggplot2 (R library).

Because I am studying Aerospace Engineering I believe I will be familiar with the vocabulary and algorithms used in the project.

Weak points

  • I have never contributed to middle-to-big projects, which definitely has to be considered a drawback. I want to learn a lot from these project, especially in terms of version control in big projects and contributor-to-contributor interaction.
  • Although I am confortable using Python, I am not an expert. I expect not to have many problems using Python, but I better keep Python and matplotlib's documentation close.

Methodology

When I am faced with a new problem I break it into smaller problems which, when solved, have to be pieced together. In other words, I identify the links between them and organize them according to the order of dependence. Then I rate every problem according to a preference (importance) order. I use this information to choose which problem to tackle at the start of every session. The puzzle pieces are put in common as soon as I can, and a fast revision of the whole project is done after every session/couple of sessions.

I try to avoid skipping areas of code in order to write them later. I want to output a code that can be interpreted and checked as soon as possible. The code I write is always commented, but I will avoid comments that reference obvious operations. I use these comments to write the documentation, which is updated as soon as a change is made.

I will try to be as consistent as possible with the work done and share as much information as possible.

Future work

I have always wanted to contribute to an Open Source project, so if everything goes according to plan I would like to continue being a member of this project. I would like to mantain the work done during the summer for some time.