Science Tools Walkthrough

6 April 2004

Present: Jean Ballet, Sandhia Bansal, Joanne Bogart, Toby Burnett, Jim Chiang, David Davis, Seth Digel, Marco Frailis, Riccardo Giannitrapani, Navid Golpayegani, Traudl Hansl-Kozanecka, Yasushi Ikebe, Heather Kelly, Matt Langston, Francesco Longo, Michael Kuss, Pat Nolan, James Peachey, Dirk Petry, Jeff Scargle, Robert Schaeffer, Tom Stephens

The presentation

Toby and James gave the presentation, which closely followed their web page (or see alternate non-frame version).

There was some discussion of the checkout section under the heading Packages. Traudl suggests, for non-checkout packages, use statements should specify the interface part ("v number") and wildcard the rest (issue to be fully resolved offline).

In the section A library/Application Primer see a sample requirements file; using the macros defined in STpolicy keeps it short and simple. James noted that, although the pre-supplied class st_app::Iapp, which functions as a main, will capture all thrown exceptions, nothing prevents applications from handling recoverable exceptions themselves instead. Follow the links to see several application examples (not quite fully documented, but about to be); see also the very helpful st_app Doxygen documentation.

See James' presentation to learn about tip (Table and Interface Package). It supports table access for FITS and Root files; there is as yet no analog of FITS keyword access for Root files. Images are still to come; as are several other features listed in the presentation. The Doxygen documentation is complete and clear; highly recommended for all users.

The package sane provides (will provide) an umbrella for access to all science tools. Not all tools have been integrated yet. The diagram (under the section Executables and Runtime Environment shows what it includes currently (to be compared with the old dependency graph).

Other comments

(Francesco) Does Likelihood behave the same way in the new scheme of things as it did before? (Jim) Yes, this has been verified.

(James) Heasarc is aware of current direction w.r.t. gui (Root- or python-based) and is not raising objections.

(Dirk, Seth) What comes next? What about missing pieces in the new picture, like the Observation Simulator? (James) This has to be converted to use tip rather than Goodi and the new tip code James has written for file creation has to be committed; then the integration can proceed. James has been responding to feature requests from the two alpha-testers (Toby and Jim); he invites others to become users and put in requests.  In fact, he'd welcome volunteers, particularly local volunteers, for pair programming.

(Bob) Speaking of Extreme Programming practices, what about testing? James has addressed this to some degree in a user package users/Peachey/tug; however work on this has been suspended. Jim is hoping to make use of CppUnit; before proceeding any further he has to get it to build and run on Windows as well as unix.  See the user package users/jchiang/unitTests.

How to deal with FITS schema evolution? (James) For writers, it's not much of a problem. The code doing the writing is tightly bound to the template, probably should be in the same package. For readers there is likely to be some grief on occasion, lessening as templates stabilize. He thinks designing and implementing a industrial-strength facility to deal with this is not worth the overhead.


Last modified: 12 April, 2004 10:10:48 -0700
J. Bogart