Cleaning Up and Documenting

This is my final blog for the Google Summer of Code, wrapping up the work that I did for it.

Astroplan has been fantastic to work on. Over the summer we have implemented a scheduling module complete with tests and documentation. I have written and fixed code all over the package, some of which got added and some of it was rejected or required further modification. The code that I wrote can be found here: a list of my pull requests to astroplan, and a list of commits that were in the accepted PRs. As a part of the documentation I wrote a tutorial on how to use the scheduling module that can be found in the astroplan documentation.

I am planning on continuing to work on astroplan after the Summer of Code ends, especially working on improving the scoring and scheduling currently in place.

Many Merges into Astroplan

During the past two weeks, a lot of PRs were merged into astroplan (17 as of today, 5 of which are mine). These have moved astroplan over to astropy 1.2.1, made Constraint outputs more consistent and added new functionality and bug-fixes, and condensed a few methods, in the Scheduling module. It has been really cool seeing all the different people adding to the package and trying to make it better.

My focus is now more heavily on writing tests, documentation, and tutorials as I get closer to the end of the Google Summer of Code. I'm looking forward to continuing to work on astroplan after the Google Summer of Code ends.

Scoring and Scheduling Constraints

My work during the last two weeks has been on writing a separate scorer as well as writing the scheduling constraints that will allow a scheduler to group blocks together. I also would really like to see the features included in Stuart Littlefair's work be able to be merged into the astroplan master, and so I've been trying to work on finding the issues preventing the package template update from being merged. There are still some issues left that I am not sure how to fix, which may partially result from my attempt at fixing it.

Update in direction

A large portion of the work I have done so far has been improving and fixing bugs with the schedulers that are currently in Astroplan. From conversations with mentors and from feedback on my straw-man API that I wrote for how a user should be able to interact with the schedulers, where conversation is still ongoing and feedback welcome, we have realised there a some things that the current schedulers really cannot support. The most common part is allowing a user to designate multiple observing blocks that need to observed consecutively or during the same night. Looking forward I will be working on making the code reflect the straw-man API and making the scheduling more extensible.

Implementing a Schedule

One week ago the work that had been done by Stephanie Douglas and Erik Tollerud was merged into astroplan. I made a straw-man API for scheduling in astroplan, partially based off their work, and submitted it as a proposal PR to get feedback on what makes sense and what should be added/changed to the way that users will interact with the schedulers.

Most of my work this week has been on creating a Schedule class that would provide a consistent format for the output of the schedulers. This process required modifying the schedulers to use the Schedule class. During my modifications I found, and fixed, a couple of bugs in their code that were causing faulty results. I also started writing the body of tests that will be needed to make sure each part of the scheduling is working properly. My PR for the changes can be found here.

Looking forward, I'm going to be working on the scheduling to make it more flexible and extensible. The first step for that will be allowing a user to input multiple targets that must be observed in succession, and the code being able to handle that properly.

Getting feedback and planning

This last week has been a productive one for me, in coding, communication and understanding the underlying framework used in astroplan. My mentors mentors Eric Jeschke, Brett Morris, and Erik Tollerud have helped me in coming up with tasks that give me a better understanding of the code and expectations while adding to astroplan. The main piece of work that I did is on a constraint that distinguished between dark grey and bright time. While writing it, I gained a better understanding of how constraints are used in astroplan and how to write tests for them. The comments on that, and a doc page for terminology that we use have, helped me understand the importance of communication is for this project. There are many other astronomers who have a better understanding of syntax and expectations than I do who can help me understand when an error occurs or a description is ambiguous.

I'm starting work on the scheduling side of things and my first task was to write out how I would imagine working with the scheduler would look like. Right now it looks like https://github.com/astropy/astroplan/pull/178, though it might change from feedback and discussion. At the code level, I'm starting to work on creating a schedule class that the schedulers can interact with.

Gitting started

Getting started working on astroplan has been a mix of reading up on work people have already done (https://github.com/astropy/astroplan/pull/137, https://github.com/astropy/astroplan/pull/151), brainstorming scheduling styles, planning using astroplan, and figuring out how git works. Working with git has been interesting and being told what to do by Brett Morris and by Github has been very useful in learning the flow of pulling, branching, committing, pushing etc. I'm looking forward to start coding in earnest as a developer.

Community Bonding Update

I've been enjoying observing the Astropy mailing list, the two main threads that have interested me are about NDData with LSST and the freezing of features in preparation for the next Astropy version's release. The conversation with NDData and LSST has gone into if/why backwards compatibility is needed in certain parts of NDData and if that outweighs the benefits of having code that is compatible with the needs of LSST. The conversation has also gone over what other methods LSST could use that would satisfy their needs without requiring fundamental changes to NDData. With the feature freeze there is a lot of talk about the process of adding to and maintaining Astropy and the tests that features have to pass before they can be added to the main Astropy package. It also gives an interesting look into the development cycle of a Python package, how for a release each part of it has to be fully functional and consider the changes that have been made to the rest of the code base in the case that a function has been changed in a way that is not backwards-compatible.

Another cool part has been watching the Facebook group created by and for this year's GSoC interns. The community is very open and willing to help on coding as well as meet up with other local interns.

Related to my project, I've been looking through the current code and documentation for Astroplan for what I can use and add to during my project.

This blog is for GSoC 2016

I plan to work on the Astroplan package within Astropy.