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

Revision as of 14:45, 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

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: will aim to observe 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.

Recipe 1: imaging with a single filter

This recipe describes the Configuration and Instrument Configuration options for Mookodi's imaging mode.

Configuration

• Instrument Category: IMAGE
• Instrument: 1M0a_Mookodi-Img
• Guide Mode: For single short exposures (~60s) guiding isn’t necessary (Off), but for longer exposures, or multiple short exposures, it is advisable to use the autoguider (On). The "optional" tick box is not implemented so you can ignore it.
• Type: Choose Expose here.  Other applicable options are Bias and Sky_flat, but these are taken automatically on a regular basis, so you will have access to them without observing them as part of your proposal.
• Acquire Mode: The options are as follows, where AcN stands for "acquire nearest star" and "Acq" means to "acquire RA & Dec":

1. AcN:OFF&Acq:OFF: this option simply points the telescope and starts the observation without making any pointing adjustments. In other words, you are reliant on the telescope's pointing accuracy.
2. AcN:OFF&Acq:ON: this option will centre the requested coordinates on the centre of the CCD. This is a good default option, but should definitely be used if (i) you have entered the coordinates of a space between stars, e.g. to fit both an target and a comparison star in the field; (ii) the field is crowded; and (iii) the target wouldn't be visible in a four second acquisition image.
3. AcN:ON&Acq:ON: this option first centres the specified coordinates on the centre of the CCD, then adjusts the pointing to recentre on the brightest star found within a 3 arcsec search area around that position. This is useful for transients which may not have such accurate coordinates.

• Dither: Select None as this is not commissioned on Lesedi+Mookodi.

Instrument Configuration

For a single filter, you will only need one instrument configuration.

• Exposure Count: Enter the number of consecutive images to take with this instrument configuration and the specified Exposure Time.
• Readout Mode: The options are 1x1HighFastOpen, 1x1HighFastAuto, 1x1HighSlowAuto, 2x2HighFastAuto with the format Binning_Gain_Readout_Shutter and the following definitions:

1. Binning: 1x1 (platescale 0.59 arcsec/pix) or 2x2 (1.18 arcsec/pix)
2. Gain: High (for faint targets) or Low (bright targets)
3. Readout rate: Fast (5 MHz - read noise 13.6 electrons) or Slow (0.05 MHz read noise 3.3 electrons)
4. Shutter: Open must be selected for multiple exposures <60 seconds (time series will therefore typically be 1x1HighFastOpen).  Otherwise Auto for longer exposures.

• Filter: Mookodi has two filter magazines, which the OCS calls Filter and Obfilter (below).  There needs to be one filter – and only one filter – in the beam at any time, so you need to select one from one of the two magazines.  In this box you can select an SDSS filter.  If you want to use a clear filter, it is in the next field, so select OUT here.
• Obfilter: If you have selected an SDSS filter in the Filter option, select OUT here.  Otherwise select Clear.  Do not select OrdBlk_Fltr - this is for spectroscopy.
• Slit: must be OUT.
• Grism: must be OUT.

Offset RA/Dec: this is not implemented so should be left blank.