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.
|
|
|
|
|
|
|
