HSpot allows you to define many special requirements as to how your observations should be carried out. These are termed "constraints". Normally, unless you specify otherwise, your observations will be scheduled effectively at random: the Mission Planning System will simply select a pool of the best set of observations to make on any particular day according to the instrument that is mounted (cycling through the instruments on a strict 28 day rota, so that the observations that require the same instrumental configuration are always blocked together on the same days of each 28 day cycle) and the area of the sky that is visible, irrespective of which proposals they belong to. Once the pool of potential observations that could be carried out with the available instrument on any given day is identified, a sub-set of them will then be scheduled.

However, there are many occasions when you will want to specify that observations should be constrained for one reason or another. Although, often, constraints will make your observations less efficient to schedule, on many occasions it is even strongly advised to add constraints to make them more efficient. How is this?

If you have two or more observations of the same target using the same, or a very similar instrumental configuration, it is quite likely that Mission Planning will not schedule the observations together unless nudged to do so. This is not just a case of inefficient software, it is simply that with a huge database of observations (several tens of thousands), optimising perfectly the order of carrying them out would take so much computer power that it is just not practical. So, effectively, what will happen frequently is that one observation will be made and then the telescope will slew away to another target and later, perhaps months later, have to slew back again to this position, adding dead time to the observatory's work. The way to avoid this and make scheduling more efficient is to force the Mission Planning System to schedule the observations together by grouping them (a grouping constraint), thus removing one, unnecessary telescope slew. Here everyone gains: the observations are more efficient, so less time is wasted slewing and the observer is rewarded by having less overhead charged for the observing programme, thus leaving more time available for other observations.

Similarly, while you may be quite happy to get your data at any point in the Herschel mission, there may be good reasons for needing your data at a particular time (for example, to coordinate it with ground-based observations) or taken in a particular order (the data are useless, or unreducible, unless the requested control observations have been made, so you may wish to ask for these to be taken first). These are just two examples of possible timing constraints on the execution of observations. Constraining how the Mission Planning System can schedule observations with different instruments, or in different parts of the sky generally makes observing less efficient, so such constraints are charged a slightly increased overhead to compensate.

Note

There are also what are termed "implicit timing constraints". This is when you request that your data be taken in a special way that, to Mission Planning, has the same effect as putting a timing constraint on it. These can be the trickiest to handle, as the astronomer may not even be aware that an apparently reasonable constraint on the observation is really so tight, or so exclusive, as to make it totally impossible to schedule. These are requirements such as requesting that the observation be carried out at such a time as to avoid the chopper moving in a certain direction, or such that your scan has a certain orientation. These implicit observing constraints are discussed elsewhere, although all versions of HSpot from v3.4.3 onwards have flagged them as time-constrained observations and the AOR visibility windows calculated by HSpot will be reduced to reflect the constraint that has been applied. For security, after adding a constraint you should check the AOR visibility carefully to ensure that it has not had undesired effects.

HSpot allows you to create TIMING and GROUPING constraints by selecting "Timing Constraints" or "Group/Follow-On Constraints" from the "Tools" menu. When you save your AORs, each timing constraint will be saved with the appropriate AOR and the grouping constraints will be written out at the end of the AOR file. All constraints must be scientifically justified in your proposal for telescope time. It is recommended that you complete all of your AORs before adding Grouping or Follow-On constraints that link them. This will lower the probability of your constraints becoming invalid due to changes made to the AORs included in the constraints.

Warning

Constraints add a hidden overhead to the observatory planning system by making observations planning less efficient. All constrained observations except concatenations will thus be penalised with a 600s "slew" overhead, rather than the standard 180s. When there are several constraints on a single AOR, the concatenation takes priority, so the slew penalty will only be added to the first observation. So, for example, you concatenate two sets of four observations and then place a follow-on constraint between the two chains, only the first observation in each chain will have the time constraint overhead added.