Hey, everybody!
It's been a while since I made a big post--$h!t got crazy what with finding a new apartment to call home, packing all of the books I've accumulated over the years, etc.
However...it has been an extremely productive last couple of weeks, with a couple bits of code merged into the main project branch, and a few other sitting in PR's.
So let's rap.
Mass of air? Para-what angle??
As mentioned in a previous post, I've been working on some plotting functions for my Google Summer of Code project, part of the Astroplan project.Code says what?
After testing preliminary code in some IPython notebooks, I transferred this code to .py files. An IPython notebook is essentially a frozen interactive programming session--you can write, modify and run code from a web browser and immediately see any results (i.e., plots, numerical output, etc.), but unlike a normal interactive session in IPython, you can save your code AND output. A file that ends in .py is just code--no output--and so it's more efficient to store bits of code for a complex project in this type of file. Other bits of code, either in IPython notebooks or .py files, can call the code you save in a .py file, which may contain descriptions of classes, functions and other objects (see my post here)
So, when you've got very preliminary code, it's nice to have it in IPython notebooks, but once it's (mostly) in working order, you need to transfer it to a .py file and put it in the appropriate place in your copy of the repository you're working on. The usual place to put your Python code is in the source code sub-directory, which tends to have the same name as your project. For instance, our project, Astroplan, has a root directory, astroplan. Inside this directory is another one, also called astroplan, and this is where we put our source code.
 |
| Dem files! |
Most projects will have even more subdirectories, each one containing source code for a particular aspect. In order for all this code to communicate with each other, each source directory (including the main one) has to have an __init__.py file.
When a module such as Astropy is being used, __init__.py files help communicate to your Python installation where to look for useful functions, objects, etc., and to make sure there's no confusion about which .py file contains the source code. This is why you can have two modules both containing a function with the exact same name--Python module importing conventions (e.g., "from astropy.coordinates import EarthLocation") plus the __init__.py files make sure everything stays organized.
The plot increases in viscosity--yet again!*
What all the above meant for me was that I had to figure out how all this worked before I could use my newly-minted plotting functions. When you're working on a development copy of a software package, you don't really want to install it in the usual way (if you even have that option). You'll want to do a temporary, "fake" installation of the code you do have so that you can test it (python setup.py build, anyone?). Sometimes this means you'll have to take the extra step of informing your current Python/IPython session where this installation lies.Plots or it didn't happen
The plotting functions for airmass and parallactic angle went through several iterations, and had to wait for some PR's from Brett to get merged in order to use our project's built-in airmass and parallactic angle functions. My PR containing the plot_airmass and plot_parallactic functions finally merged recently--check it out! It also contains some IPython notebooks examples on the usage of these, which will eventually migrate to our documentation page. |
| Airmass vs. Time for 3 targets as seen from Subaru Telescope on June 30, 2015. |
 | ||||||
| Parallactic Angle vs. Time for the same three targets. Polaris would make a horrible target. |
You may notice that the sky plot is missing here--due to technical issues, I moved it to a separate PR. It's unfinished, and hopefully my mentors will have some suggestions *cough, cough* as to how to figure out the funky grid stuff.
