NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > DSSTestCode

Changes | Index | Search | Go

• Introduction
• What's been implemented
• How the selected Allocations can be displayed
  • The Simulation
• Selection Rules that have not been implemented at all
• Selection Rules that have implemented in some fashion
• Sorting Rules that have not been implemented
• Short List of what else should be done with the Database
• Short list of what else should be done with the progam and displays
• Testing

Introduction

What's been implemented

• getProjects() - returns all project names from the Project table
• getProject("project") - returns all fields in the Project Table for the specified project
• getProjectData("project") - returns the project name, the scienceGrade, the Allocation Ids and the Allocation totaltime for the specified project
• getAllocationData("project") - returns all Allocations and thier fields from the Allocation table that are associated with the specified project
• getFixWinAllocations() - returns the project Id, the allocation Id, the Allocation scheduling type for all fixed and fixed window allocations
• getInstrumentationForAllocation(allocationId) - returns the allocation id, the receiver, backend and bandwidth from the instrumentation table associated with the specified allocation id.
• getInstrumentation() - returns the allocation Ids and the receiver for all recordes in the Instrumentation table
• getScienceGrade() - returns the project Id and the science grade for all records in the Project table
• getProjectName(id) - returns the project name associated with the specified Allocation Id
• getAllAllocations(id) - returns all the fields in the Project and Allocation tables whose records are associated with the specified Allocation Id
• getTimeBetween() - returns the allocation Id and the timeBetween fields in the Allocation table for the timebetween value > 0.
• getAllLst() - returns 2 lists, the first contains the mimimum LST for all Allocations, the sceond list contains the maximum LST for all Allocations in the Allocation table
• getAllAllocationsWithinLST(currentLST) - returns a list containing the project name, scheduling type, observing hours, allocation id, lst minimum, lst maximum, windGrade (no longer relevent!!! TBF must be changed to comply with new wind fields), tsys grade, science grade, total allocated time to project, used project time, thesis, mimimum allocation run time and receiver for all Allocations whose LST range is within the specified LST AND whose Project still has time available AND whose Project has been awarded time. The results are ordered by science grade, percentage complete, scheduling type and thesis
• getCriteria1(currentLST, currentWind, currentTSYS, obsHours, scienceGrade)
  • Inputs
    • currentLST - input as float.
    • currentWind - input as float
    • currentTSYS - input is still the "old" tsys grade; int values 1 through 4
    • obsHours - legal values are "any", "night", "work". Default is to "any"
    • scienceGrade - legal values are "A", "B", "C", "D". Default is "D"
  • The selection rules it implements and how the Allocations are returned
    • Three lists are returned:
      • The first list contains the Allocations whose fields meet the following selection critria (perfect weather match)
        • the specifed LST is within the range of the LST maximum and minimum AND the allocation mimimum runtime can be met with the current LST and maximum LST range.
        • there is still time left to be used in the Allocation
        • the specified wind is between the maximum and mimimum wind range of the allocation AND the TSYS grade is equal to the specifed TSYS
        • the obsHours is equal to the specified obsHours
        • the allocation is currently runnable
        • the science grade is equal to or less than the specified scienceGrade
        • the allocations associated Project has remaining time left
        • The results are ordered by
          • scienceGrade
          • the allocations minimum wind criteria - the specified wind (in decreasing order) (?? Should this be the maximum wind - the specfied wind?)
          • projects percentage completion ( in decreasing order )
          • scheduling type
          • thesis
      • The second list contains the Allocations whose fields meet the following selection critria (the wind is too good)
        • the specifed LST is within the range of the LST maximum and minimum AND the allocation mimimum runtime can be met with the current LST and maximum LST range.
        • there is still time left to be used in the Allocation
        • the specified wind + some incremented value is between the maximum and mimimum wind range of the allocation AND the TSYS grade is equal to the specifed TSYS. (the increment value starts at 1 m/s and is incremented by 1 until at least one allocation fits the criteria)
        • the obsHours is equal to the specified obsHours
        • the allocation is currently runnable
        • the science grade is equal to or less than the specified scienceGrade
        • the allocations associated Project has remaining time left
        • The results are ordered by
          • scienceGrade
          • the allocations minimum wind criteria - the specified wind (in decreasing order) (?? Should this be the maximum wind - the specfied wind?)
          • projects percentage completion ( in decreasing order )
          • scheduling type
          • thesis
      • The third list contains the Allocations whose fields meet the following selection critria (fixed window within the next 8 hours)
        • the startDate and time < the current date and time + 8 hours ( I arbitrarily assinged an 8 hour "preview" mechanism)
        • there is still time left to be used in the Allocation
        • the specified wind + some incremented value is between the maximum and mimimum wind range of the allocation AND the TSYS grade is equal to the specifed TSYS. (the increment value starts at 1 m/s and is incremented by 1 until at least one allocation fits the criteria) AND the Allocation has not been completed. NOTE: this is not the same as hours left, this is a different field.
        • the schedulingType is 'fix' (Both Paul and I think a similar approach to "window" types should be implemented)
        • The results are ordered by:
          • scienceGrade
          • projects percentage completion ( in decreasing order )
          • scheduling type
          • thesis
        • NOTES
          • In theory no ordering should be necessary
          • If a fixed project has NOT completed at the correct date:time, I still show it in the list so that it doesn't disappear. In theory this should NEVER happen.

How the selected Allocations can be displayed

The Simulation

• QueryPlot?.py - Displays the output to the user.
• query.py - just a wrapper class tha can be called usng the execfile("query.py") command in the DEAP command line console. Before execing this file from the DEAP python command console, one must declare a python dictionary called "args" with the following keys:
  • 'grade' - specifies the lowest grade to be used in the selection rule for scienceGrades in the query. Thus args["grade"] = "B" will result in allocations whose project has a science grade of "A" or "B" meeting the selection criteria.
  • 'lst' - The LST of interest. This should be changed to a date:time string
  • 'obshours' - the time of interest. Legal values are "any", "night" or "work". When the lst is changed to date:time, and the day/night transistions are added to a database table (or something) this argurment can be removed.
  • 'wind' - the wind speed is in m/s.
  • 'tsys' - currently the "old" tsys grades of 1 through 4 are used.

Execing this file results in the query being run with the selection parameters in the args dictionary. A plot of the qualifying allocations are displayed and 3 lists are displayed, one containing all fixed windows from the current date:time to the current date:time + 8 hours, another list containing a list of the allocations that meet the current selection rules and have the exact weather criteria specfied, the third list contains allocations that meet the current selection rules with the exception that the current wind is better than these allocations require. As soon as TSYS specifications are refined, the same type of rule will be applied to it (the matrix). Three sample displays are shown and described below.

The displays show the prototype output of the query tool with the implemented selection and sorting rules described above.

• The Y axis is the suggested priorites where the higest priority is #1.
• The X axis is LST in radians. This will be modifed to be UTC at some point. Negative LSTs are the midnight crossover range.
• The vertical Red line is the specified LST of interest.
• Each Allocation display line ranges from the LST minimum and LST maximum range.
• The circles on each Allocation display line is the LST that corresponds to the minimum time the allocation should be run. The value for minimum time is 2 for most of the Allocations in the test database.
• The black vertical lines were intended to show 4 hour telescope periods from the specified LST. I've royally messed this up, but don't want to spend the time to fix it until we move to the UTC display.
• I do have code that displays Project numbers and some vital Allocation information as a legend in the graph. Displaying as a legend works ok if there are a small number of selected Allocations, but the graph quickly gets too busy with a moderate number of qualifying allocations. For now, information for each qualifying allocation is printed in the console window. Possible ways to put more Allocation information in the DEAP display are annotaions, tables, or separating the display into 2 panes. I haven't looked into ay of these options yet.

COLOR Legend: Upcoming (or Past allocations that have not been completed!) Fixed allocations are displayed in Red. Allocations whose wind criteria is a perfect match for the specified weather conditions are displayed in Green. Allocations whose wind criteria can be met with the specified wind conditions and tsys but don't require as good wind conditions as specified are shown in Yellow.

Display 1 show the output for the input conditions of wind = 1.1, tsys=1, obshours = "any", lst = 1.5 and of filter set that selects only allocations with a science grade of A or B. In this example there are 3 fixed allocations coming up but notice the date!. These allocations should have run on 11/29/06 and 11/30/06 but were not completed so they are still shown. There are no allocations in the database that meet the selection rules exactly. The query mechanism increases the specified wind velocity by 1 m/s until at least one allocation is returned that meets the criteria.

Display 2 show the output for the input conditions of wind = 4.1, tsys=1, obshours = "any", lst = 1.5 and of filter set that selects only allocations with a science grade of A or B. It is essentially the sample example as display 1 except that the wind velocity was increased such that the formerly "next best" weather conditions are now the exact weather condition. The allocations that were "yellow" are now "green" and a new allocation requiring the "next best" wind condition is displayed.

Display 3 show the output for the input conditions of wind = 6.1, tsys=4, obshours = "any", lst = 1.5 and of filter set that selects only allocations with a science grade of A or B. This is pretty "crappy" weather but apparently our database is chock full of allocations requiring the lower frequency receivers. There are no allocations in yellow because the largest value for any minimum wind in the database is 6.1.

Display 4 show the output for the input conditions of wind = 1.1, tsys=1, obshours = "nigh", lst = 1.5 and of filter set that selects only allocations with a science grade of A or B. It is essentially the sample example as display 1 except that the obshours is now "night". Qband allocations are selected (the kaband allocations have not been changed to "night" yet).

Selection Rules that have not been implemented at all

• Is the observer available?
• Has the total time for this allocation exceeded the maximum allowed for the given semester? I think this really only comes into play for legacy projects. It should be relatively simple to add.
• The last opportuinity for a monitor project. In fact, In general I am displaying the monitoring projects as "regular" projects.

Selection Rules that have implemented in some fashion

• There is a filed called "currentlyRunnable" in the allocation table that specifies whether the hardware is currently available for this allocation. The values have been arbitrarily assigned.
• Is the time of day correct for the entire session (work hours, nighttime, any time, solar avoidance).
  • Since sessions are not part of the querying process, this doesn't make sense at the current time. If the DSS acutally fully schedules the "sessions" than this requirement will make more sense.
  • What does it mean to avoid the sun? I put these projects as "night" but suspect that avaoiding the sun might be better specified as within some number of degreess within the sun? There was only 1 (possibly 2) projects in GBT06A that had soloar avaoidance specified. NEED more refinement as to what it means
  • Is the minimum time for the allocation less than or equal to the available session time (e.g. it doesn't run into any fixed time sessions)? Again session time does not come into play. This requirement was implemented as the is the will the source be up for minimum time required by the allocation.

Sorting Rules that have not been implemented

• Is the observer on site?
• What is the semester for this project? NEEDS clarification..do past semester projects get priority or current semester projects or is it more reasonable to run allocations based on the other priority rules?
• Percentage completion is not broken done into quartiles, the actually value is currently used

Short List of what else should be done with the Database

• allocations using Ka band reciever should be changed to have "obsHours" = 'night'
• average of the Referee grades should be added to each project and the ordering changed to include it as the final ordering criteria.
• need to populate the bandwidth and nwin fields in some sane mannor.
• user information
• contact infomation
• user availability
• incorporate the concept of alloc "A" and alloc "B" hours in one project and allocation
• look in the pas database for more info in text fields concerning our "timebetwee" value
• fix rounding problem for float values
• add a lst maximum time for a given lst and add to query selection rules

Short list of what else should be done with the progam and displays

• convert graph and inputs to data:time
• start saving the results including changing the used times
• need to convert tsys to new system whenever that new system is determined
• fix 4 hour vertical lines
• shift xaxis on graph based on current time
• show fixed window similarly to how fixed allocations are displayed
• negative lst ? does this issue go away when we convert to dates?
• display the allocation details in the graph section of DEAP rather than the console

Testing

-- MelindaMello - 11 Dec 2006