>
> |
%META:TOPICINFO{author="MarkClark" date="1150290120" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="ModificationRequest4C805"}%
Astrid provides a Validate button in the Edit tab which tags the observing
script in the editing window to be "valid" or "invalid," and if invalid attempts to return
an error message to the user describing the problem. Currently -- but soon to
change (see MR 4C805) -- only valid scheduling
blocks may be saved to the database.
The validaton process is dependent on the current state of the telescope therefore introducing
time as an uncontrolled variable into the validation process: what is valid next
week may be invalid today. The most common problem is attempting to validate an
observing script for a receiver that is not currently mounted on the telescope.
This is one indication of a larger issue.
The issue whether the correct prime focus receiver is mounted on the telescope is
only the most irksome of the variables which effect the validation process.
Other variables which change over time are:
- cabling file - The validation process attempts to confirm that the observer's specific configuration including the IF paths. Anytime the cabling file is modified it will affect an observing script's validity. The cabling file may be modified because of device changes, but also more rarely to circumvent bad devices or for unique experiments.
- dev_health.conf - When devices are declared as working or not working, it will affect whether a specific observing script at a given time is valid or not.
- time - Time itself can affect the validity of a scheduling block two ways. First, whether the objects being observed are available, i.e., above the horizon, and second, when the observing script contains LST or absolute times. Currently the validation process ignores this issue, but it will become an issue (see MR 14C306).
In the above description, no definitions of valid is offered. Unfortunately, the current definition is
an operational one. Basically, the way Astrid validates an observing script is by running the script.
This can become painfully obvious if one puts an infinite loop in an observing script: the validation step
never returns, and one has to kill the user's Astrid program.
Since observing scripts are supersets of the Python, i.e., Python scripts with additional "built-in" functions
and objects, running the script checks for syntax errors and whatever semantical errors that are in Python
and which are not stubbed out in the add-ons during the validation "run." For example,
configuration finds the needed IF paths, but does
not set parameter values in the telescope managers; scan type's and observing directive's constructors are executed which
can catch illegal
arguments, but the actions themselves of the commands are not executed.
These operations were not chosen from a definition of- or need for- validation,
but were "doable" with minimum effort.
Undefind or not, validation is useful.
- provide users error feedback offline prior to observing
- allow selection from job queue with some degree of confidence the script will run
- minimize delays in the run queue
To facilitate discussion, the following definitions for valid are proposed.
- legit - The script is good given that the telescope if fully populated with all possible devices (cabling file is a superset of all cabling files) and all devices are working (device health file is empty).
- valid - The script is good given the current state of the telescope as defined by the current cabling file and device health file. (current definition, ignoring the level of emulation during the validation execution)
- runnable - The script is good except for unforeseen run-time software and hardware problems for a given time.
In other words, legit = syntactically correct for an ideal telescope; valid = legit + current telescope state; and runnable = valid + current time.
Given there are currently over 5000 scheduling blocks in the database, some criteria are needed for when scripts
are checked for validity regardless of the definition used. Currently, validation takes place on demand or when a script
is submitted to the database.
Candidates are:
- on demand (user-selected definition)
- submitted to the database (legit definition)
- entry into the job queue (valid definition)
- use legit definition off-line and valid definition on-line
- all scripts in the job queue whenever the cabling file or device health file change (valid definition)
- all scripts in the job queue periodically (needed for runnable definition)
-- MarkClark - 14 Jun 2006 |