NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > MetricsC52006
   Changes | Index | Contents | Search | Statistics | Go

Software Development Metrics & Information Summary for C5 2006

The Plan of Record used for this cycle can be found at PlanOfRecordC52006.

Overview

6 SDD members worked 1531.8 hours in C5 2006 over 6 weeks (73% cycle commitments, 5% GBT operations support, 22% overhead incl. vacation/sick/holiday time).

overvieweffortC52006.jpg

Project Allocation

The cycle commitments were allocated over 6 major projects: Dynamic Scheduling, SDFITS/GBTIDL, PTCS, Penn Array, High Freq Activities, Zpectrometer. In the chart below, "other" is used as a catch-all for those commitments without a major project. The "other" category is dominated this time by the NRAO-wide software engineering conference.

projecteffortC52006.jpg

The projects are further broken down into the individual commitments in the next section.

Cycle Commitments

The cycle commitments for C5 consisted of 18 commitments. 4 items discussed in this summary were background tasks. A summary of each commitment is discussed later in its own section. Of the 18 commitments, 12 were met satisfactorily. 6 were not completed as expected and continued over into the next cycle.

commitmentsoverviewC52006.jpg

Operational Support

The items listed below pertain to time spent supporting GBT operation. These tasks usually involve helping users, fixing/troubleshooting system problems, and fixing/troubleshooting lab test environment problems. Note: Effort estimates reflect total time elapsed, i.e. how long did it take to fix the problem start to finish - not the sum total of each person's time.

Key:

Commitment Highlights

Evolve Dynamic Scheduling Proposal

Information on the Dynamic Scheduling project can be found at the Dynamic Scheduling Project Page and Dynamic Scheduling Web Home. The effect of weather conditions, both wind and opacity, on high frequency astronomy is well known. Currently, the GBT is using a fairly basic dynamic scheduling system which neither allow for rapid changes in the weather nor for long spells of good or bad weather. To maximize our use of good weather, we need to implement a true dynamic scheduling system on the telescope. The design and implementation of such a system is the goal of this project. This task was allocated 300 person-hours of effort, of which 267.3 were actually used. A majority of this time was spent at the JCMT/UKIRT trying to understand their successful dynamic scheduling system.

Create NRAO-wide reservation system

The creation of an NRAO-wide reservation system is aimed at consolidating the disparate systems used in Green Bank and Socorro for visitor accomodations and support. Green Bank currently uses a system called CRAINS and Socorro currently uses a system called BARS. This project is currently in stage 3. A history of stages can be found at: ReservationsStageOne, ReservationsStageTwo, and ReservationsStageThree. The current aim of the project is to seamlessly transfer reservation information and basic business transactions performed by the respective business offices into PeopleSoft where fiscal can access the information. Most of the work this cycle focused on the selection of scenario 3 in ReservationsStageThree as the appropriate way forward. Next cycle, we aim to update the project charter with this new information and generate a series of MRs, which will describe the work needed to achieve scenario 3.

Zpectrometer (Manager, SDFITS, GBTIDL, LO1, Ka Manager changes, IF Manager changes, Meetings)

A description of the Zpectrometer Project can be found at ZpectProject. Zpectrometer software development can be tracked at the ZpectSoftwareDevelopment status page. As of this cycle, we have the microcontroller development kit for the Zpectrometer microcontrollers. This kit will allow us to modify the firmware of the Zpectrometer as needed throughout its lifecycle on the GBT.

We are also writing an MR which specifies the changes needed to SDFITS and GBTIDL for Zpectrometer data reduction when the Zpectrometer is being commissioned. The implementation of this MR is scheduled for next cycle.

Additionally, the Ka Manager and IF Manager underwent modification to accomodate the new backend. This work is close to completion and will continue into next cycle.

Finally, for Zpectrometer calibration routines, the university-supplied software requires direct control of the GBT LO1 test tone signal. Modifications were made to the LO1 Manager to support this functionality. This work is mostly complete but will be carried over until next cycle for testing. This activity was not identified at the planning meeting for cycle 5 and was added mid-cycle as the requirement was recognized.

Our estimates for the work involved in bringing the Zpectrometer online were fairly accurate. We allocated 168 person-hours of effort and expended 155.35 person-hours. Luckily, some efforts were smaller than expected and we were able to fit in the LO1 work, which was unanticipated.

Penn Array Receiver (PAR)

Details on the Penn Array Receiver can be found on its project page. The focus of our work this cycle was to support the FITS archiver software developed by members of the SDD using the IRC framework. We expect this activity to continue into the next few cycles as the PAR comes to Green Bank and is commissioned on the GBT. We underestimated the effort required for the support task. We allocated 44 person-hours of effort and expended 61.6. The overage is due to the fact that JoeBrandt spent time, which wasn't pre-allocated, on PAR support.

Implement Spectrometer "Bad Lags" Fix

The GBT Spectrometer suffers from drop-outs in the values for some of the lags. While this problem is being fixed in hardware (see http://www.gb.nrao.edu/GBT/spectrometer/index.html), that fix will not be complete in the near future. To help observers with this problem, we are working on a fix in the AIPS++ and SDFITS fillers to allow users to replace the bad lag values with values which closely repreesnt reality. The effort required to complete the item was grossly underestimated. We allocated 48 person-hours of effort and have expended 109 as of the end of cycle 5. This task will be continued into next cycle as testing unearthed a case that was not covered.

Test Antenna Trajectory Algorithm

This task is in support of the testing of FredSchwab's new antenna trajectory algorithm only - no integration with the Antenna Manager planned for C5. One round of testing was completed. We plotted the results in a report, and discussed the results with JohnFord. We have committed to providing a test version of the servo software with which JohnFord may experiment in August. We will continue to support JohnFord's testing next cycle, but expect it to require minimal effort. The effort required to complete the item was grossly overestimated. We allocated 120 person-hours of effort and have expended only 14.6!

Implement Linux Quadrant Detector Manager

The Quadrant Detector (QD) is required for upcoming PTCS activities and has been reconfigured to support these activities. More information on the Quadrant Dectector is available at QuadrantDetectorUsage?. Although a QD M&C Manager currently exists, it needs to be updated/replaced to support the current state of the QD hardware. The QD Manager is one of the main tasks listed as part of the PTCSProjectPlan and is the impetus of this MR. Work is almost complete on this task. Currently, the Manager compiles and links, with a new GDAQ library shared with the accelerometers. All Samplers and Parameters have been added to the data descriptor library (DDL), which is complete. This task will continue into next cycle. Summary of work remaining: DT-50 library and testing. The effort requested for this activity was pretty accurate. Only 50.9 person-hours of the allotted 96 person-hours were used, but the task remains incomplete. The effort was redirected from QD implementation to software conference preparation. We expect that the time required to finish this task is on par with the unused 45 person-hours.

GBTIDL (autoflagging, imaging)

GBTIDL has the capability to flag specific parts of the data on disk. These flag rules are then applied when the data is read in to GBTIDL. The rules can be fairly complicated and ultimately any bit of data can, in principle, be flagged. See the Introduction to Flagging and Blanking in GBTIDL for more details. In practice, it can be quite tedious to know what data should be flagged and to set those flag rules by hand from the GBTIDL command line. User of dish in the aips++ system have found the aips++ autoflagger tool to be useful in flagging large blocks of data. GBTIDL needs a similar capability in order both to make GBTIDL as capable as dish and thus attract dish users who would otherwise be unlikely to move to GBTIDL and to provide necessary enhanced flagging tools to make flagging data in GBTIDL as easy as possible. GBTIDL needs the ability to flag large blocks of data according to one or more rules. An autoflagger is something which automatically flags data based on these rules. It can be invoked with one or perhaps a few procedures typed by the user at the command line without the user needing to explore the data in detail.

Likewise, imaging is a missing vital component to data reduction in GBTIDL. We are currently investigating possible technologies to incorporate into GBTIDL to support imaging of data.

This cycle 168 person-hours of effort were devoted to autoflagging and imaging, 123 were expended. The primary reason why the expended number was much lower than the expected number was that the Spectrometer "bad lags" fix took more effort than originally planned. Work will be suspended on these activities next cycle, but we hope to continue them in the following cycle (C7).

Topic MetricsC52006 . { Edit | Attach | Ref-By | Printable | Diffs | r1.6 | > | r1.5 | > | r1.4 | More }
Revision r1.6 - 13 Oct 2006 - 15:14 GMT - RichardPrestage Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.