ACP Scheduler comes with a set of standard constraints that may be applied to Observations. If no constraints are applied, Observations will be eligible based solely on astronomical night (Sun below –18 degrees) and instrument limitations retrieved from the sequencer (ACP).
The Scheduler has a plug-in architecture that allows custom Constraints to be added without releasing a new version of the Scheduler software. Scheduler includes a Constraint Software Development Kit (SDK) for Microsoft .NET 2005 and 2008. Plug-ins are Microsoft.NET assemblies that implement a standard interface. Simply dropping the plug-in into a directory is all that's needed to activate it in both the Browser and the Scheduler.
The following constraints are supplied with ACP Scheduler:
AirMass constrains the Observation to be run when the current relative air mass to the target is at or below a specified value. The relative airmass at the zenith is 1.0, and increases with zenith distance.
The algorithm used to calculate air mass is a third-order polynomial expansion first published by Hardie (1962). It is a fit to Bemporad's data for relative airmass as tabulated by Schoenberg (1929). Its accuracy is better than 0.1% up to a relative airmass of 6.8, and better than 1% up to a relative airmass of 10. Maximum calculated air mass is reached at a zenith distance of 87 degrees (to avoid division overflow).
When AirMass rejects an Observation, it tells the Scheduler when it estimates that the Observation will fall below the required relative air mass (even if it will be on the next night!). If the Observation is the first of an unstarted Plan, the Scheduler will defer the Plan to start at the estimated time given by AirMass.
If the Observation will never fall below the required relative airmass, AirMass returns a failure indication and the Plan will be failed.
References:
This is a special-purpose variation of the AirMass constraint which allows specifying both the maximum and minimum airmass through which the target must be acquired. This constraint is useful for photometric programs which must acquire images of stars at specific air masses during a run. The algorithms used are the same as those of the AirMass constraint.
If you specify a narrow range, you increase the chance that the Observation will be skipped.
Horizon constrains the Observation to be above a specified elevation above the local mathematical horizon. It converts the target coordinates to alt/az for the current location and time, then applies the test.
When Horizon rejects an Observation, it tells the Scheduler when it estimates that the Observation will rise above the required elevation (even if it will be on the next night!). If the Observation is the first of an unstarted Plan, the Scheduler will defer the Plan to start at the estimated time given by Horizon.
If the Observation will never rise above the required elevation, Horizon returns a failure indication and the Plan will be failed.
HourAngle constrains the Observation by sidereal hour-angle. The constraint takes one or two parameters, East and/or West. If both are specified, the Observation is constrained to be within the given hour angle range. Hour angle values are given in units of hours, and may be within the ranges of 0 to 24 or -12 to +12. Remember that hour angles east of the meridian are either negative or in the range 12 to 24 hours.
If you specify a narrow range, you increase the chance that the Observation will be skipped.
If you specify the East value only, the Observation will be constrained to times after it passes the East limit. If you specify the West value only, the Observation will be constrained to times before it crosses the West limit.
MoonAvoid implements the Moon-Avoidance Lorentzian, which varies the avoidance distance from the Moon based on its phase. At full moon the Observation will need to be at its farthest from the Moon. As the brightness decreases with phase, the Observation can be done closer.
MoonAvoid takes two parameters: distance (degrees) and width (days). Observations will not be scheduled if the target is within distance/(1+(0.5 - age/width)^2) of the Moon (see below for Excel formula). This means at full Moon the avoidance will be distance, and width days before (or after) the avoidance will be one half distance. If you are unsure what to use, start out with distance=120 and width=14.
Thanks to ACP Expert user Dick Berg for the idea of a live spreadsheet to help visualize this. His spreadsheet has been translated to HTML/JavaScript and is given below. Enter values for distance and width below and you can see the resulting minimum angular distance from the Moon in the table day by day from new to full Moon.
Distance | |
---|---|
Width |
Age (days) | Distance (deg.) |
---|---|
0 (new) | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 (full) |
When MoonAvoid rejects an Observation, the Scheduler won't look at it again until the next night.
The Moon-Avoidance Lorentzian was formulated by the Berkeley Automated Imaging Telescope (BAIT) team. Thanks to Steve Walters of CCDWare, this is the formula you would use in an Excel spreadsheet: SEPARATION = DISTANCE / ( 1 + POWER( ( ( 0.5 = ( AGE / 29.5) ) / ( WIDTH / 29.5 ) ) , 2 ) )
MoonDown constrains the Observation to be taken when the Moon is down (at least 5 degrees below the mathematical horizon). Simply enabling the constraint in the Browser puts it into effect. There no parameters.
When MoonDown rejects an Observation, the Scheduler will continue to check it throughout the night and the Observation will become eligible as soon as the Moon sets and the current Observation (if any) completes.
SkyCondition constrains the Observation to be taken at or better than the given sky condition. ACP Scheduler implements a simple 4-value sky condition (Excellent, Good, Fair, Poor). This is a result of the work done by Steele and Carter at the Liverpool Robotic Telescope. Since seeing, transparency, and photometric extinction are not independent variables, and are difficult (impossible?) to measure, they chose to aggregate these into a sky condition. The following table lists their definition of the 4 sky conditions:
Condition | Description | Est. % |
---|---|---|
Excellent | Photometric with upper quartile seeing | 15 |
Good | Photometric with 2nd & 3rd quartile seeing | 30 |
Fair | Photometric with lower quartile seeing or non-photometric with any seeing | 25 |
Poor | More than 50% cloud or humidity/wind etc. limits exceeded | 30 |
You are free to assign your own sky conditions to the 4 values (as long as your Observers understand their significance!), and use SkyCondition to suit your needs. In addition, the Scheduler can be set up to have a Sky Condition feed from an external server. For details, see Advanced Features, Sky Condition Input.
TimeRange constrains the Observation to be taken with respect to one or two Julian dates: If you specify EarliestJD, then the Observation will not be taken until after that JD. If you specify LatestJD then the Observation can be taken any time before that JD. If you specify both, then the Observation will not be taken at a time outside that JD range.
The constraints available in Scheduler are provided by plug-ins which can be added without rebuilding scheduler itself. This means you can add a constraint which you may find useful. Constraint plugins are .NET "class library" assemblies; you can develop a constraint with any .NET language (including C++ if you use the Managed Extensions). The only requirement is that the constraint must implement the DC3.Scheduler.IConstraintPlugin interface, and use the Scheduler's DC3.Scheduler.IConstraintHost interface to communicate with the scheduler.
Scheduler includes a Constraint Software Development Kit (SDK) for the C#.NET language. If you must use another .NET language, Contact DC-3 Dreams for assistance. The SDK includes a template project for Visual Studio 2005/2008. It is strongly recommended that you use this template to make your Constraint project. Unzip the SDK and look at the included read-me file.