Separate target info from priority and other selection info

[jamessynge]

I propose that the targets info should be available without any priority info, but with info that can be used to make decisions. For example, instead of having a priority and exposure time for a target, we could have a info about the magnitude of the star and, if known, the depth of transit(s). Ideally, we'd have access to transit ephemera, perhaps by querying a service.

We can then use separate file(s) to provide info about the mapping of magnitude to exposure, which can vary by scope. We can have magnitude limits for a site (e.g. PAN001 will be able to see a far dimmer star than PAN006 can). And we can have exposure limits for a site (PAN001 can take a longer exposure than PAN006). Finally, preference info such as how long to observe a target before and after the transit.

I'd like to use this sort of data to inform the selection process, so that I can use the same target info as any other unit, but provide different parameters for selecting targets. And it would be great to have a command line tool that allows me to get a "prediction" of what will be selected on the next few nights, assuming good weather.

I add issue this in the context of adding in targets for the next few nights where I need to edit the standard targets file (simple.yaml) in order to change priorities.

@wtgee: your thoughts?

[wtgee]

Certainly an interesting idea. I think there are a couple of things to consider. Ultimately we will want to have two distinct observing modes: a survey mode where we tile the sky and aim for some definition of coverage (depth vs width) for each of the tiles; and a follow-up (or direct observing) mode where the item at the center of the field-of-view is the item of importance.

Currently we are operating in a quasi-direct observing mode where we have fields that are named after the object that is placed in the center. The purpose of this is of course to validate against known exoplanets but, as you point out, it's partly useless without some of the other information regarding those transits.

Ultimately I think we want to keep the mechanics of the scheduler (priorities and weights) as that is well established and fairly robust (more info in the outdated scheduler wiki, including references).

However, what I do think we need is something that sits in front of the targets list and acts as a generator for those priorities and weights and that is exactly the kind of thing you are proposing above. This could work both for the survey mode and for direct observing mode.

There's plenty to think through with this, which is why we didn't want to get hung up on it in the beginning and instead made a fairly dumb scheduler that just worked. Next steps would be to add some constraints (such as #496) that provide more scheduling options.

At SPIE I talked a number of times with one of the engineers at the MMTO who has been doing a lot of scheduling work with astroplan lately, mostly on building up a number of such constraints. He said they should be making their way upstream in the next few months.

Additionally, the goal was also to always have the targets edited via some kind of easier-to-use web interface rather than a direct edit of the targets yaml file. I agree that can be a big pain. A good and fairly easy first step might be to build that into PAWS. The auto rereading of the targets file has already been integrated with that goal in mind.

I have also been thinking a fair amount about the networked scheduler. It would be interesting to just operate a web service that accepts a json object with location information (or just a PANID) and which returned a valid target. A centralized scheduler has interesting potential and I think is the way we would ultimately want to go. It could also provide, e.g. a list of valid targets for next 3 months.

[wtgee]

Adding @joshwalawender as he has done a lot with scheduling in general.

[wtgee]

Note a huge factor, but also note that scheduling on the Raspberry Pi takes a fairly significant time. Assuming even a modest web connection a query to a scheduler service would invariably be faster, especially as we add more constraints.

[jamessynge]

Thanks for the detailed response. I agree that a web service is the way to go for the survey, and for priority overrides. We'll still need a local means to provide both extra constraints and priority boosts for locally selected targets. Since all units likely to be operational in the next 6 months are also likely to be connected to the internet, how about if we make it a priority to create the web service, taking as input the coordinates, obstructions, magnitude & exposure info, etc. This can start with the existing code.

I'd like to see it extended at some point to take into account the weather forecast so that we don't decide to prioritize observing a deep transit due at 1am, skipping a less good transit at 11, when the forecast is for rain starting at 12:30.

Is astroplan pure Python? And the rest of the dependencies for the scheduler? If so, could we trivially write this as a app engine app?