2.3m Automation FAQ
Q: How does the Automated 2.3m system work?
The Time Allocation Committee (TAC) now awards telescope time to successful applicants in units of hours, rather than nights. The applicant-come-observer prepares their observations with a web-based tool and submits them into a pool. The Automation system uses a just-in-time scheduling model to select observations from the pool, taking into account the constraints applied by the observer, the TAC and the current observing conditions.
Q: Do I need to factor in the statistics on time lost to bad weather when requesting an allocation of time?
No. You only need to request the time needed to execute your science observations.
Q: Do I need to request time for instrument calibrations or standard stars?
Maybe. The Automated system does instrument calibration observations for the most commonly used configurations every afternoon on behalf of all potential observers. It also schedules additional calibrations in the morning if the afternoon calibrations do not provide the essential data needed for reduction of the observations taken during the night. Standards are also observed during astronomical twilight for the common configurations, weather permitting. Data for all of these routine observation is available to all observers and has no impact on their time allocation. If this data is inadequate for your science requirements you can schedule calibrations as part of your observation, but then you do need to factor the time required for them into you allocation request. The standard configurations are
- RT560 - B3000, B7000
- RT560 - R3000, R7000
- RT615 - B7000
- RT615 - I7000
Twilight sky flats are also observed semi-regularly for the configurations listed above, and those listed below.
- RT480 - U7000
- RT480 - R7000
Q: Do I have any control over when my observations will be scheduled?
This depends on the privileges a successful proposal is granted by the TAC. The Automation system supports three kinds of scheduling - Flexible, Fixed and Target-of-Opportunity (ToO). A ToO observation is considered urgent and the Automation system will abandon a executing non-ToO observation in order to start executing a ToO observation. A Fixed scheduling observation has a specific time-window in which the observation is to be executed. Flexible scheduling does not have any explicit time constaints and the observer has absolutely no influence on when an observation will be executed. The TAC limits the allocation granted to ToO and Fixed scheduling as they impact the overall efficiency of the system.
Q: What kind of constraints can be applied to my observations so the data will meet my science requirements?
For each observation the observer sets the upper bound to the acceptable sky brightness in terms of the lunar phase, an upper bound to the acceptable seeing, the minimum angular distance from the moon and the minimum acceptable transparency of the atmosphere. The Automation system use these as constraints in real-time when selecting observations and as requirements throughout the duration of the observation.
Q: Why isn't airmass a constraint I can set for my observation?
The scheduling algorithm is designed to optimize data quality whilst prioritizing observations based on the TACs directives. Attempting to observe targets at low airmess is implicitly part of the quality optimization. Observations that are urgent are prone to being observed at high airmass, but the observer can bias the scheduling algorithm in an attempt to trade urgency for quality.
Q: How precise is the acquisition of my science object and can I control where in the field of view of of the IFU it is placed?
The final step of the acquisition process is usually based on measuring the centroid of a point source with known coordinates. The precision is typically sub arcsecond and the accuracy is usually limited by the uncertainty in the source's coordinates. Not specifying the proper motion terms is the usual cause of poor acquisition accuracy. The science target coordinates always apply to the center of the field of view in the region of interest and they need not correspond to a specific source.
Q: Why did acquisition fail yesterday but succeed today with no change to the observation description?
Transient or localised cloud is the most common cause of the acquisition failing. High residual pointing error in poor seeing is the next most common, but neither case is common in practice. The system is more tolerant of small pointing errors if there are multiple catalogue stars in the field, since this increases confidence we're pointing at the required target. In good conditions the Automation system will reliably acquire well over a hundred objects in a single night without a single failure.
Q: If the acquisition fails, or there is a system fault, or bad weather interrupts my observation, do I need to resubmit it?
Probably not. If your observation was abandoned due to bad weather or ToO observation then it is returned to the pool and may be reselected later during the same night. The quality optimization makes this unlikely unless your observation was high priority. If there was a fault or a failure to acquire then the observation will mostly likely be automatically returned to the pool the next morning. It will be returned to the pool automatically up to three times. If the status of an observation shows in the observation preparation tool as fault or failure in the afternoon then you will need to investigate and consider submitting with an alternative configuration.
Q: The TAC assigned a low priority to my proposal but I have an observation I consideer critical and urgent. What should I do?
You can make a case for special consideration to the TAC, but they assigned priorities due to a range of policies and established agreements, so you would need to have a very strong argument and a change in circumstances that effectively strengthens your science case substantially.
Q: The TAC assigned high/medium priority to my proposal but none of my targets have been observed yet. Why not?
This is an easy question to ask but it's not always easy to answer. The scheduler is balancing competing interests and there is no reason to expect your allocation will be consumed at a uniform rate. You are sharing access to the telescope and instrument with other proposals but you don't have visibility of their priority or constraints. The TAC grants a total allocation that is schedulable in principle when amortized over the quarter/semester.Carefully check you have not over-constrained your observations, and then be patient. Note that Fixed scheduling is intrinsically high risk because ToOs and bad weather can eliminate your window of schedulability. If you've not had a single observation after a full lunar cycle then seek advice from the RSAA software engineering team.
Q: Are all of the observations from high priority proposals completed before lower priority proposals?
No. The scheduling algorithm is heavily biased by the TAC assigned priorities, but the Automation system works with what is in the pool when it is time to select an observation. The suite of constraints and the time remaining in the night can mean a high priority observation is not available but a lower priority one is. It will choose the latter over sitting idle.
Q: How much of my time allocation will be spent on an observation?
The web-based observation preparation tool computes the nominal duration of each observation based on the options you choose. This is based on the true run-time of the deterministic aspects of the observation and an additional 90s per observing block as a contribution to operational overheads for slewing, acquisition and instrument reconfiguration. Once successfully observed the pre-computed duration is added to your account, irrespective of the actual run-time. There is no charge for observations abandoned part way through, no matter the cause, even though some useful data may be obtained and archived. Note, the overhead may be significant for programs needing large numbers of short observations.
Q: Can the total duration of my prepared observations exceed my allocation?
Yes. Once your allocation has been spent the scheduling algorithm strongly biases against selecting more of your observations, but it will not completely prevent it. Because you have no direct control over the order in which your observations are executed you may not get the precise set of observation you wanted if you choose to oversubscribe. It's better to stay under your allocation until it has been consumed and then prepare additional observations to compete for any surplus time. If your proposal was for paid time then any surplus you choose to pursue will also be charged at the appropriate hourly rate.
Q: Can I assert scheduling dependencies between two or more observations?
No. The Automation system manages a pool of observations, it does not manage observing programs. All observations in the pool are independent. If you wish to apply constraints, such as 'if observation X is observed then observation Y needs to be observed within Z days', you need to implement this via your own external scheme. Access to non-GUI interfaces to facilitate the status monitoring you would need to build a functional implementation is available on request.
Q: Can more than one person have rights to submit observations for a single proposal?
Yes. Any reasonable number of observers may collaborate on a proposal, and all have the power to submit observations that spend against the proposal's allocation.
Q: Can I collaborate on more than one proposal in a quarter/semester?
Yes. There are no limits on how many proposals you co-manage at any given instant.
Q: Do I have to prepare all of my observations in advance of the start of the quarter/semester?
No. You can add observations at any time of day or night throughout the quarter/semester. However, the system can't operate efficiently with a depleted pool. Proposals limited to Flexible scheduling are expected to prepare at least 20% of their allocation prior to the start of the quarter/semester, and to keep the pool well populated at all times.
Q: Is there an API for managing observations via C/C++/Python/...?
No, but there is a well defined interface and code-based submission of observations is certainly feasible with almost any client that supports authenticated HTTPS. Observers that have a specific need to use programmatic methods of submissions should discuss their use-case with a member of the RSAA software engineering team. Note, the observation preparation tool includes many sanity checks, and there is only minimal validation server-side. This path is not for the faint hearted and free technical support will be very scarce.
Q: I discovered a problem with the instrument when reducing the data and I need to reobserve the target. Can my allocation be increased or the spend reduced as compensation?
Adjustments will be considered if issues are raised in a timely fashion. Contact the TAC to discuss your specific case.
Q: Do I need to include an acknowledgement or citation in my publications that are based on data obtained via the Automated 2.3m observing system?
Please consider including the following acknowledgement.
The automation of the 2.3-metre telescope was made possible through funding provided by the Centre of Gravitational Astrophysics at the Australian National University.