Dynamic Scheduling Glossary

Quick Links:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Glossary Issues

Overlap with other observatories' terminology, and our own in other places.

All places where our terminology and that of the PST overlap, as defined in the PST documentation http://e2e.nrao.edu/pst/PSTMANUAL/PSTMANUAL.html have now been given. We still need someone (Dana?) to go over the discrepancies with the E2E or PST group, whichever is appropriate, to ensure we are all on the same page with both our planning and our terminology.

Where possible, we should attempt to be compatible with terminology at other telescopes - especially NRAO ones. We should not allow them to usurp useful terms however.

There is a useful document somewhere in the NRAO wiki with definitions of "Project Model", "Observing Model", etc, at https://wiki.nrao.edu/bin/view/Software/CommonNRAOModel. The only overlap I see with the DSS definitions is that of "Project Model", which we have adopted.

Once the above ambiguities are worked out and we are confident of our usage, we need to go through the GB web pages to remove any discrepancies in usage of words.

Dynamic Scheduling Glossary

Activity

An event whose session must be scheduled (as a segment) but which does not use the PST and therefore has no project associated with it. Examples of this include maintenance activities and commissioning runs.

Co-Investigator (Co-I)

All authors on the proposal at the time it was submitted except for the Principal Investigator

Completed Project/Activity

A project or activity is complete if they have successfully observed the amount of time allocated to them by the GBT PSC, at their chosen LST, or the time for which the project or activity is valid has elapsed. Eventually, this could morph into the project or activity reaching the desired time or rms, but the second definition is currently out of scope.

Dynamic Scheduling System (DSS)

The suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate sessions and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

Fixed Session

A fixed session must be executed at a certain time and date and cannot be dynamically scheduled. Examples of fixed time sessions include VLBI and radar runs.

Investigator

One of the named authors associated with the project at the time it was submitted through the PST, or the person(s) responsible for a GBT activity. For the PST Observer is used to mean both observer and investigator, with no distinction between the two

Metadata

Metadata (Greek meta "over" and Latin data "information", literally "data about data"), are data that describe other data. Generally, a set of metadata describe a single set of data, called a resource. An interesting definition for our context is one cited in the Wikipedia : "Metadata is structured, encoded data that describe characteristics of information-bearing entities to aid in the identification, discovery, assessment, and management of the described entities."

Minimum Time (Session)

A session will have a minimum and maximum time associated with it. The minimum time will define the smallest amount of time the observer feels is useful for observing, and will be the smallest amount of time for which the DSS will allow a session to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and session, but due to the difficulty in scheduling the telescope it is conceivable that an session will be scheduled for only its minimum time. The default minimum time will be set to 2 hours.

Examples of minimum time include:

If a pulsar investigator needs to observe a pulsar for 8 consecutive hours to correctly obtain the pulsar(s) orbit parameters, the minimum time for a session segment will be 8 hours plus the time needed for overhead (e.g. 8.5 hours or so).
If a spectral line investigator wishes to make 100 repeated frequency switched observations of an object, where each frequency switched observation is only 10 minutes long, the investigator could make the project session's minimum time 10 minutes + overhead. In this case, though, even though the project's set-up time would likely only be 3-5 minutes, it probably would not make much sense for the investigator to ask for a 15 minutes minimum, as the investigator could (although hopefully would not) end up with numerous 15 minute slots on the telescope, thereby eating much of the project's total time in overhead. Instead a sensible minimum time might be 30 minutes or 1 hour.

Maximum Time (Session)

A session will have a minimum and maximum time associated with it. The maximum time for that session will define the longest period of time in the LST range for which a session segment will be scheduled (that is, it will define the longest session segment allowed). The purpose of this definition is to allow for observers to readily break their (non-fixed or windowed time) project into multiple segments. Unlike fixed time and fixed window projects, the maximum time parameter does not offer any information as to when the next session will be scheduled, except that it will not be scheduled until the LST range for the session begins again. The default maximum time will be set to the maximum time of the session

Examples of maximum time include:

An investigator wishes to make multiple (10) maps of an astronomical object, where the map is made in azimuth and elevation and takes 2 hours to run (including overhead). To add complication, though, they would like to randomize the azimuth and elevation range over which the maps are made. To accomplish this task, the investigator may wish to make no more than 1 map in a given 24 hour period. In this case, the segments would have a minimum time of 2 hours (to insure a full map was made) and a maximum time of 2 hours (to insure no more than 1 map is made). In practical terms, then, and assuming this is the only segment associated with this session, the TP for this session would be set to 2 hours each time it was observed.
Another pulsar-pulsar pair is found. The investigators wish to determine the full orbital parameters of the system. The investigators knows (from preliminary observations) that no orbital or spin period is greater than 4 hours, nor less than 2 hours, but they do not know at what precise time the orbital period starts. Also, though, the investigators wish to observe this system on different days to see if the pulse signal is varying with time. In this case the segments would be defined so that the minimum time is 2 hours and the maximum time is approximately 4 hours (with set-up time and some fudge factors included, the minimum time might be more like 2.5 hours and the maximum time might be more like 5 hours).

NRAO Priority

A priority ranking given to project sessions by the GBT staff which would override all other priorities in the SelectionRules listing (Criteria IV). This is intended to be used on in the extremely rare case where the telescope scheduler or another qualified individual decides that a given session(s) needs priority over all other sessions, overriding the normal priority listing. The smaller the number for the priority, the higher the session priority is ranked. Additionally, any session with a priority > 900 will not be considered for observing.

Observation

A generic term used to indicate that the telescope is being used to perform observing, without being more specific. Observation is used in a similar sense in the PST. E.g. here the investigator indicates whether an observer will be present at the telescope for the proposed observations.

Observer

The person carrying out observations, normally by adding OBs to the queue. This may be one of:

Project Observer - someone already associated with the project; i.e. P.I. or Co-I.
Designated Observer - someone who is observing on behalf of others (e.g. a visiting observer Who has volunteered to perform other observations should the weather not be good enough for theirs).
Staff Observer - a staff scientist who is performing observations on behalf of others for some reason.
Operator - cannot be used at this time, except in predefined circumstances (e.g. VLBI runs)
Staff Observers can only be used for observing by prior agreement with the staff member.

For the PST Observer is used to mean both observer and investigator, with no distinction between the two

Observing Block

Here, an Observing Block is just the script used to obtain the desired telescope data, and a limited amount of metadata.

The script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples
The metadata is quite sparse and consists of only the proposal ID, session number, observer’s name and operator’s name. * Observing Blocks will not be used by the DSS for determining what should or should not be run.

Observing Contact

This is a list of people to contact for observing. Initially the list will be the same as for the Proposal Contact, but can change once the project sessions are being prepared for observing. As this is a list of people to contact for observing in the GBT, people should not be on it who are not qualified for GBT observations. This should be a prioritized list of contacts for specific date ranges - if contact A cant be reached at number X on this date, try contact B at number Y.

Observing Script

The observing script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples

Operator

The on duty GBT telescope operator. In the PST this word is used in the same way.

Principal Investigator (PI)

The first author on the proposal at the time it was submitted.

Project

The scientific proposal, with its metadata, which is submitted through the PST and which then may eventually get scheduled on the telescope. There is no distinction made between projects which receive high rankings from the referees/PSC and those which are given rankings too low to be observed with the GBT, as that is simply a "scientific ranking" criteria for the DSS. The Common NRAO Models page describes a project model in the following way:

The Project model defines an information model for an observing project. The Project model includes everything needed to describe an observing project and to process and track the project through the system, from proposal submission through to data products in the archive and subsequent publications. The Project model is required to drive the automated observing process and all post-processing. The Project model includes definitions of all concepts and terminology required to statically describe the state of an observing project, e.g., proposal, program, program block, target list, resource requirements, and so forth.

The PST uses project in a similar manner, but also uses the term "proposal". The distinction between the two is unclear.

Project Friend

The GBT staff member who is assigned to help the investigators in preparing their project for observations with the GBT. This person is typically a GBT support scientist, but is not necessarily the on-duty support scientist at the time the project is observed. In the PST, this classification is used to determine the amount of help needed by a project - if you need a "friend" then "You do not have much observing experience and will need extensive help from the NRAO staff."

Project Web Page

A web page, or group of web pages, which provides, or provides links to, all pertinent information for a given project and its sessions. A prototype page can be seen at ProjectsPage

Proposal

The scientific proposal which is submitted through the PST. Once submitted, the term "project" applies The PST uses proposal in a similar manner, but also uses the term "project". The distinction between the two is unclear.

Proposal Contact

Contact person just for issues related to a telescope proposal, and comes from the PST.

Proposal Scheduling Committee (PSC)

The final reviewing committee for GBT projects. The PSC generally accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referee’s rankings to select the top ranked projects until the total available telescope time is used. The PSC does certainly make scientific judgments, but prefers not to over-rule the referees’ rankings without good reason.

Proposal Submission Tool (PST)

The mechanism to submit proposals for observing time at any of the NRAO telescopes. See https://e2e.nrao.edu/userdb/

Scan

A series of subscans which is a logical unit of observation; e.g. a Peak or an OnOff. Scan is the lowest level object normally used by an observer (however expert users may collaborate with GB staff to define new observing modes, which may require specification at the subscan level or below).

Scheduler

The person who currently schedules the GBT and whom still has ultimate responsibility for the GBT telescope schedule. Currently, the scheduler is Carl Bignell.

Science Grade

The grade given to a project by the GBT PSC. Our working definition of science grades is given at SelectionRules#ScienceGrades

Segment

A segment is the part of a session observed within a Telescope Period. As an example, suppose a session has a minimum time of 1 hour, a maximum time of 6 hours, and a total time of 6 hours. Then, suppose the DSS schedules that session for only 3 hours. This, then, is a 3 hour segment of the session.

Semester

Currently, a four month block of observing time for which projects are called for, refereed and awarded a science grade, and allocated time. Semester boundaries are:

nnA (e.g. 05A). Deadline is announced ~1st September. Deadline 1st October. Scheduling Meeting ~1st December, Preliminary schedule constructed ~1st January; Semester boundaries 1st February - 31st May.
nnB (e.g. 05B). Deadline is announced ~1st January. Deadline 1st February. Scheduling Meeting ~1st April, Preliminary schedule constructed ~1st May. Semester boundaries 1st June - 30th September.
nnC (e.g. 05C). Deadline is announced ~1st May. Deadline is 1st June. Scheduling Meeting ~ 1st August, preliminary schedule constructed ~ 1st September; Semester boundaries 1st October - 31st January.

This could change in the future without affecting the dynamic scheduling process.

Session

All projects are broken into multiple sessions, where each session is uniquely defined by a given set of criteria (e.g. LST/UT, weather, hardware). All observations which an investigator wishes to pursue for the project must be contained within one or more sessions, and it is these individual sessions which the DSS will schedule.

As an example, suppose a project has just two sources, separated by 5 hours of LST but which otherwise use the same hardware, weather conditions, etc. In this case, the project would naturally be broken into two sessions - one for each source.

As a difference example, assume that the project has only one source, but the investigator wishes to observe the source with two different front ends. Again this project would be naturally broken into two sessions, one for each front end.

For a final example, assume a project has sources across the sky in LST, but the weather and hardware requirements for each source is the same. Here, the investigator may wish to break the project into as many as 24 sessions, one for each hour of LST.

Session is defined by the PST in a manner that is a cross between the DSS definition of session and that of session:

"Generally a session represents a contiguous block of observing time. A session describes the amount of time requested for that block, and how it should be divided amongst various sources and resources. Many observing runs involve a single observing session per day. A project may request multiple observing sessions, either as repeats of the same session (for example, in monitoring observations), or as truly independent sessions (for example, in multi-configuration VLA observations).

Within the PST, each session is specified as one source/resource pair for the GBT, and as one or more source/resource pairs for the VLA. Within a pair, the source may be a single source, or a group of sources which are all to be observed in the same way. The resource specifies the telescope setup to be used in observing the source (or source group): the front end receiver, the back end, and the technical details of how they are to be used together. For the GBT, either resources or groups of resources can be specified. For the VLA, resources can be specified but they cannot be grouped.

Each session has additional information, including a session name, a minimum start LST, a maximum end LST, a minimum elevation, a total session time, a repeat count plus separation interval, text describing scheduling constraints, and text giving comments. For the VLA, each source/resource pair has an associated observing time and rms noise level, and the total time for the session is normally the sum of the observing times requested for the constituent source/resource pairs. For the GBT, the total observing time for the session is manually entered."

Later on, the PST manual clarifies: "For the GBT a session can be thought of as the longest period of contiguous time that the proposed observations can be scheduled. There are several scientific and technical reasons why one should separate the proposed observations into different or repeating sessions. Some of these reasons include:

The time needed on source is greater than the time the source is above the horizon.
The sources in a project are grouped in widely separated declinations.
The sources in a project are grouped in widely separated right ascensions.
A prime focus receiver change is required for all of the observations to be completed. The prime focus receiver changes require the receiver to be physically changed on a maintenance day. Changing the Gregorian receivers just requires a rotation of the Gregorian feed mount (which is performed by the telescope operator).
The projects are for monitoring observations."

Session MetaData

The metadata associated with a given session. A list of session metadata can be found at SchedulingData.

Session Priority

This is the internal ranking which can be given to an session by the investigators. It would be used by the DSS to distinguish between sessions for a given project. The higher the number for the priority, the higher the session priority is ranked. Additionally, any session with a priority =0 will not be considered for observing.

Session Scheduling Criteria

The subset of the Metadata for an session which is needed by the DSS to qualify it and rank it against other qualified sessions.

Subscan

The minimal amount of data taking; alternatively, a continuous period of telescope motion under a single configuration. Given that a subscan is the minimal amount of data taking, then setting configurations, positions, or defining receiver bands are not be considered subscans. Configurations involve, at the most fundamental level, setting a collection of parameters and do not involve data taking.

Successful observations

An observation is deemed successful if the observer is able to carry out his/her Observing Block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session segment but otherwise the session is run successfully, that segments still considered successful and the time is logged against the project/activity and session.

Support Shift

Twelve hour period of time covered by a single support scientist. Day shift is 6am to 6pm; night shift is 6pm to 6am. (Note - We may eventually want to change this to match the operators' shifts.)

Telescope Period (TP)

A period of time which is the maximum time during which projects may not be changed by the DSS. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:

The minimum segment time for the project or activity session is more than four hours
A fixed time project or activity is coming up causing the time to be shortened or lengthened (e.g. if the fixed time project or activity is coming up in three hours, the TP will be only 3 hours. If the fixed time project or activity is coming up in 4.5 hours, the TP will be 4.5 hours).
A transition period (thermal transition or work hours) is coming up making it inefficient for the TP to run for 4 hours
The project or activity has less than 4 hours (or just more than 4 hours) of allotted time left in that given LST and weather range
The project or activity has less than (or just more than) 4 hours of allotted time left in the semester
The weather turns or equipment fails rendering continuing of the TP useless

A telescope period may contain more than one segment from more than one session within a given project.

Time Between (Session)

A session will have both a minimum and maximum time associated with it, and a time between parameter which will set the length of time which must pass before the session can be rescheduled on the telescope. The time between is measured from the start of the session's time within a Telescope Period, and will be considered in force from when the session's time ends within that TP. This would be useful in the case where, e.g. someone might wish to have at least a week between making maps on an object in order to properly process the maps, so that decisions can be made before the next observations regarding the map's parameters. The time between parameter for a fixed window session runs from the beginning of the fixed window to the beginning of the next fixed window.

The default time between will be zero. This means that even if a session has a maximum time associated with it, if the time between is left at 0, the next TP with an session could begin as soon as the last TP of that session ends. E.g. if an session has 16 total hours remaining to it, and has a minimum time of 4 hours, a maximum time of 8 hours, but a time between of 0 hours, its feasible that the project run for 8 hours and then immediately start a new TP of 4 (or even 8) hours without any break.

As a second example, again assume an session has 16 total hours remaining to it, and has a minimum time of 4 hours, a maximum time of 8 hours, but a time between of 24 hours. In this case lets assume the project runs for 4 hours within a TP, but cannot be run for 8 consecutive hours. In this case, even though the maximum time is 8 hours, after completing its 4 hours TP the project will not be run until 24 hours have passed.

Weather Category

The groupings, or classifications, of weather criteria for the project sessions. This is useful both by the proposal selection committee in determining which projects can be run within a given semester and also with predicting which sessions can be run on the telescope. The categorization is used only as an aid to predicting the next sessions and will not result in a change in the requested weather criteria of a project

Weather Stow

Requirement to immediately stow the antenna, usually due to high winds or accumulating snow. This will result in the need to abort or pause a Observing Block being executed, or to delay submitting a new Observing Block to the telescope.

Windowed Session

A Windowed session must occur between certain times/dates. Examples of fixed window sessions include monitoring projects and maintenance activities:

Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a fixed window is assigned for 1-7 Jan 2007. They can observe on any of these days between the hours of 8-12 when their source is visible. If they are not scheduled on days 1-6 then the fixed window converts to a fixed time for 7 Jan.

Maintenance Day: an 8 hour maintenance day, 8 AM to 4 PM, must occur between Monday and Wed. for a given week. If this activity has not been scheduled by Tuesday, then it becomes a Fixed Time for Wed.

PF Receiver Change: this activity must take place between 8 AM and 6 PM on a given day, and will take at least 2 hours to successfully complete. If this activity has not started by at least 4 PM, it becomes a Fixed Time for 4 - 6 PM.

Topic DynamicSchedulingGlossary . { Edit | Attach | Ref-By | Printable | Diffs | r1.39 | > | r1.38 | > | r1.37 | More }

Revision r1.39 - 30 May 2007 - 09:27 GMT - KarenONeil Parents: WebHome	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Dynamic > DynamicSchedulingGlossary

Changes \| Index \| Search \| Go