Quick Update - Thursday 26 June 2015

Quick update!

Today, I:
1) Solved some module import problems by fixing a path issue.
2) Made an ipython notebook with examples on how to use the plot_airmass function.
3) Modified plots.py.

Quick Update - Wednesday, 25 June 2015

Quick update!

Today, I:

1) Started a plotting examples notebook (to both test plots.py and to showcase to use the plotting methods).
2) Tried to figure out why I couldn't import my plotting methods from the examples notebook.

Quick Update - Tuesday 23 June 2015

Quick update!

Today, I:

1) Updated the plotting api PR and responded to comments.
2) Had a meeting with the Astroplan team.
3) Worked on plots.py, the code for the plotting aspect of Astroplan.

Quick Update - Monday, 22 June 2015

Quick update!

Today (and this past weekend), I:

1) Played around with astropy.time
2) Updated the plotting API strawman.

Are we coding now?

¡Hola!

As sad as I am that México did not make it out of the group stages in the 2015 FIFA Women's World Cup, I managed to pull myself out of my depression long enough to get some work done on my Google Summer of Code project. 

...And what do you know, I even got a pull request merged into Astroplan's master code. :) 

Insert boastful Drake lyrics here.

My baby code goes to kindergarten 

I worked on PR #5 to Astroplan (containing my contribution to the core code of the project, as well as documentation outlined in my last big post) for what I'm sure was too much of last week. 

I was getting very cryptic error messages when I tried to build the documentation.  I eventually figured out that this had to do with the fact that the old documentation files were not being deleted.  This meant that whenever I changed the name of a class or removed it all together, the Sphinx environment was still looking for the old one. 

One of my mentors, Erik, gave me two possible solutions:

1. Force git to delete all untracked files (Sphinx docs are rebuilt from the repo, so by default, Astroplan's .git_ignore file includes any generated documentation files)
•  git clean -dfx
2. Tell Sphinx to delete all old files from any previous document builds
• python setup.py build_sphinx -l
  
  

 I think I tried the first one, but I can't remember.  

At any rate, the docs built, and the skeleton code I wrote is currently being adopted by my fellow Astroplan GSoCer, Brett, into the actual code base for our project.  Exciting!

Matplotlib & Me

The next big part of the project that I'm (still) working on is implementing the plotting aspect of Astroplan.  

At minimum, we want the three following types of plots:

1. Airmass vs. Time
2. Parallactic angle vs. Time
3. Sky chart 

I now have rudimentary versions of all three types of plots, which look fine--other than the fact that it's hard to feed Matplotlib a series of times formatted like 1200 & 0300 instead of 12:00pm & 3:00pm and expect it to plot data for 3pm *after* the data from noon, so my time-based plots don't look quite right.  

However, I did manage a damn fine sample sky chart if I do say so myself.

One thing I have found out about matplotlib (the Python plotting library) is that, for some reason, you MUST plot points BEFORE you set the ticks and tick labels.  

Also, you will have an excruciatingly "fun" time creating a plot in any projection other than Cartesian (one horizontal and one vertical axis, for all you non-math nerds religiously reading this blog) when 99% of the matplotlib plotting examples and tutorials assume you have x- and y-axes.

Almost as much as this guy.

Quick Update - Wednesday, 17 June 2015

Quick update!

Today I:
1) Figured out how to get a rudimentary sky plot with radial ticks/labels increasing towards the zenith and cardinal direction annotations.

Quick Update - Tuesday, 16 June 2015

Quick update!

Today I:

1) Worked on rudimentary sky-plotting examples.
2) Met with my mentors and our collaborators. 

Quick Update - Monday, 15 June 2015

Quick update!

Today I:

1) Figured out how to build dictionaries to hold generated coordinate data for targets.
2) Worked on making a sky chart plot to show target locations.

Quick Update - Sunday, 14 June 2015

Quick update!

Today I:

Researched and wrote up simple test plotting functions for airmass and parallactic angle.

Quick Update - Thursday, 12 June 2015

Quick update!

Today I:

1) Worked on improving core.py and debugging resulting Sphinx documentation
2) Meet with mentors and solved Sphinx documentation problems

Quick Update - Wed, 10 June 2015

Quick update!

Today (and the day before) I:

Fought with some "AttributeError" messages while building --haven't figured out the issue exactly, but something to do with Sphinx not updating the class/method names from core.py.

Quick Update - Monday, 9 June 2015

Quick update!

Today I:

Reworked and debugged core.py.

Quick Update - Thursday, 4 June 2015

 Quick update!

Today I:

1) Finally figured out Sphinx documentation (?)
2) Worked on plotting API stuff.

A witty title evades me.

Hello, internet friends! 

It's been a long, long week of figuring out how to:

1. Use the tools necessary to build the documentation for an Astropy-affiliated package.
2. Code up the source skeleton for Astroplan and
3. Plan out the API for the plotting branch of our project.

Also: basic, human greetings.

Mock documentation is mocking me.

Putting together the basic Sphinx documentation for a mock source code file in Python seemed pretty straightforward, but it took me a couple of tries to get the HTML files built.  These are the same HTML files that you see in a web browser when you go to a project's Read The Docs page (such as Astropy's).

These are important because not only do they serve as a user manual of sorts--providing useful examples and directions on syntax--but they also describe the structure of the code you're building.  In other words, they show how the "objects" in object-oriented programming are related to the functions that make your software useful.

If the hierarchy of classes, subclasses, and methods is still a bit vague even after perusing the examples (either because you're new to object-oriented code, or a human of normal intelligence, or both), a visual such as an inheritance diagram can be a great way to understand all of the relationships.

Including your unhealthy one with food and violence.

To get Sphinx to work with the setup that Astropy uses (and that we shall use), you have to:

1. Put the code files describing all of your classes, etc. in the folder that contains the source for that module.  For instance, astropy.cosmology's code is in astropy/astropy/cosmology. 
2. Edit the index.rst file associated with that module.  This is the file that generates all the text for your module's documentation webpage.  It also contains commands particular to Sphinx for things like formatting and inheritance diagrams; astropy.cosmology's index.rst is in astropy/docs/cosmology.
3. The last thing you have to do to get the inheritance diagram to show is not as obvious.  Sphinx is telling me to add on ".. inheritance-diagram:: <class or module names>" at the end, but Erik, one of my mentors, assures me that the ".. automodapi::" option in the file should take care of the inheritance command internally....will update when this gets resolved.

Baby steps

An important part of putting together docs and inheritance diagrams for Astroplan is to plan out the basic hierarchy of the classes and methods.

So, for instance, we want to treat an astronomer in an observatory (or even an amateur just looking at the sky from some location) as an object within the framework of Astroplan, thus the Observer class.  Each Observer object will have certain attributes (such as latitude and longitude on Earth, elevation, etc.), and each method acting on an object will perform a specific function or calculation (such as finding out the next time the Sun rises from the observer's location).

For my part, I've taken my fellow Astroplan GSoC-er Brett's API discussion and turned it into skeleton code or frame upon which to add the full-fledged source code (once its written).

In other words, I've made some baby code, soon to grow up into big, strong, kick-ass software.

Close enough.

The plot thickens

The thing about scientists is: We.  Friggin'.  Love.  Plots.

And diagrams.

And graphs.

You show us visual representation of data, and we're all over it like...scientists all over data. 

He's not usually this excited to see us, though.

Inevitably, some astronomer using Astroplan will want to see some plots, and who are we to deny them? 

The plots most crucial to observation planning are probably airmass vs time, parallactic angle vs time, and a skychart showing where targets and guide stars are in the sky at a given point.  We're still deciding which others we will include in Astroplan by the end of the summer.

For the time being, I'm coming to terms with how observational astronomers understand and use airmass and parallactic angle--as opposed to how dreamy-eyed theorists with no practical skills like me do, which is to say not at all.  Part of this is knowing which equations to use, what inputs and outputs are necessary, and what options users would like to have.

The next thing is to write up an API showcasing potential usage for these plots (much like Brett's strawman for the overall Astroplan package)--stay tuned! 

Quick Update - Monday, 1 June 2015

Quick update!

Today, I:

1) Researched parallactic angle--more on this later.
2) Cleaned up code for an observation use case written in Skyfield that generates alt/az coordinates for a few different objects.

Quick Update - Sunday, 31 May 2015

Quick update!

Over the weekend, I:

1) Researched airmass--more on this later.