Attendees


Dave Brunkow, Gordon Farquharson, Dennis Flanigan, Jim George, John Hubbert (for part of the meeting), and Joe VanAndel

Notes


  • It was agreed that final decisions about engineering related issues would be made by Chandra.
  • Several products were identified to track project progress and develop milestones. These include OmniPlan (Mac OS X only), MS Project (Microsoft Windows only), Enact (requires a license for each person involved in the project). We decide to look into alternative options, and preferably one which had web-based capabilities.
  • We found that there was good compatibility between operating systems that were used at S-Pol and CHILL. CHILL uses Fedora for workstations and CentOS for servers/data processing machines. S-Pol uses CentOS.
  • It was proposed that we implement design and code reviews so that all software engineers would be familiar with the code in the system.
  • We decided to organize a tour of CHILL for the S-Pol engineers to see the CHILL software in action. Jim will create an outline of the presentation of the software, and during the tour, Joe and Dennis will document the software as Jim presents it. This documentation will then be expanded to provide a high level overview of the CHILL software architecture.
    For more detailed documentation of code, we agreed to use Doxygen.
  • We agreed to focus our efforts on building new features on top of the existing framework that CHILL had implemented rather than reimplementing existing systems at the start. All of the CHILL software is implemented in C and user interfaces are built using the GTK+ toolkit. EOL software engineering has standardized on C++ and the Qt Toolkit. We discussed whether we should standardize on a common language and toolkit for future developments, or whether we could work with a heterogeneous environment which would likely add some overhead to maintenance of the software. Jim agreed to evaluate using Qt and Joe is to send him some documentation and resources about Qt.
  • We discussed the data formats that will be used in the radars. Mike Dixon had said that the time series format developed at CHILL was well implemented and he had proposed that is be adopted for both radars with some minor changes.
    For transporting moments data between processes, we agreed to use the CHILL SDB format so that we did not have to re-engineer current processes now. Use of this format will mean that we can focus on getting the CHILL software running on S-Pol as soon as possible, and concentrate on new features for the radars. Jim did mention a few deficiencies in the SDB format (e.g. tied to little endian) that we may address down the line. However, it is easy to add to the format so it shouldn't pose any problems in the near term.
  • For archived data, we agreed to use a data format that is based on a common format such as netCDF4 and develop a community-based library to access this format. This work ties in nicely with a joint effort between EOL and Unidata to develop a data model of radar data for IDV, and another development at EOL to write an improved version of Foray, which is a data interchange library for radar data.
  • Dave presented an overview of the CHILL antenna controller system, and their plans for future development. We discussed the use of the PMAC controller, and Dave pointed out that a Delta Tau only produces Windows drivers for their PCI PMAC cards. Because of this driver limitation, CHILL is using an Ethernet PMAC system and a 10Base2 network connection through the slip rings. However, this requires the radar to poll the PMAC for updates on changes to the scan information and CHILL has had problems with the communications link in the past. Dave is looking into changing the control system for CHILL such that PC handles more of the control of the antenna. This would make the PMAC motion control programs simpler.
    There are minor differences between the S-Pol and CHILL control systems, e.g. S-Pol has the PMAC controller below the pedestal azimuth rotation whereas CHILL has the PMAC controller above the azimuth rotation. However, these differences are unlikely to prevent us coming up with a common solution that works for both systems.
  • We discussed monitoring system software. Joe presented Nagios, an open source package, which was configured and used to monitor S-Pol during TiMREX. It has a web-based status display that can be accessed through any browser. Jim presented a monitoring protocol based on a UDP multicast system and associated package that he had recently  developed. He also showed us Munin, another open source monitoring package, which is running on CHILL to monitor servers. It looks very similar to Nagios. We also discussed the importance of logging messages from processes to aid in debugging problems in the system.
  • The idea of using a distributed version control system was presented. These systems operate on the principle that there is no master repository of software. Each developer has their own repository and changes are pulled into repositories when appropriate. The Linux Kernel project uses git which was written by Linus Torvalds, and is an example of one of these systems.
  • We proposed using Google Documents to collaboratively write and share documents. We also proposed creating several mailing lists for the integrated facility to make it easier to email all participants, e.g. iwrf-all, iwrf-eng, iwrf-sci, iwrf-ed, etc. We did not decide on which organization would host these.

Action Items


  • Investigate project management systems (Jim, Joe, Dennis).
  • Organize trip to CHILL for S-Pol engineers (Gordon).
  • Send resources on Qt toolkit (Joe).  [Done]
  • Investigate Qt (Jim).
  • Investigate and recommend a distributed repository system (Joe, Jim).
  • Create mailing lists (decide on which organization would hosts these).
  • No labels

2 Comments

  1. Open-sourceProject management tools:

    Two such tools are taskjuggler and planner.

     Planner has a set of basic task management tools, like Gantt charts, task assignment, resource assignment and usage. It is currently at version 0.14.2 (what comes with Fedora 9).

     TaskJuggler turned up in a list of Office applications available from Fedora, I installed it, but couldn't find it in the applications menu. Instead, it got filled in with a bunch of KDE apps, including "KOrganizer", which it seems to integrate itself in to. I can't find the usual things like Gantt charts and such. Also, I got a whole bunch of stuff (including "KitchenSync") which I didn't ask for...

     Please send feedback on "Planner", to see if it's up to the task.

  2. I've had some experience with Planner -- used it to develop plan for our Spring 08 preparations for operations.  I haven't had much experience with this sort of software, but found Planner worked well.  The document is available at ftp://chill.colostate.edu/pub/brunkow/Spring08.planner if you'd like to try it.It looks like the program is being actively developed.