This loads a font easier to read for people with dyslexia.
This renders the document in high contrast mode.
This renders the document as white on black
This can help those with trouble processing rapid screen movements.
Decrease text size Increase text size Reset text size
Accessibility menu
Search icon
Menu

Usage System

The Usage ssytem is intended to help track usage of the Compact Array and Mopra. In particular, it is a tool to track lost time. There are three components to the system:
  1. A process which periodically inspects the data produced by the Compact Array and Mopra to try to discern what the telescopes was doing, and whether there were any antennas that were down, or ACCs that were rebooted.
  2. A tool that allows this data to be inspected and editted. It is a GUI-based system which presents the schedule, the RPFITS files generated, and details about each RPFITS file. This is the part of the system that requires regular attention.
  3. Tools (yet to be written!) which produce summaries and tables of the usage.

Above is a (low resolution) screen dump of the ``Usage'' GUI. To start the GUI from a UNIX system, use: 


    % /n/rsault/usage/usage.pl
to handle Compact Array usage, and 

    % /n/rsault/usage/usage.pl -m
to handle Mopra. The GUI consists of three main panels:
  • a Schedule Usage and Web Resources panel (leftmost),
  • the Actual Usage panel, giving a list of RPFITS files (centre), and
  • an Usage Details panel which shows the specific information about each RPFITS files and usage (rightmost).
Some buttons across the top of the GUI provide file management function.

The Actual Usage panel

The use of the telescope at any instance is tied to an RPFITS file. When the telescope is idle, the list shows a pseudo-file with IDLE as the project identifier. Each RPFITS file has a record detailing any lost time, whether the observer was local or remote, whether it was a NAPA/ToO or swap etc. Although the usage tools can usually determine when there is lost time, they can get it wrong and they do not (generally) know the cause of the lost time. Consequently each record has to be inspected to check whether they are complete/correct.

The View All/View New button switchs between the RPFITS file list showing all records or just the records that are new. When it starts up, CAUSE shows only the new records that have yet to be checked.

The arrow buttons allow you to navigate back of forth through the list currently being displayed. Alternatively you can just click on any of the RPFITS files.

The Usage Details panel

This gives details about the current RPFITS file being considered. At the top it gives the current file name, and a line looking something like 
  Scheduled: 10:09-Astro-10:20
This "Scheduled" line gives a simple schedule of what the telescope was supposed to be doing during the time covered by the RPFITS file. It is of the form

Scheduled: time - use - time [- use - time ...]

 where use can be Astro, Directors or Maint

There is a Project field. This will normally be guessed correctly. However occassionally it will need to be corrected.

Below there are some buttons and a table of Usage/Loss information. In recording the use, it is assumed that the normal state is that all systems are used for astronomy at all times. The table gives the exceptions to this. Obviously maintenance is a major other use of the system (note the system does not distinguish between maintenance, test time and reconfigurations).

Normally the process which checks system usage makes a good guess at what systems are down when. If this does not work well, the Mark as Lost can be used to put an entry in the Usage/Loss table showing the corresponding data are all bad.

The Mark as Good clears the Usage/Loss table so that the usage is assumed to be for astronomy.

The Defaults button resets the Usage/Loss table to the initial guess that the system makes. The Defaults button would be used if you mess up the usage table, and want to start again. The default entries in the Usage/Loss table are determined by what the schedule indicates the time was supposed to be used for, the project identifier used (whether this corresponds to maintenance/test or astronomy project), and of course the record of what was happening with the telescope.

The Autocheck button is used for maintenance periods where there will be a mix of idle time, C999 observations and other observations that are obviously "maintenance/test" in nature. The Autocheck marks the new records that fit the bill of routine maintainance as being maintenance.

Each entry in the usage table has a start and end time, a description (from a list of available descriptions), the fraction of the system that was used for that, and space for some notes.

The fraction will usually be 1. However the fraction can be 1/6 for one antenna down out of 6, or 2/6 for two antennas down, etc. The fraction can be given in the form a/b or as a decimal number (less than or equal to 1). Strictly speaking, the fraction is the fractional loss in sensitivity of the observation.

The notes can contain anything. When there is a fault report associated with a failure, the notes field should reference the fault report.

The descriptions are Maintenance/test, Idle, Misc Failure and specific systems which might be the cause of lost time.

  • Maintenance/test should be used for scheduled maintenance time where the system is not used for astronomical observations.
  • Idle should be used for maintenance and Directors times when the telescope is available for astronomy, but there is no one who wishes to use it.
  • Not lost time should be used when the system believes there was down time, but when this was really not the case. Good examples of this are when an antenna is intended to be unavailable during astronomy (e.g. when only three antennas have been outfitted with 3mm receivers or able to be used in the wideband correlator experiment). The usage system will initially flag these cases as the antenna being down. However the situation is not a system failure, and so should not be labelled as downtime.
Below the usage/loss table, one can specify where the observer was (local or a variety of classes of remote observers), and some check boxes for whether the observation was a NAPA/ToO, Swap or Weather Override (where a 3mm project is aborted and replaced by a centimetre project because of poor weather).

There is a place for general notes after this. Any special processing that needs to be performed on the data to make sense of it should be mentioned here

File Management Buttons

There are (currently) four file management buttons along the top-left of the GUI. These abort the GUI (without saving any changes), exits (and save as it exist), saves the outputs (without exiting), and imports any new records on usage.

Original: Bob Sault (9-Jun-2004)
Modified: Bob Sault (10-Jul-2004)