search

astropy / astroplan

Observation planning package for astronomers – maintainer @bmorris3
https://astroplan.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
200 stars 109 forks source link

[Enhancement/tutorial] Custom constraint tutorial with the Hobby Eberly Telescope #473

Open gully opened 4 years ago

gully commented 4 years ago

Hi astroplan team! Thanks for making a great software. I made a tutorial about how to use astroplan with custom constraints for the Hobby Eberly Telescope's fixed elevation design. Is this something that would interest astroplan? I am happy to submit it as a pull request, maybe with a bit of guidance for converting to rst. Here is a link to a gist of the Jupyter Notebook:

https://gist.github.com/gully/c7afb57c805bbd3d87a91d1fdf53791c#file-het_observability_constraints_with_astroplan-ipynb

bmorris3 commented 3 years ago

Hi @gully,

First off, sorry this took me so long to respond to. Finally getting caught up on things now.

So many things to say:

  1. This is a really awesome tutorial, I've always wondered how much work it would be to support this use case, and I'm really glad it was feasible
  2. I love the parametric solution to the visibility constraint – the emulation of the original figure is 👌
  3. Your implementation looks like astroplan is intended to look, good work!
  4. Do you have access to a few observations (with their obstimes) made by HET that we could use to "spot check" the constraint results, as you say at the bottom?
  5. Would you have time to turn this into a PR? It shouldn't take much work since you really polished that NB nicely, but of course I know you're busy.
gully commented 3 years ago

Hello! :wave: Yay! Glad this demo/tutorial is in the right direction.

Some of the impetus for this feature has been slightly subdued-we now programmatically query the HET Observability website and web-scrape with BeautifulSoup, since there is extra metadata encoded in the website that I couldn't figure out how to put into astroplan easily. But now looking back on it, this notebook is still pretty useful. Hmm!

I could potentially revisit this notebook as a PR. It looks like your tutorials are in RST, how do you convert from ipynb to RST?

Related question--- I wonder if there is a way to turn TESS observability into a constraint? I suppose reading-in TESS-provided bounding boxes and dates? Maybe something @mrtommyb would be open to supporting through the TESS GI?

mrtommyb commented 3 years ago

I think the right way to provide TESS constraints involves using TESS-point which was developed by @christopherburke.

bmorris3 commented 3 years ago

Agreed with @mrtommyb, astroplan is focused on supporting ground-based observatories.

since there is extra metadata encoded in the website that I couldn't figure out how to put into astroplan easily.

Might I be able to help, or do you think that info is not relevant to astroplan?

It looks like your tutorials are in RST, how do you convert from ipynb to RST?

Probably the simplest way is with nbconvert.

gully commented 3 years ago

Regarding TESS-- the observations I had in mind are contemporaneous with TESS, and so the TESS observability serves as a "constraint" as such. But I suppose the key idea is that filtering on TESS observability is a bit complicated, and in practice should be done separately from astroplan, which I think makes sense for the most people. Plus even if there were a straightforward way to incorporate TESS constraints into astroplan, someone would have to maintain such features, and with TESS sectors changing and getting added from time-to-time, such maintenance would be cumbersome for TESS GI or whoever in addition to all the existing and good outlets already available. For example, a good workaround in my case is down-select a target list based on say wtv, and then one could hypothetically group targets by Sector, which in turn have an already implemented date constraint.

After I sent the "how do I do X?" question I realized I should have just Googled it. lol. Thanks for pointing me towards nbconvert, which I haven't used in a long time.

The extra metadata in the case of HET is subtle--- the fact that they quantize observability windows into "tracks", the parlance requested in proposals. They also encode ostensibly up-to-date info about priority conflicts (e.g. HETDEX program gets most Dark Time, but with some holes) on their page, so that's hard to implement natively. Overall thinking about how to schedule HET is more subtle than most queue telescopes because of its non-standard limitations and the surveys that have adapted to those constraints.