Go to the bottom.
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! SDDL Name: zspss_user_types.sddl
!
! Purpose: This file consists of the standard spss object types.
!
! Modification History:
!
! Date OPR Who Reason
! -------- ------- --- -------------------------------------------------
! 11/94 27329 Team Updates for relation conversion project.
! 12/94 27329 Team More updates for relation conversion project.
! 01/95 27329 Team More updates for relation conversion project.
! 11/95 30445 NLC Duplicate type SI_STATE_TYPE; rename to
! SI_CONFIG_STATE_TYPE
! 1/96 30681 EGB Add LRP_NAME_TYPE
! 03/13/96 31033 MRB Add PASS_SMS_ID_TYPE
! 04/02/96 29724 NLC Add LOCK_FIELD_TYPE
! 03/13/96 30954 MRB Add OPUS_ASSOCIATION_ID_TYPE,OPUS_PRODUCT__ID_TYPE
! 06/24/96 31689 SFS Modify definition of OPUS_ASSOCIATION_ID_TYPE
! 10/30/96 32496 SFS Resolved CMS variant for this file
! 12/6/97 32404 EGB Clarify cclist version.
! 11/03/98 37306 bao Delete remnants of GSSS interface from SPSS
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! Langauge Specifications
LANGUAGE FORTRAN, C
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! PMDB Proposal Hierarchy Types
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
USER_TYPE PROPOSAL_ID_TYPE
DESCRIPTION "A proposal consists of many individual observations
submitted as a package by a proposer. When a proposal is
processed by the proposal entry system (PEPSI, RPS2),
it is assigned a proposal identifier. That identifier is
an integer that is converted into a 5 character base 36
string. This field, typically called 'proposal_id', will
often contribute to the index on a relation.
In the PMDB a proposal will minimally consist of
proposal-specific data plus observation set, alignment,
exposure, and target data, as defined below."
TYPE C5
UNITS "BASE_36"
END_USER_TYPE
USER_TYPE INT_PROPOSAL_ID_TYPE
DESCRIPTION "This is the PEPSI/RPS2 proposal identifier field. It is
simlar to the PMDB proposal_id field except that it is an
integer instead of a base-36 string. PEPSI only assigns
base-10 proposal ids to the propsals so that this field will
be identical (except for the leading 0)."
TYPE I*2
END_USER_TYPE
USER_TYPE PROGRAM_ID_TYPE
DESCRIPTION "When a proposal is accepted into the PMDB by SPSS it must
be assigned a unique 3 character base 36 program identifier.
This is done by the PMDB/ACCEPT_PROP command. This program
identifier is tagged as 'program_id' in most PMDB relations.
Is is used for identification of proposals by spacecraft
and PODPS software. It is also used in the PODPS and DADS
rootname for all archived science data files.
Because of flight design software, program_id must be
three characters."
TYPE C3
UNITS "BASE_36"
END_USER_TYPE
USER_TYPE OBSET_ID_TYPE
DESCRIPTION "An observation set is a collection of one or more
alignments that are grouped together based on FGS pointing
requirements. That is, if multiple alignments can all be
executed using the same guide star pair, they are grouped
into the same observation set.
An observation set is identified by a 2 character base 36
string. This field, typically called 'obset_id', will
often contribute to the index on relation together with a
proposal_id, version_num, and possibly other fields.
In the PMDB an observation set will minimally consist of
observation set-specific data plus alignment, exposure,
and target data.
OBSET is an acronym for observation set."
TYPE C2
UNITS "BASE_36"
END_USER_TYPE
USER_TYPE OBSET_SPEC_TYPE
DESCRIPTION "This is the full specification of an observation set (See
OBSET_ID_TYPE). The specification is:
ppppp:oo:vv
where ppppp = proposal id
oo = obset id
vv = version num"
TYPE C11
END_USER_TYPE
USER_TYPE ALIGN_ID_TYPE
DESCRIPTION "An alignment is a collection of exposures that are grouped
together based upon changes in the target/aperture
combinations and the length of a visibility period. That
is, a separate alignment is generated if the target or
aperture changes between eposures or the sum of the
exposure times is greater than a visibility period.
An alignment is identified by a 2 character base 36 string.
This field, typically called 'alignment_id', will often
contribute to the index on a relation together with a
proposal_id, obset_id, version_num and possibly other
fields.
In the PMDB an alignment will minimally consist of
alignment-specific data plus exposure, and target data,
detailed below."
TYPE C2
UNITS "BASE_36"
END_USER_TYPE
USER_TYPE ALIGN_SPEC_TYPE
DESCRIPTION "This is the full specification of an alignment (See
ALIGN_ID_TYPE). The specification is:
ppppp:oo:aa:vv
where ppppp = proposal id
oo = obset id
aa = alignment id
vv = version num"
TYPE C14
END_USER_TYPE
USER_TYPE EXPOSURE_ID_TYPE
DESCRIPTION "An exposure is a separate instrument operation using a
instrument/target combination. Together with target data,
this is the smallest entity in the PMDB to comprise a
proposal.
An exposure is identified by a 2 character base 36 string.
This field, typically called 'exposure_id', will often
contribute to the index on a relation together with a
proposal_id, obset_id, alignment_id, version_num and
possibly other fields."
TYPE C2
UNITS "BASE_36"
RANGE "00..ZZ"
END_USER_TYPE
USER_TYPE EXPOSURE_SPEC_TYPE
DESCRIPTION "This is the full specification of a scheduling unit (See
EXPOSURE_ID_TYPE). The specification is:
ppppp:oo:aa:ee:vv
where ppppp = proposal id
oo = obset id
aa = alignment id
ee = exposure id
vv = version num"
TYPE C17
END_USER_TYPE
USER_TYPE VERSION_NUM_TYPE
DESCRIPTION "All observation sets, and their associated alignments and
exposures have a version number. The scheduling unit
containing an observation set inherits the version number
of the observation set. When the scheduling unit contains
more than one observation set the version numbers must all
be the same.
A version number is identified by a 2 character base 36
string. This field, typically called 'version_num', will
often contribute to the index on relation together with a
proposal_id, obset_id, and possibly alignment_id,
exposure_id, and other fields.
Version numbers are always set to '01' operationally. They
currently are only utilized in testing."
TYPE C2
UNITS "BASE_36"
RANGE "00..ZZ"
END_USER_TYPE
USER_TYPE VISIT_ID_TYPE
DESCRIPTION "A visit is a synonym for a scheduling unit, and is more of
a front-end system/proposal instruction term. The visit
identifier is a 2 character string, while the scheduling
unit identifier which is a 7 character string. The visit
idenitifier will always be the last two characters of the
SU identifier.
Following is the definition of visit in the Proposal
Instructions.
A visit is an exposure or a series of consecutive
exposures, with overheads, on a given target, and may
consist of the following parts:
1. guide-star acquisition (to point HST at the target)
2. target acquisition (to place the target in an
instrument aperture)
3. science exposure(s) (to obtain the data)
4. instrument overheads (to set up the instrument and read
out the data)
5. instrument calibrations/overheads (if more than standard
calibration is required)
If the visit lasts more than one orbit, it will continue
with the following for each subsequent orbit:
6. guide-star re-acquisition (to keep HST pointed and locked
after earth occultation)
7. science exposure(s)
8. instrument overheads
9. instrument calibrations/overheads
A new visit is required whenever a new set of guide stars
must be acquired."
TYPE C2
END_USER_TYPE
USER_TYPE SUNIT_ID_TYPE
DESCRIPTION "A scheduling unit consists of one or more observation sets
and is the fundemental object which is placed on SPSS
calendars. A synonym for a scheduling unit in SPSS is
a 'candidate.'
A scheduling unit is identified by a seven character
base 36 string. For operational proposals the first five
characters are the proposal id (with a leading zero).
This field, typically called 'sunit_id', will
often contribute to the index on relation together with a
proposal_id, obset_id, version_num, and possibly other
fields.
In the PMDB a scheduling unit will minimally consist of
scheduling unit-specific data plus observation set,
alignment, exposure, and target data.
SU is a common acronym for a scheduling unit."
TYPE C7
END_USER_TYPE
USER_TYPE SUNIT_SPEC_TYPE
DESCRIPTION "This is the full specification of a scheduling unit (See
SUNIT_ID_TYPE). The specification is:
sssssss:vv
where sssssss = sunit id
vv = version num"
TYPE C10
END_USER_TYPE
USER_TYPE TARGET_ID_TYPE
DESCRIPTION "The target identifier defines the astronomical object
to be observed.
The target name can be up to 15 characters and is derived
from the proposal id with a unique number for the object
within the proposal, i.e. for proposal 04931 the 5th
target would be 4931_5. Within the database relations,
the target field is typically called 'target_id'. It will
often contribute to the index on relation together with a
proposal_id, and possibly other fields."
TYPE C15
END_USER_TYPE
USER_TYPE LINK_SET_ID_TYPE
DESCRIPTION "A linked set is a collection of two or more scheduling
units with a defined timing relationship between the
scheduling units.
A link set is named, and can be up to 16 characters.
Within the database relations that store link set
information, the field is typically called 'link_set_id',
and it will often contribute to the index on relation."
TYPE C16
END_USER_TYPE
USER_TYPE AF_REVISION_NUMBER_TYPE
DESCRIPTION "A number incremented each time the assignment
file (AF) is regenerated. It is used to keep
track which version was last generated."
TYPE I2
END_USER_TYPE
!!!!!!!!!!!!!!
!
! Guide Star Types
!
!!!!!!!!!!!!!!
USER_TYPE GS_ID_TYPE
DESCRIPTION "The first five characters of the guide star id represent
a region id, and the second five, an id of a star within
that region. The sky was divided into approximately
9500 regions for the creation of the guide star
catalog; it is these region numbers that are used
for the region id."
TYPE C10
END_USER_TYPE
USER_TYPE GS_PAIR_ID_TYPE
DESCRIPTION "The guide star pair id consists of the guide star
ids of the dominant and subdominant stars, and the
FGS numbers. The dominant star is listed first,
and is the star that controls the pointing of the
telescope. The subdominant star controls the roll.
The field is formatted as follows:
characters
----------
1-10 : the guide star id of the dominant star
(GS_ID_TYPE)
11 : 'F', which stands for FGS
12 : the integer identifier of the FGS (1, 2, or 3)
13-22 : the guide star id of the subdominant star
(GS_ID_TYPE);
or a string of '0's for a 'pair' with only one
star, resulting from a single FGS guide star
request
23 : 'F', which stands for FGS
24 : the integer identifier of the FGS (1, 2, or 3);
or 0, resulting from a single FGS guide star
request"
TYPE C24
END_USER_TYPE
!!!!!!!!!!!!!!!!!!!!
!
! C&C List/SMS Types
!
!!!!!!!!!!!!!!!!!!!!
USER_TYPE CCLIST_ID_TYPE
DESCRIPTION "The C&C list is a major data structure within SPSS that
contains information on 'candidates' and the 'calendar'.
The candidate data, often referred to as the candidate
pool, are scheduling units and their associated
observation set, alignment, and target data.
The calendar is a timeline of activities that are laid
down by the SPSS scheduling utilities. Example
activities include slews, PCS aquisitions, small angle
maneuvers, science, TDRS contacts, tape recordings,
science instrument reconfigurations, and others.
When a C&C List is saved in SPSS (via the CCLIST/SAVE
comand) it receives an identifier. The identifier can
be up to 9 characters long. Within operations, the C&C
list naming convention is: yydddnxx
where yy = last two digits of the year
ddd = day of year of start of calendar
n = length of calendar in days (usually 7)
xx = unique identifier within above info.
Within the database relations, this field is typically
called 'cclist_id', and will often contribute to the index
on the relation together other fields."
TYPE C9
END_USER_TYPE
USER_TYPE CCLIST_VERSION_NUM_TYPE
DESCRIPTION "C&C list files have a version number associated with
them. The version number is incremented by one as
each version of a C&C List is saved (via CCLIST/SAVE).
Operationally, version numbers for C&C Lists are not used,
meaning they never in practice create C&C Lists with a
version number higher than one."
TYPE I2
END_USER_TYPE
USER_TYPE ORBIT_FILE_ID_TYPE
DESCRIPTION "The orbit file is a major data structure within SPSS that
contains ephemeris information for the HST and two Tracking
and Data Relay Spacecraft (designated as TDRS East and West)
for a specific time period. It also contains ascending node
crossing times, Earth shadow crossing times, and multiple
SAA contour crossing times.
Raw ephemeris data files are provided by PASS for the HST and
TDRS spacecraft. The WEREADX program catalogs and converts
the data to a format used by the PEFFIT program. PEFFIT
generates a set of Least Squares Fit coefficients from this
data and stores them in the PMDB. The ORBFILE/CREATE program
generates an Orbit File from these coefficients.
The Orbit File is used by many SPSS programs for scheduling
related calculations involving the positions of HST and the
TDRS spacecraft"
TYPE C9
END_USER_TYPE
USER_TYPE ORBIT_FILE_VERSION_NUM_TYPE
DESCRIPTION "Orbit Files have a version number associated with
them. The version number is incremented by one as
each version of an orbit file is created (via
ORBFILE/CREATE). Operationally, version numbers for
orbit files are always 01."
TYPE I2
END_USER_TYPE
USER_TYPE EPHEMERIS_FILE_TYPE
DESCRIPTION "Filename of ephemeris file produced by the WEREADX
program. The filename can take one of the following
forms:
File Type Filename
------------------------------------------
ST7WP SPSSPEF:ST7WP_YYDDD.DAT
ST9MP SPSSPEF:ST9MP_YYDDD.DAT
STDEF SPSSPEF:STDEF_YYDDD.DAT
TDRSaaa SPSSPEF:TDRSaaa_YYDDD.DAT
Where YY = Start of file Year
DDD = Start of file Day number
aaa = West Longitude of TDRS (degrees)
SPSSPEF is a VMS logical."
TYPE C*128
END_USER_TYPE
USER_TYPE EPHEMERIS_FILE_VER_TYPE
DESCRIPTION "This is the version number of the ephemeris file.
Generally, this will be '1'."
TYPE I*2
END_USER_TYPE
!!!!!!!!!!!!!!!!!
!
! SI Types
!
!!!!!!!!!!!!!!!!!
USER_TYPE SI_ID_TYPE
DESCRIPTION "This is the identifier type for a Science Instrument (SI).
The current SI list includes the:
FOC - Faint Object Camera
FOS - Faint Object Spectrograph
WFII - Wide Field Planetary Camera 2
HRS - High Resloution Spectrograph
CSTR - COSTAR
FGS - Fine Guidance Sensor
NIC - NICMOS
STIS - Space Telescope Infrared Spectrograph"
TYPE C4
DISCRETE "FOC", "HRS", "WFII", "FGS", "NIC", "STIS", "CSTR"
END_USER_TYPE
USER_TYPE SI_DETECTOR_TYPE
DESCRIPTION "Each science instrument may have its own unique
set of detectors. A detector is ."
TYPE C4
END_USER_TYPE
USER_TYPE SI_CONFIG_STATE_TYPE
DESCRIPTION "The state of an SI denotes what configuration a particular
science instrument is in blah blah blah ..."
TYPE C8
END_USER_TYPE
!!!!!!!!!!!!!!!!!
!
! Time Types
!
!!!!!!!!!!!!!!!!!
USER_TYPE FULL_SOGS_CHAR_TIME_TYPE
DESCRIPTION "This is the standard SOGS output time in full precision
in the following format - yyyy.ddd:hh:mm:ss.sss
where yyyy = year
ddd = day of year
hh = hours
mm = minutes
ss.sss = seconds"
TYPE C21
UNITS "UTC"
RANGE "1980.001:00:00:00.000..2015.001:00:00:00.000"
END_USER_TYPE
USER_TYPE SOGS_CHAR_TIME_TYPE
DESCRIPTION "This is the standard SOGS output time
in the following format - yyyy.ddd:hh:mm:ss
where yyyy = year
ddd = day of year
hh = hours
mm = minutes
ss = seconds"
TYPE C17
UNITS "UTC"
RANGE "1980.001:00:00:00..2015.001:00:00:00"
END_USER_TYPE
USER_TYPE SOGS_INT_TIME_TYPE
DESCRIPTION "This is the compact representation of the SOGS character
time. It is the integer number of seconds past January 1,
1980.
There are software mechanisms and SYBASE formatting
mechanisms for performing the conversion from integer to
the more readable, friendly string representation
(yyyy.ddd:hh:mm:ss or yyyy.ddd:hh:mm:ss.mmm)."
TYPE I4
UNITS "UTC"
END_USER_TYPE
USER_TYPE FULL_TIME_STAMP_TYPE
DESCRIPTION "This is the standard SOGS output time field that is used
to 'time stamp' a record. Time stamping a record means
putting in the current system time into the field and that
will designate the last time the record or some process
was updated or run. See description for the
FULL_SOGS_CHAR_TIME_TYPE for format details. The data
type of this field will be changed in the future to a
SYBASE date time datatype."
TYPE C21
UNITS "UTC"
END_USER_TYPE
USER_TYPE TIME_STAMP_TYPE
DESCRIPTION "This is the standard SOGS output time field that is used
to 'time stamp' a record. Time stamping a record means
putting in the current system time into the field and that
will designate the last time the record or some process
was updated or run. See description for the
SOGS_CHAR_TIME_TYPE for format details. The data
type of this field will be changed in the future to a
SYBASE date time datatype."
TYPE C17
UNITS "UTC"
END_USER_TYPE
USER_TYPE BRIEF_TIME_STAMP_TYPE
DESCRIPTION "This is the shortened standard SOGS output time field that
is used to 'time stamp' a record. Time stamping a record
means putting in the current system time into the field
and that will designate the last time the record or some
process was updated or run. The format of the field is
yyyy.ddd
where yyyy = year
ddd = day of year"
TYPE C8
UNITS "UTC"
RANGE "1980.001..2015.001"
END_USER_TYPE
USER_TYPE INT_TIME_STAMP_TYPE
DESCRIPTION "This is an integer representation of a standard SOGS
time field that is used to 'time stamp' a record. Time
stamping a record means putting in the current system
time into the field and that will designate the last time
the record or some process was updated or run. See
description for the SOGS_INT_TIME_TYPE for format details.
The data type of this field will be changed in the future
to a SYBASE date time datatype."
TYPE I4
UNITS "UTC"
END_USER_TYPE
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! SMS Generation/Instruction Expansion Types
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
USER_TYPE TABLE_NAME_TYPE
DESCRIPTION "This field holds the name of a table, and is seen in many
of the qg* relations. A table is one of the instruction
types ('TBL'). A table statement provides a convenient
mechanism for loading table data into the memory of the
NSSC-1, DF-224, Co-Processor, and/or SI microcomputers
through the SMS.
The table format, and optionally, a set of pre-defined
parameter values are defined by PDB (and the data gets
generated by IMTOOL). The table name is the name of this
PDB table."
TYPE C8
END_USER_TYPE
USER_TYPE INSTRUCTION_NAME_TYPE
DESCRIPTION "This is the instruction name or mnemonic. Instruction
names are user determined (IM) or pre-defined from the
ST PDB tape. Often they are named according to
functionality. An instruction name must be unique
within the relation."
TYPE C12
END_USER_TYPE
USER_TYPE PREC_CHECK_VALID_TYPE
DESCRIPTION "This flag indicates the validity of a precedence
checker table's records where:
V : all records in this relation are valid;
I : some records in this relation are invalid."
TYPE C1
DISCRETE "I", "V"
END_USER_TYPE
USER_TYPE SMS_ID_TYPE
DESCRIPTION "This is the filename of the Science Mission Specification
(SMS) file. The name and version create a unique key for
referring to an SMS. Other SMS related files with the same
SMS_ID and version are identified by filetype. This id is
the same as the CCLIST_ID."
TYPE C9
END_USER_TYPE
USER_TYPE SMS_VERSION_NUM_TYPE
DESCRIPTION "SMS files have a version number associated with
them. The version number is incremented by one as
each version of an SMS is generated (via SMSG/Generate).
Operationally, version numbers for SMSes are not used."
TYPE I2
END_USER_TYPE
USER_TYPE PASS_SMS_ID_TYPE
DESCRIPTION "This is the name of the PASS SMS as generated by
SMSG/Send. The naming convention is:
Sadddnpr
where:
S = source (S for SSC/STSCI)
a = alternate code (A-Z), default = 'A'
ddd = day-of-year of SMS start time (from START parameter)
n = year sent (base 36: 0-9,A-Z), modulus 1980
p = patch number (base 36), default = 0,
for a given alternate code, day-of-year, and
same day code, incremented for each patch of
an SMS
r = revision number (base 36), default = 0, for
a given alternate code, day-of-year, and
same day code, incremented for each revision
of an initial or alternate SMS."
TYPE C8
END_USER_TYPE
!!!!!!!!!!!!!!
!
! Other Types
!
!!!!!!!!!!!!!!
USER_TYPE YES_NO_FLAG_TYPE
DESCRIPTION "This field is a Yes/No flag database field. Read the
field description to determine what 'Y' (or 'y') means,
'N' (or 'n') means, and what a blank field maps to
if anything."
TYPE C1
DISCRETE "Y", "y", "N", "n"
END_USER_TYPE
USER_TYPE PAR_ALLOWED_TYPE
DESCRIPTION "At the scheduling unit, observation set, and alignment
levels are flags of this type that control how a primary
SU, OBSET, or alignment can handle a parallel SU's
activites.
This is a 4-way flag.
'Y' means parallel SUs can be scheduled on top
of the SU, OBSET, or alignment.
'A' means only attached, targeted parallel SUs can be
scheduled on top of the SU, OBSET, or alignment.
'I' means only non-targeted SUs can be scheduled on top
of the SU, OBSET, or alignment.
'N' means no parallel SUs can be scheduled on top of
the SU, OBSET, or alignment. "
TYPE C1
DISCRETE "Y", "A", "I", "N"
END_USER_TYPE
USER_TYPE PDB_ID_TYPE
DESCRIPTION "This field contains the name of a Project Database (PDB).
The PDB name is controlled by SCIOPSDB. It gets changed
with each new installation of the PDB. Many tables
contain this identifier and could support multiple
datasets that are indexed by this PDB identifier."
TYPE C8
END_USER_TYPE
USER_TYPE COMMENT_PAGE_TYPE
DESCRIPTION "This field is a page number for a PMDB comments
relation and enables multiple pages of comment
text to be entered."
TYPE C2
RANGE "01..03"
END_USER_TYPE
USER_TYPE COMMENT_LINE_TYPE
DESCRIPTION "This is a line of text that can be found in one of
the PMDB comment relations. There are no rules on
the format of the text within the string, and it may
be blank. A comment relation will normally have
24 fields of this type that enable a record to hold
a fair amount of information (on whatever the subject
is)."
TYPE C80
END_USER_TYPE
USER_TYPE SAA_MODEL_TYPE
DESCRIPTION "This field contains the SAA model id as it applies to a
particular relation. The SAA, or South Atlantic Anomaly,
is a region of the earth over which there is a magnetic
disturbance that affects some of the instruments onboard
the HST. Because of this there are certain events that
have to avoid occurring during an SAA passage. Note
that the different instruments can use different SAA
models (therefore will have different SAA Model IDs).
SAA ID '00' is the TDRS Multiple Access Return (MAF)
Radio Frequency Interference (RFI) model. SAA ID
'01' is the TDRS S-Band Single Access Return (SSAR)
RFI model. SAA ID's '02' through '99' are SAA contour
models for HST and other spacecraft. Relation
'wvvert_type' describes each SAA contour."
TYPE C2
RANGE " ", "00..99"
END_USER_TYPE
USER_TYPE PCS_MODE_TYPE
DESCRIPTION "This field indicates the PCS mode for
the observation set.
GYRO = neither fgs nor FHST is used,
FGS = FGS(s) only are used,
FHST = FHST(s) only are used,
BOTH = both FGS and FHST may be selected by the
acquisition scenario."
TYPE C4
DISCRETE "GYRO", "FGS", "FHST", "BOTH"
END_USER_TYPE
USER_TYPE GSACQ_SCENARIO_NAME_TYPE
DESCRIPTION "This field is the scenario name associated with an
obset's guide star acquisition or re-acquisition. The
scenario will have a set of characteristics associated
with it that will impose limitations on the GS and
GS pair selection process that will eventually be used
in the generation of acquisition data sets stored in the
relation WGACQUIS. Acquisition data sets control the
timing of acquisition and reacquisition activities and
also specify observation set level roll constraints.
This field establishes the link between the relations
QBS_OBSET, QBACQS, QBACQD_DEF"
TYPE C8
END_USER_TYPE
USER_TYPE LRP_NAME_TYPE
DESCRIPTION "This field contains the Long Range Plan (LRP) name created
by SPIKE that associates a group of plan windows for an
SU or group of SUs. The scheduling unit is intended to
schedule some time within the LRP timeframe."
TYPE C15
END_USER_TYPE
USER_TYPE LOCK_FIELD_TYPE
DESCRIPTION "This field is a filler field used for updating the
locking tables."
TYPE C3
END_USER_TYPE
USER_TYPE OPUS_ASSOCIATION_ID_TYPE
DESCRIPTION "This field identifies an OPUS association. An
association is a set of exposures that will be
merged into products by OPUS pipeline calibration
processing. The full association consists of a
list of exposures and products. STIS can only have
one product per association. NICMOS can have as
few as one and as many as nine products.
This field completely identifies an association. It
is set by TRANS. It is used by DADS as the dataset
name to archive the association file. This is the
OPUS value used for the keyword ASN_ID. It has the
following format:
IPPPSSAAa
where:
I = instrument code
(e.g., N for NICMOS, O for STIS),
PPP = program_id
SS = obset_id of the first associated exposure,
AAa = the two-character sequence (AA = 01,02,...)
is unique within the obset SS;
plus the dataset counter (a) that is always
0 (for the first product_id of the
association which is always 0).
For example, the first NICMOS association for
program ABC and obset 01 would be NABC01010."
TYPE C9
END_USER_TYPE
USER_TYPE OPUS_PRODUCT_ID_TYPE
DESCRIPTION "This field identifies an OPUS product. An
association product is a dataset, distinct from
any exposure dataset, that is generated by pipeline
calibration during concurrent processing of multiple
exposures. Exposures are associated in order to
generate products.
This field is a single digit base 36 number: 0, 1,
..., Z, and is set by OPUS.
Note STIS can only have one product per association
while NICMOS can have as many as nine products."
TYPE C1
END_USER_TYPE
Go to the top.