Difference between revisions of "Observation requests for Lesedi+Mookodi"

Revision as of 14:06, 29 July 2024

Getting started with the OCS

If you have been allocated queue-scheduled time on Lesedi, you will need to submit observation requests via the SAAO Observatory Control System (OCS).  Note that you need to have accepted the time allocation first, as instructed in the email informing you that your telescope time application was successful. This is done on the Accept a Proposal page on the SAAO website, where you will be prompted to log in with your Observer Portal credentials, then click the link again.

You will need to create an account on the OCS by submitting the registration form. You should then send an email to Ramotholo Sefako informing him of your username, so that he can link your telescope time to your OCS account. 

Once your account has been activated, you can sign in at the OCS login page.

To submit an observation to the queue, click “Submit Observation” in the top left of the landing page, which will present you with the form to fill in. The first two sections - RequestGroup and Request - can be explained for all types of observations. Beyond that, there are recipes to follow for different types of observations.

Note that while we use the OCS developed by Las Cumbres Observatory (LCO), not all of the options available on the submission form have been implemented. If you are familiar with the LCO OCS, you will notice some differences in the functionality here.

Populating RequestGroup and Request sections

RequestGroup

The first section of the observation request form should look like the image below. Note that you can toggle between the form, the API view and a list of Drafts using the buttons in the panel along the top. You can save a draft any time using the blue button to the right, then load it from the Drafts tab at the top. In this way you can abandon a partially completed submission. It is also particularly useful to save a completed form as a draft once you're happy with it, so that you can load it later to use as a template for future observation requests.

The options for a RequestGroup are as follows:

• Name: Give your request an identifier that is appropriate for your target/proposal/observation type.  This is only for your purposes and need not take a specific format, but you should be able to recognise it in a list of all users’ request groups.

• Proposal: Your proposals that have time allocated to them will be available in the dropdown list.  Select the appropriate proposal for your observation.  If there is nothing in the list and you have accepted your proposal and registered as instructed above, contact Ramotholo Sefako.

• Type: The options are:

1. Queue scheduled: this is a “normal” observation that can be made by the queue when it is feasible to do so, when the other parameters of your request are met.
2. Time critical: if your observation is time sensitive (e.g. a transit, eclipse, etc.), you can specify a window within which it must be executed.  Note that your proposal will need to have been approved as time critical, and have time critical hours allocated to it in order for this to work.
3. Rapid response: this is for observations that need to be triggered as soon as possible, and will interrupt the scheduled queue (but not an observation in progress).  Again, you will need rapid response hours allocated to your proposal to successfully use this option.

• IPP Factor: Intra/Inter Proposal Priority factor.  This will largely be of interest if you would like to prioritise different observations within your proposal; you would give a larger number to a higher priority observation.  Values must be between 0.5 and 2.  If you’re happy for all your observations to have equal priority, stick with the default value of 1.05.  This is a very basic summary, the full explanation of IPP can be found here.

Request

• Acceptability Threshold: Here you would specify the percentage of the request that would need to be done in order for you to accept it as having been completed.  E.g. if you requested 10 exposures and only 9 were taken, the default of 90% would accept this as complete.  Had you specified 100%, the observation would be rescheduled and that time would be deducted from your allocation.

• Configuration Repeats: This must be 1.

• Optimization Type: The options are:

1. Time: favours scheduling the observation earlier in the observing window. Use this option as the default, especially as you can apply an airmass constraint in a later section. Definitely select this for time-critical observations.
2. Airmass: favours observing the target at lower airmass.  Note that specifying this results in a slightly lower chance of the request being observed if the queue is full. 

• Mosaic: This has not been commissioned with Lesedi+Mookodi, so should be left as None.