Scheduler Updates


#1

hi @james.synge could you just link the github repos where the current scheduler is situated so I can have a quick run through of the particular code base and ideally how should one go about to beginning contributing like should one dive straight into prototyping the project or begin with bugs etc?

cheers!


#2

Hi! I am Nikhil, I am currently studying in 3rd year in IIIT Hyderabad(B. Tech Computer science), India. I am interested in the project ’ Scheduler Updates’ as it involves application of GCP and cloud functions.

I have had used cloud functions, just for practise, to deploy and test some web-app. Really excited to get some hands-on experience via this project.


#3

I guess this is the link to the current scheduler https://github.com/panoptes/POCS/tree/develop/pocs/scheduler
And this is repo to host the various GCP techonologies:
https://github.com/panoptes/panoptes-network


#4

Nikhil, that’s exactly right.


#5

Aditya,

Coming back to your question about how to get started, let’s look at the current approach: each unit (robotic observatory) has the POCS software installed, which includes a small file of targets; for each target there is a names, a location in J2000 coordinates, and a priority (there are other attributes, see here for an example). POCS uses astroplan to determine where each target is relative to the location of the unit (which might actually be on the other side of the Earth, so not visible), what angle it will be at relative to the horizon, etc., and uses these to decide on the target for which we can get the best images. For example, a target that will be low in the sky isn’t as good as one that will go straight overhead because there will be less air to look through for the latter (lower “air mass”), so there will be less extinction and likely the stars will suffer less twinkling (also called scintillation).

Each of the scopes is currently doing the above independently. This means that two units that could observe the same field on the same night (e.g. one in Tuscon, Arizona and one in Hawaii) won’t currently attempt to do so. Therefore, we’d like to introduce a protocol by which a unit can request from a remote server its next target, or a list of targets. At first the server could have the same behavior as the current scheduler (i.e. independent scheduling), but then we can introduce some coordination; e.g. given a set of scopes, we can group them into those which can see overlapping parts of the night sky, and then come up with the best target in that area of overlap, and hand that target to each member of the group.

From a science perspective, this will result in more continuous observations of the selected target, which means that we’re less likely to miss an exoplanet transit. This mechanism also makes it easier to participate in exciting observations, such as of a comet or supernova; these are referred to as a “target of opportunity”).

I hope that helps with the background. We can have further discussions about protocol if you’re interested.


#6

Hi! I am Ziang Gao from China. I am studying in 3rd year in Nottingham University, U.K… My major is Computer science. I am also interested in ‘Scheduler Updates’ project.
I have experience in Python and building stuff on the cloud. This project seems that can give participants a lot of practice. I am really looking forward to participating in it.


#7

I have some question about the project. As you said above, POCS software is installed in units. It seems like unit itself cares about its own targets.
This project aims to divide scheduler functions to cloud. Is that means, a server in the cloud should be built, which is responsible to send observation information (e.g., field information) to each unit? And units are only responsible for operating observations and leaving scheduling task to the cloud. Is that right?


#8

Yes, that’s exactly right. Most of the scopes (units) are operating at locations where good internet service is available, so it would be reasonable for each scope to contact a central server to request the next target to be observed. We’d still want to keep the ability for a scope to be operated without internet, but as implied in the Message-based API topic, this could be done by having the core software on a scope contact a local server or a remote server, thus allowing for independence of the core software from the scheduler.


#9

And I think a later step for the cloud scheduler would be to take some parameters that could specify for how long of a time you wanted for valid targets. In this way you could query for example for the next 180 days and get a larger list. There’s more to that scenario however so for now we just assume the cloud function would respond with whatever target is best for the given moment.