Enhancement proposal: use astroquery to get the stellar distance and radius like I do in this example, rather than hard-coding the answers into the notebook. You'll need to come up with a more clever way of selecting the correct answer from the query response than choosing the first row, as I did in the example. You might find that the answer is the star closest to the input coordinates. You can measure distances between coordinates using SkyCoord.separation(). 📐

I don’t know if this is a better long-term solution than pwv_kpno, but there’s a python package on PyPI called skycalc_cli which queries the Cerro Paranal sky model for transmission spectra among other things, and I found the source code for the Python query that it sets up, which I’ve posted here

In principle, Tiffany could pare down this code and design small algorithmic queries for the atmospheric transmission spectrum as a function of airmass (among other things). Perhaps that code might even make up enough substance for an astroquery PR.

Enhancement proposal: ultimately you'll be making a PR to astroquery which queries the VO service from the SVO Filter Profile Service 🌈 , but for now, you can do something simpler to retrieve the filter response curves for Sloan filters. Use the astropy.utils.data.download_file function to grab the response curves for each filter from the following links (and remove the step in the tutorial which says 'you can download the filter response curves here...'). The goal here is to avoid including any data files in the PR or requiring the user to manually download something which can be done in the code.

• SDSS r
• SDSS z

Why do we need it?

I think it would be beneficial to:

1. Create milestones from relevant GSoC 2019 deadlines: https://developers.google.com/open-source/gsoc/timeline
2. Assign milestones to all the issues and pull requests.

This way, even without a project board, we can guesstimate the work load and whether we are ahead or behind in the project.

Since we'll have PHOENIX model spectra of HAT-P-11 and TRAPPIST-1, it would be fun to model their count rates through a second telescope 🔭 . I'm thinking perhaps we can use Kepler, since (1) Kepler observed both HAT-P-11 (Kepler) and TRAPPIST-1 (K2); (2) it's a space telescope and therefore shouldn't depend on our atmosphere model, making it a good sanity check.

Here's some of the info you'll need to do Kepler:

• Kepler instrument+filter response – remember to use astropy.units.data.download_file to grab this file rather than including it in the PR
• Answer key via MAST: HAT-P-11 measured counts: 2.8e6 e-/s; TRAPPIST-1 measured counts: 5.70e3 e-/s
• Kepler Gain (which you might not need since we're reporting e-/s above): 110 e-/ADU (source)

Open source code isn't technically open source until you've assigned an open source license to the repository. Please add the BSD 3-clause license to this repo (see here for a shortcut on how to do this!).

I suppose before #12 gets addressed, it'd be natural to request that you use tynt in the notebook.

While the destiny of the tynt package is under consideration (affiliated package vs. PR to synphot) , it should be sufficient to install tynt locally (pip install tynt) and to add a requirements.txt file to the notebook's directory which simply contains the name tynt, like in this tutorial.

It looks like tynt will be capable of returning filter transmittance curves as either astropy composite models or as lookup tables. It'll be interesting to do a little profiling to measure how the performance of the two different methods compare with synphot computations.

It is easier to review if you open a pull request in this repo from your other the-first-notebook branch. Having a PR open also serves as a reminder for us.

As discussed during tag-up on June 4, 2019.

Let's make a final cell which compares the synphot expected count rate (y) with the measured count rate (x), with a 1:1 line over plotted; perhaps with two subplots – one for APO, another for Kepler.

Try adding a boring elliptical galaxy to the tutorial to see if its synthetic photometry is also biased in the same direction as the emission line galaxy example. This will be diagnostic: if the boring elliptical is similarly biased, then we might be doing something wrong; if the elliptical falls on the other side of the 1:1 line then we might be seeing the effect of weather, for example.