Time accounting on projects
Time accounting through the night	-When you ACCEPT an MSB the database decrements the time remaining for the project concerned using the Estimated Time from the MSB itself, not from the data headers (to which it doesn’t have straightforward access – you may be doing the query while still observing the previous MSB). -Therefore the QT may in some circumstances (for example a programme with Observations which include too many repeats) not return any MSBs on a programme even though you know that the programme has some viable observations remaining. Another reason for PIs to ensure that their MSBs are giving sensible-looking times of execution.
Time accounting at end of night	-At this point (defined here as the point at which the TSS runs ompnightrep) the data headers are scrutinised, the actual time spent exposing on each project is added up, and the database updated acordingly. Any time gaps with identified causes, and any faults, are also taken into account at this point. -Corollary: if a programme becomes unavailable as a result of MSBs overestimating their execution time, the TSS can give the database the correct time used by running nightrep before the end of the night. -The entries for time spent in each programme are applied to the database at the point where the TSS commits the changes, which can be done more than once through the night (just don’t mail them every time!).
Nightrep detailed function	Two numbers are presented to the ompnightrep user (whenever they run it): 1. The current estimate from the time accounting database. This is usually the sum of all the MSB time estimates for MSBs completed so far during the night. If the TSS has run ompnightrep for this night already and then subsequenctly accepted another MSB for a given project (when the MSB is accepted the CONFIRMED flag will be changed back to ESTIMATED). 2. The value that is placed in the entry widget by default is the value estimated by analysing the data headers. This algorithm works as follows: -Gets UTEND – UTSTART for each file and then charges that to the associated project -Generic calibrations aretotalled up by instrument. A generic calibration is deemed to be either DARK or BIAS at the current time. Further note later on about how these are allocated to projects. -If the project ID is CAL but not DARK or BIAS the time is charged to UKIRTCAL – aka ‘unallocated calibrations’ -A time gap is defined as something lasting more than 6 minutes For any time gap less than 6 minutes, the gap is assumed to be an acquisition overhead and is charged to the project following the gap -Time gaps marked as associated with a fault are ignored. The assumption is that these have already been taken into account via the fault system. -Time gaps marked as UNKOWN are charged to OTHER -Time gaps marked as “INSTRUMENT” are charged equally to all programmes which used that instrument in the entire night.  -Time gaps marked as “LAST” are charged to the programme preceding the gap. -Time gaps marked as “NEXT” are charged to the programme following the gap. -Once the basic totals are generated the generic calibrations for each instrument are allocated to each project that can use them in proportion based on the amount of time spent taking science data for the project. -At JCMT scientific calibrations are charged to projects that can use them (essentially implementing the oracdr rules system) ie each project that could in principle use a standard star is charged for it in proportion to their science time. This is not implemented for UKIRT. -Currently observation status is not taken into account. In principle an observation marked as bad in ompobslog should not be charged to the project. Question is whether it should be ignored (forcing a fault to be filed) or charged to OTHER.
Communications
Emails sent	When using add comment (feedback system)	Comment: mailed from   flex   to   PI   and   support scientist
At end of night	Night report: mailed from   flex   to   ukss, software and ukto
Every morning	List of their supported projects which have been uploaded: mailed from    flex     to  PIs and individual support scientists
As they happen	Fault reports: mailed from    flex   to    ukirt_faults
4pm HST	Report of data being taken on their project the night before: mailed from    flex   to    PIs and their support scientist
Retrieving data	retrieve with calibrations	Gives you all observations with a type of ARC, FLAT, BIAS or DARK, and those whose project ID is missing, and those whose project id is “CAL” and those observations marked as a standard in the OT.
retrieve without calibrations	Gives you all observations with the your project ID.

This page is a Work in Progress but should reasonably represent the state of the software at the time of reading. If you find that this is not the case, please contact the author.