GB . Dynamic . DSSTestDatabase

Overview

A mysql test database named "DynSchedTest" was created from the mysql pas database. "DynSchedTest" was created to facilitate testing of selection rule requirements. The pas database contains many semesters worth of proposal and scheduling information. It was generated from Carl's DBASE files. Pas is not the database that Carl currently uses and its completeness and integrity is unknown. However, it give the DSS team a great opportunity to obtain test data. Carl created a new table in pas called 'vprog' which contained session data for the GBT06A semester. Much of the test data was generated using this table although other tables in the pas database were used when necessary.

This document is not intended to inform the reader about field types, default values etc. for each of the fields in the DynSchedTest database. That information can easily be viewed by users with a mysql account by:

going to http://leo.gb.nrao.edu/phpmyadmin/
selecting the DynSchedTest database
selecting a table
select 'Structure' tab

The Tables

There are currently 4 tables in the DynSchedTest database:

Project - contains meta information general to a project
Allocation - contains meta information that is specific to an allocation in a project
Instrumentation - contains meta information pertaining to the instrumentation required for an Allocation
TimeConstraints - contains meta information pertaining to time constraints of an Allocation. This table is only relevent for fixed and window allocations.

How the Tables were Created

The tables were created using the python script: /home/sandboxes/mmello/dynamic/testcases/python/CreateTables.py Initially the script created tables based on the "Input Table" in the selection criteria, but tables and fields were added when it became clear of the need for fields that were not specifically addressed in the Input table. This is only worth noting because although every effort well.. at least good intention.. was made to update the CreateTable?.py file with the new fields, sometimes this was done AFTER I had created the table using the script.

The Test Data

Much of the meta data required by the DSS for scheduling purposes was in the pas database. Some meta data such as wind and TSYS grades were unavailable from the pas database and were generated by criteria set by the sponsor. This section describes each table and field in the DynSchedTest database and how the test data was generated.

Project Table

Fields

projectId - is an auto incremented id number for each project. The projectId is the primary key and is used to link Allocations to a Project.
projectName - the project name. This name is compliant with proposal name definition currently in use at the GBT. The first 3 letters are GBT, the next 3 characters designate the trimester and are followed by a '-'. The last 3 characters are the unique numbers assined to a given project.
semester - the semester the project has been assinged to.
totalTime - the total observing time in hours allocated by the PSC to this project.
usedTime - this field will be used internally by the DSS to keep track of the amount of time this project has been observed.
scienceGrade - the science grade given the proposal by the PSC. Projects are awarded "A", "B", "C" or "D" science grades.
thesis - designates whether this project is related to a thesis project.---+

How the Test Data in the Project table was Generated

The fields in the DynSchedTest.Project Table, with the exception of the auto generated Id, has either a 1-1 or 2-1 correlation to the data in the Pas.proposal table. The test data was read from the Pas.Proposal table and then stored in the DynSchedTest.Project table.

Pas.proposal.pcode = DynSchedTest.Project.projectName
Pas.proposal.trimester = DynSchedTest.Project.semester TBF OOPS probably should be trimester not semester!
Pas.proposal.allochours + Pas.proposal.allocbhours = DynSchedTest.Project.totalTime
DynSchedTest.Project.usedTime = 0
Pas.proposal.scgroup = DynSchedTest.Project.scienceGrade
- This is how the original science grade was assigned. The scienceGrade test data has since been modified to more closely resemble the proposed, new science grade designations and their expected distribution. How the data was "massaged" is described later in this document.
Pas.proposal.thesis = DynSchedTest.Project.thesis

Allocation Table

Each Allocation record in the table is linked to a project by the projectId field.

Fields

projectId - the projectId of the Project that this allocation is associated with.
allocationId - is an auto incremented id number for each project. The allocationId is used to link Instrumentation and TimeConstraints to an Allocation.
lstMin - the minimum number of the LST range. It is stored in radians.
lstMax - the maximum number of the LST range. It is stored in radians.
localTimes - the time the allocation should run in local time. It is stored in radians. It is not currently used.
minimumTime - the minimum telescope period time this session should be run within.
maximumTime - the maximum telescope period time this session should be run within.
timeBetween - the time between telescope periods that different instantiateions of this Allocation can be run in. Currently this is in days, but probably should be modified to days.
windGrade - the minimum wind grade this alocation requires. The expected values are 1-3.
tsysGrade - the minimum tsys grade this alocation requires. The expected values are 1-4.
totalTime - the number of hours this allocation is intended to be observed.
usedTime - the number of hours this allocation has been observed.
obsHours - constraints on the time o day this Allocation is to be scheduled. Legal values are: 'any', 'night', 'work'.
priority - the priority of this Allocation in relation to other Allocations WITHIN a Project.
solarAvoidance - speciflies if the Allocation has special constraints with respect to the location of the sun. (? do we have enough info in this one field?)
NRAOPriority - An internal priority that can be used at the discretion of the scheduler. Set to 0 for all Allocations.
schedulingType - The type of Allocation, e.g. "fixed", "window", "any".

How the Test Data in the Allocation table was Generated

Each Allocation record in DynSchedTest corresponds to a record in the Pas.vprog table. The test data in each of the fields in each record was derived from fields in various tables of the Pas database.

projectId - the projectId of the Project that this allocation is associated with. It was assigned by carefully scripting the insertion of each Project record followed by the insertion of each associated Allocation.
allocationId - is an auto incremented id number for each project. The allocationId is used to link Instrumentation and TimeConstraints to an Allocation.
lstMin - This value is derived from the Pas.vprog lst, leeway and hours fields. If Pas.vprog.lst was not specified, lstMin was set to Null. If a leeway is specified in the Pas.vprog.leeway field, lstMin was set to Pas.vprog.lst - Pas.vprog.leeway. If Pas.vprog.leeway was 0, then lstMin was set to Pas.vprog.lst - Pas.vprog.hours.
lstMax - This value is derived from the Pas.vprog lst, leeway and hours fields. If Pas.vprog.lst was not specified, lstMax was set to Null. If a leeway is specified in the Pas.vprog.leeway field, lstMax was set to Pas.vprog.lst + Pas.vprog.leeway. If Pas.vprog.leeway was 0, then lstMax was set to Pas.vprog.lst + Pas.vprog.hours.
localTimes - All set to Null.
minimumTime - No equivalent field is in the Pas tables exists. Carl thought that for 80% of the Allocations a value of 2 was adequate.
maximumTime - The value from Pas.vprog.hours was converted to hours and stored.
timeBetween - The value form Pas.vprog.daysep was used. Additional meta data may be gleaned by using the Pas.vprog.schedularnote TBF. Also, I think we should convert this to hours rather than days.
windGrade - No equivalent meta data in Pas. Generating the meta data for these fields is described in the "Massaging the Data" section of this document.
tsysGrade - No equivalent meta data in Pas. Generating the meta data for these fields is described in the "Massaging the Data" section of this document.
totalTime - This value is the result of multiplying the Pas.vprog hours, mult, outermult fields.
usedTime - Set to 0 for all records.
obsHours - No equivalent meta data in Pas except for 2 exceptions where suitable meta data was found in Pas.vprog.schedularnote. Generating the meta data for these fields is described in the "Massaging the Data" section of this document.
priority - Set to 0 for all records. There may be a way to set the priority by using the text in the Pas.vprog.schedularnote. TBF.
solarAvoidance - Used the Pas.vprog.schedularnote to generate the meta data.
NRAOPriority - Set to 0 for all Allocations.
schedulingType - Set to 'Fixed' for all Allocations within a Project where Pas.proposal.proptype = 'RSS-TOO' (Target of Opportunity). See the "Massaging the Data" section for information on how additional meta information was generated.

Instrumentation Table

Every record in the Instrumentation is linked to a record in the Allocation table by the allocationId.

Fields

projectId - the project Id that this instrumentation record is associated with. I suspect this can be deleted, instrumentations are linked to Allocations and not directly to Projects
allocationId - the Allocation Id that the instrumentation record is associated with.
receiver - The receiver designation(s) of this instrumentation record. The receiver designations used are from Carls Pas database. We may want to refine them.
backend - The backend designation(s) of this instrumentation record. The backend designations used are from Carls Pas database. We may want to refine them.
bandwidth - Set to 0. This needs to be completed.
frequencies - TBF. We probably can get some of this meta data from text fields in Carls database. ( but I don't believe we will get these from the PST?)

How the Test Data in the Instrumentation table was Generated

Most of the meta data is available in the Pas.vprog.receiver and backend records. Bandwidth and frequencies are in text fields in the resource table and are not clearly linked to the vprog table.

projectId was set to the projectId in the allocation that this instrumentation record is associated with.
allocationId - the Allocation Id that the instrumentation record is associated with. It was assigned by carefully scripting the insertion of each Project record followed by the insertion of each associated Allocation.
receiver - The receiver was set to the value in Pas.vprog.bands.
backend - The backend was set to the value in Pas.vprog.backends
bandwidth - Set to 0. This needs to be completed.
frequencies - TBF. We probably can get some of this meta data from text fields in Carls database. ( but I don't believe we will get these from the PST?)

TimeConstraints Table

Each record in this table describes the information required to schedule a "window" or "fixed" allocation. Only allocations that are "window" or Fixed have TimeConstraint? records associated with them. This may not be such a good idea, since completion date etc. will need to be kept for all Allocations. Even then, its probably not complete ( for instance times reqwuired?) , it is a first cut. I think new TimeConstraints? records will be generated by the DSS as an Window of Fixed allocation is run.

Fields

id - an auto incremented field that uniquely identifies a record
allocationId - the Allocation Id of the Allocation that this time constraint is associated with
startDate - the starting date.
endDate - the ending date.
completionDate - the date this timeConstraint wa completed
completed - a flag that is set when the timeConstraint is completed

How the Test Data in the TimeConstraints table was Generated

id was auto generated.
allocationId was assigned by carefully scripting the insertion of each Allocation record followed by the insertion of each associated TimeConstraint? record.
startDate was intentionally left as NULL. Null values in this field that are associated with a "Window" Allocation signifies that ther is currently no window time constraint since the first observation using this allocation has not occurred. I imagine that for some Allocations, the user might want to set the initial data and certainly for "Activities".
endDate - Currenlty NULL in all records.
completionDate - Currently NULL for all records.
completed - currently 0 for all records, i.e. none are complete.

Massaging the data

schedulingType was refined for "window" projects. schedulingType in Allocations that had timeBetween > 0 were set to "Window".
windGrade and tsysGrade were set by assigning a percentage of each Allocation using 3 separate receiver categories to a specific weather bins.
- Allocations using the ka receiver and higher were allocated weather grades according to these percentages:
  - 10% exc wind, exc tsys
  - 30% good wind, exc tsys
  - 30% exc wind, good tsys
  - 20% good wind, good tsys
  - 10% poor wind, good tsys
- Allocations using the receivers < Ka but greater than L were allocated weather grades according to these percentages:
  - 5% exc wind, exc tsys
  - 10% good wind, exc tsys
  - 10% exc wind, good tsys
  - 50% good wind, good tsys
  - 25% poor wind, bad tsys
- Allocations using the receivers <= L were allocated weather grades according to these percentages:
  - 75% poor wind, bad tsys
  - 25 good wind, bad tsys
obsHours was set to 'night' for all Allocations that use the Qband receiver. TBF. The same rule applies for Kaband receiver Allocations, but has not been done.
schedulingType was set to "Window" for all Allocations whose timeBetween field is > 0.

-- MelindaMello - 17 Nov 2006

Topic DSSTestDatabase . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More }

Revision r1.4 - 14 Dec 2006 - 12:37 GMT - MelindaMello	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 > DSSTestDatabase

Changes \| Index \| Search \| Go