Minutes of HEASARC Users Group Meeting

April 12-13, 2006

1. Agenda

Wednesday April 12

  
        9:30am Coffee/snacks
       10:00am Session start: Introductions, Logistics, etc
       10:10am HEASARC Overview (Nick White)
       10:40am NASA HQ Perspective (Jeff Hayes)

       11:10am Break

       11:20am EPO Activities (Jim Lochner)
       11:40am HEASARC-Supported Activities at SAO, 
	       including Chandra Archive (Roger Brissenden)

       12:10pm Lunch

        1:00pm Tour of the HEASARC Website (Karen Smale)
        1:30pm HEASARC On-line Services Session & Demos (Tom McGlynn)

        3:00pm Break

        3:15pm Distributed HEASARC Software

             1. HEAsoft package (Bill Pence)
             2. XSPEC (Keith Arnaud)
            
        4:00pm Interoperability, including XMM and Swift optical datasets 
               availability through MAST, SkyView, and NVO (Tom McGlynn)

        4:40pm Close for the day

Thursday April 13

        8:30am Coffee/snacks
        9:00am Session Start: Logistics, etc.
        9:05am Active Missions Archiving in HEASARC
                - GLAST (Mike Corcoran)      20 mins
                - Suzaku (Lorella Angelini)  15 mins
                - Swift (Lorella Angelini)   20 mins
        10:00am HEASARC On-line Services Session & Demos (continued)
             4. Hera demo, including XMM SAS (Bill Pence))

         10:30am Break

         10:45am Active Missions Archiving in HEASARC (continued)
                - HETE-II (Mike Corcoran)    10 mins
                - INTEGRAL (Steve Drake)     10 mins
                - XMM-Newton (Steve Drake) 
		  and Particle Background Modeling (Steve Snowden)  10 mins
                - RXTE (Padi Boyd)           10 mins
          11:25am Any Other Business

             noon Lunch

           1:00pm HEASARC Future Initiatives and Directions (All)
           2:00pm HUG Executive Session
           2:30pm HUG Initial Response/Recommendations (Frits Paerels)
           3:00pm Finish

2. Notes from the Meeting

Present: Derek Fox, Sarah Gallagher, Eric Gotthelf, Julia Lee, Nancy Levenson, Frits Paerels (Chair), Paul Ray, Gordon Richards, Masao Sako, Rita Sambruna. Jon Miller was absent, with notification.

The HEASARC Users Group (HUG) met on April 12-13, 2006, at GSFC.

First of all, we would like to express our general and unanimous appreciation for the excellent job the HEASARC is doing. We feel it really is a model archival research center. We very much appreciate the forward-looking attitude, which very effectively anticipates the user's needs, and we are very happy with the HEASARC's responsiveness to user needs, desires, and advice. We are also impressed and very enthusiastic about specific items of recent development, such as the HERA and the Browse by Keyword, and we strongly support their (and other items') future development. Several members and colleagues frequently reaffirm that without the HEASARC, much of what we do in High Energy Astrophysics would be impossible to accomplish.

We heard a general presentation by the HEASARC Director, Nick White, regarding the general mission and objectives of the Center, specific developments over the last two years, and a statement concerning the role of the HUG and specifics on what the Center would like us to comment on. Nick also touched on interaction of the HEASARC with the National Virtual Observatory. Jeff Hayes briefly outlined current organizational and financial aspects of Space Astrophysics at NASA. Jim Lochner reported on the HEASARC-wide EPO program. Roger Brissenden reported on issues concerning HEASARC-supported activities at SAO, and the interaction with the Chandra archive.

Following these presentations, we saw a series of presentations on the status of the archive for past, current, and future missions, and on software development. Instead of including detailed notes on these in our minutes, we refer to the on-line archive of HUG meeting presentations.

Concerning these latter issues, related to archive and software, we have a series of specific comments, detailed below (not in the chronological order of presentation):

Software development, Tools, Databases and Searching:

1. The HUG was surprised by HERA. We think it is an impressive tool, and we strongly support its further development, for a number of reasons (it can potentially greatly simplify the work of a researcher, releasing her/him from the necessity to install the LHEA software on her/his own computer-with all its attendant problems of platform and version incompatibility, etc.; it lowers the barrier for first-time high-energy-astrophysics-data users; it offers a simple way to experiment with a user-designed analysis without the need to download all the software; one can run a user-defined 'pipeline' on large amounts of data without the need to download all the data either). We have one practical request: with further development, undoubtedly at some point there will be back-compatibility issues, which could hamper large-volume, or long time-interval analysis projects that straddle the break (these could be as simple as just a redefinition of a quantity, not even a technical software issue). It would be very helpful if outside users could have access to a stable (backup) version of Hera. Also, some logging capability that records the commands and parameters of each step would be extremely useful (i.e., so that a process once developed can be repeated consistently).

2. 'Footprint Mapping': When searching the archive, you can currently only do a 'cone' search. For a number of instruments, however, one still has to work out by hand whether a given position on the sky is, or is not imaged onto the focal plane detector (focal plane detector not circular). In many cases, the answer to this question also depends on the instrument mode. We ask that the HEASARC study the feasibility of implementing the correct, detailed field of view associated with a given dataset when searching by position. We view this as an important issue, because the labor-intensiveness of working with cone searches really does inhibit important science.

3. With the new Browse by Keyword facility (which we all thought is a wonderful innovation), it would be very useful if the various mission keyword 'dialects' could be harmonized (i.e. for one mission, the relevant keyword may be EXPOSURE TIME, for another ELAPSED TIME; and if , for instance, you want to search and filter for observations of a position on the sky with a minimum exposure time, you have to run the Browse as many times as the number of dialects). Since a general database of keywords, with their meaning, already exists, we suggest that perhaps that could be put to use to help a user perform a Comprehensive Browse.

   We also suggest that the Browse Keyword search be integrated more prominently into the Browse page design.

4. We have serious concerns with respect to the coordination of software development for GLAST between the GLAST project and the HEASARC. Currently, the project-developed GLAST software already clashes with HEASARC standards, starting in some instances at incompatibility at the FITS format level. We urge the HEASARC to coordinate with the GLAST project to remedy the current problems, and to prevent further divergence. We have also asked the HUG member who is on the GLAST Users Group to voice our concerns in that environment, too, and to impress upon the other GLAST UG members and the GLAST project that issues such as these can noticeably hurt the scientific productivity and success of a mission.

5. We have detailed responses to Keith Arnaud's XSPEC status presentation: We would strongly support the development of joint spatial/spectral analysis capability, and give it higher priority than most other major innovations in Xspec (example of a non-'luxury' application: multiple sources in a single GLAST field of view). We would urge that Xspec/Sherpa compatibility be maintained throughout. The single most important resource embedded within Xspec (because it is unique) is the library of model spectra routines. We strongly suggest that the 'independence' of the library be maintained, such that it can or could be put to use also in other, user-designed software environments. We would like to see a Python or S-Lang interface (whichever has the most support).

6. HEASARC website design: we don't have a unique or unanimous response to the question 'Is the design satisfactory, and could or should it be changed, and if so, how?' Some members would prefer to see the non-'professional' entry more clearly marked, maybe with a separate page (which we professionals can then bypass) along the lines of the Chandra X-ray Center site design; others felt that the HEASARC has a different mission and should have an appropriately professional home page, with a clearly marked emergency exit for non-professionals. Some of us also feel that the page is unnecessarily cluttered, and suggest breaking up the home page into a top-level page sitting on top of more detailed pages. But since a significant fraction of us feel that the page is satisfactory, we suggest that we carefully review changes (if any) before the old page is discarded.

   We do suggest that the site could have a 'higher ed' link, in addition to the E/PO material, where lectures, presentations, and reviews could be stored, for use in professional talks and reviews, as well as astronomy and physics classes.

7. PIMMS: it would be very helpful if the PIMMS output listed all parameters of the model spectrum it uses, not just a selection (for instance, one frequently wants to know what the normalization constant of the model is, for use in Xspec).

Specific Archives:

1. GLAST: we have already noted the concerns with respect to the software development diverging from HEASARC compatibility.

2. Swift: we wondered when the BAT source catalog will become available. The HUG encourages the Swift team to produce this very useful catalog in a timely fashion. We also suggest that the HEASARC consider the feasibility of a GRB Followup Archive (currently, whatever optical followup data is publicly available is widely dispersed and possibly not always maintained).

3. XMM: The HUG reiterates its concerns that the XMM analysis software operates outside the CALDB infrastructure, and it urges the HEASARC, in its contacts with the XMM project, to continue to advocate that the XMM calibration data and software be brought into this structure.

   Steve Snowden's work on the synthetic background for the MOS, for use in the analysis of extended sources, is much appreciated, and its completion (and possible extension?) should have high priority.

4. RXTE: We suggest making a new high-end product for the RXTE GoodXenon data sets. This product would be a 'sensible' Event file that incorporats the sub-intervals and pieces of the GoodXenon data for an OBS_ID by using MAKE_SE to merge the GoodXenon data pairs obtained from the two EAs for each data interval of the OBS_ID, AND'ing a nominal GTI extension generated by running XTEFILT and MAKETIME, and merging all the sub-intervals. These steps are necessary to start most all analysis and will produce an event file that is immediately useful and available for further processing/analysis.

(Appendix to this item:

Specifically, we suggest the following steps to produce this new Event file:

For each PCA FS37/8 data file pair:

1. Run XTEFILT using the nominal applist to generate a HK file,
2. Run MAKETIME to generate a MakeTime file,
3. Use MAKE_SE to merge the GoodXenon data to get the new Event File,
4. Run FSORT to make sure the merged file is time ordered.
5. Filter the new Event File using the MakeTime file,
6. Use MGTIME to make a new GTI file by AND'ing MakteTime and Filtered times,
7. Clear out extraneous GTI extensions and append new GTI file ("EXTNAME=GTI"),
8. Add the OBS_ID keyword to all extensions.

Then make the final Event File for this OBS_ID by FMERGE'ing the EVENT and GTI extensions of the event_gxN files, appending the combined GTI with the combined EVENT file. Rename the result by the OBS_ID number (e.g., 90079-03-01-00.fits).

This will produce, for each OBS_ID, a time-ordered, EA merged, and filtered event file with an appropriate GTI extension for further analysis.)