CXC response to CUC Recommendations following 2006 Oct CUC Meeting
> (1) Optional chips: The CUC fully supports the reasons behind the
> implementation of optional ACIS chips but fears that the wider
> user community might not be aware of the utility of this step. We
> recommend that a short web-page describing how thermal constraints
> are relaxed by turning off a small number of chips be linked to
> appropriately, especially to pages used in the detailed planning
> of observations.
>
> The proposed web page should also explain that a compromise has to
> be made between turning off CCDs and splitting observations. The
> web page should describe the current policy: observations that do
> not explicitly ask for un-interrupted scheduling can be split by
> Mission Planning team without further check with the
> PI. Observations explicitly asking for un-interrupted exposure
> will be considered time-constrained and hence limited by the 15
> per cent maximum constrained time that can be approved.
ACIS Ops will create the content for this web page.
CDO is writing a Proposal Thread for optional chips.
This thread will have links to the relevant section in the
POG and to the ACIS Optional chips Web Page.
The latter page will be standalone, analogous to the
page on New Pitch Angle Restrictions
http://cxc.harvard.edu/cdo/pitch_angle.html
> (2) Internal and external cross calibrations: The CUC is very pleased
> by all of the ongoing calibration and cross-calibration efforts,
> and especially encourage further participations in IACHEC and
> cross-calibration efforts with Suzaku. However, the CUC has two
> specific concerns and questions in this regards:
>
> (a) There has been very little discussion about cross-calibration
> across the Chandra instruments, e.g., between the bare ACIS-S,
> bare ACIS-I, ACIS-S/HETG and HRC/LETG. It remains unclear to
> what extent this internal cross-calibration is naturally
> achieved through the regular calibration efforts. The CUC
> requests an explicit update about internal Chandra
> cross-calibration. While the CUC acknowledges that it is
> challenging to find potential sources, it also recommends
> examining the cross-calibration of ACIS grating spectra with
> the spectrum of the zero-th order image.
>
Cross-calibration between Chandra instruments was among of the first
tasks undertaken by the Calibration group. Some of this work may not
be familiar to the current CUC because much of the work occurred
within the first two years of Chandra flight operations. The current
effective areas for the Chandra instruments have been updated as
needed based on such comparisons as described below:
1- Upon comparing LETG/HRC and LETG/ACIS, the ACIS contaminant was
discovered. It was found to be time- and spatially-dependent by
internal checks of extended sources and using the external cal source
that is observed regularly. The contaminant correction is regularly
checked against flight data.
2- Using HETG/ACIS data, the BI and FI chips were cross-checked,
finding an anomaly affecting energies below 1 keV that was later
corrected using ground calibration data. Furthermore, we also
uncovered a systematic error in the FI calibration relative to the BI
that results from cosmic ray blooms. These corrections have been
verified using ACIS-I and ACIS-S observations of A 1795, giving us a
great degree of confidence in the relative calibrations of the FI and
BI chips and, in practice, between ACIS-I and ACIS-S.
3- Comparing bare ACIS-I to ACIS-S is done with extended sources (to
avoid variability, for one) but requires accounting for spatially
dependent gain and contamination corrections, which are tested and
verified with LETG/ACIS observations and external cal source data.
4- Early observations with HETGS and LETG/ACIS were used to make
adjustments to the LETG/HRC effective area.
5- Standard HETGS observations have been used to determine the HRMA
contaminant thickness, which improves all Chandra effective areas.
6- ACIS QE uniformity maps, which account for grade migration, were
developed from external cal source data to improve the cross-
calibration of ACIS-S and ACIS-I.
> (b) The CUC notes that essentially all of the cross-calibration
> efforts between Chandra and XMM or Suzaku is conducted using
> Chandra in a grating mode. While we acknowledge that it is
> technically easier (given pile-up issues), it is highly
> desirable to also cross-calibrate bare ACIS modes. If they are
> not doing so already, the CUC recommends that the
> cross-calibration team include bare ACIS modes in their
> consideration.
Related work that is planned includes:
1- Comparing HETGS and ACIS-S observations of 1ES 0102 -- supporting
ACIS effective area and response function verification and cross-
calibration with XMM (which also addresses item 2b).
2- Comparing HETGS 0th order spectra to HETGS +/-1 order spectra --
providing a verification of the HETGS 0th order efficiency more than
a check of the ACIS effective area, complicated by pileup for bright
sources and CTI calibration when using readout streak data.
3- Continuing with analysis of last year's observations of PKS
2155-304 where the LETG was used with both ACIS and HRC and the HETG
was used -- providing a verification of grating effective areas.
4- Revisiting the contaminant spectral model, with an eye toward a
possible time-dependent composition model.
All of these efforts will be presented in more detail at the next CUC
meeting and summarized on a new web page. The web page will mostly
provide a series of links to the existing analyses but will also
provide updates from ongoing work and a summary of the quality of the
relative calibrations. Some of this information is already contained
in pages linked to the main CAL page http://asc.harvard.edu/cal/
or to pages for individual instruments.
> (4) CHIPS rewrite: The CUC is somewhat concerned about the level of
> effort that is being expended in rewriting CHIPS given that CHIPS
> appears not be to crucial to other on-going activities (such as
> the catalog) and it is unclear to the degree that CHIPS is used by
> the community. The CUC makes the following requests and
> recommendations:
>
> (a) We request that, at the next CUC meeting, we are given a clear
> description of why it is important to update/rewrite CHIPS and
> where (and how) CXC sees CHIPS eventually developing. As part
> of this discussion, it will be important to identify other high
> priorities activities for which CHIPS is an important tool.
>
As for Sherpa, infrastructure issues and software
licensing/copyright issues associated with the old code were
significant drivers for the rewrite of ChIPS. In order to ensure that
CIAO complies with the license requirements of a number of GNU Public
Licensed (GPL) off-the-shelf packages that CIAO uses extensively,
these legal issues had to be resolved. The two major areas that had
to be addressed were the use of SM in the old ChIPS, and Numerical
Recipes code in the old Sherpa. Sherpa will retain the ability to fit
images, and fully operate in double precision (both in contrast to
XSPEC capabilities). With the ChIPS and Sherpa rewrites, future
versions of CIAO will be able to be released under the GPL.
As for the activities for which ChIPS is an important tool, the ChIPS
plotting package is used in three major capacities - as the plotting
package for Sherpa (much in the same way PGPLOT, via QDP, is used in
XSPEC), as part of the standard pipeline (e.g., for validation and
verification), and as part of the Chandra catalog (i.e., Level 3).
Currently, only the first is noticeable to the average Chandra user on
a routine basis (and at that, only using the old version of ChIPS).
ChIPS will continue to be the main plotting package for Sherpa as both
are rewritten. At this point, development of ChIPS is less focused on
major infrastructure changes or additions, but rather on specific use
within the above three contexts. We expect that ChIPS will soon be
transitioning to a more minor mode of development/bug fixes through
routine use in these capacities. At the next CUC meeting, we hope to
show more mature examples of ChIPS use in each of the above
capacities.
>
> (b) The CUC is concerned about the direction in which the user
> interface for CHIPS and Sherpa is developing. We feel that it
> is important to make the interface as accessible and natural as
> possible to astronomers, not computer programmers. Forcing the
> user into an object-oriented environment is of particular
> concern - this is not a natural system for most astronomers
> with the result that few astronomers outside of CXC will use
> these tools. This, in turn, diminishes the value of the effort
> expended to update these tools.
Knowledge of object-oriented programming will not be a
requirement for using either ChIPS or Sherpa interactively or via
batch mode. Given that the basic libraries are written in C++, and
that the infrastructure is "stitched together" with Python, object
oriented programming is inherent in the design, and thus will be
available for advanced users. Our plans, however, are that the
average user will not need to be concerned with that fact. An
advanced user, however, can take advantage of those features should
they desire (just as an advanced XSPEC user can use Fortran to create
custom XSPEC models, although here advanced users will have even
greater ability to create custom code).
To the extent possible, S-lang, Python, and current command-line
interfaces will be made to look and act as much alike as possible.
(The examples shown at this past CUC meeting were identical whether
one was using the S-lang or Python interfaces to Sherpa.) The more
familiar (to astronomers) S-lang interfaces will be maintained. Our
own survey, conducted last spring, showed that there is still a large
segment of the astronomical community that is most comfortable with
and desire a simple command line interface to such packages. We do
not intend to abandon that segment of the community.
>
> (c) We recommend that the CXC identify and examine metrics
> that probe the penetration of CHIPS and Sherpa into the
> community. For example, searching the body of Chandra related
> papers for "Sherpa" and "XSPEC" will give some measure of the
> relative use of these packages. This exercise will inform CXC
> and CUC as to the degree of effort that should be put into
> CHIPS and Sherpa development.
The Science Data Systems group has performed a full-text literature
search of refereed journal articles (i.e., conference proceedings have
been excluded), searching for references to five major spectral
fitting packages: XSPEC, Sherpa, ISIS, SPEX, and PINTofALE. We were
careful to exclude unrelated duplicate names (i.e., there are other
software/instrument packages named ISIS and SPEX that are easily
excluded). The search is by year, starting in 2000. We have also
separated out the University of Chicago (UC) journals (ApJ, AJ, and
PASP), as the available search engines allow us more flexibility in
searching those, specifically to add in the "Chandra" keyword. Note
that this is a search for any mention of these keywords, and does not
specifically highlight which package was predominantly used. As such,
there is undoubtedly some "double counting" of references. Our
experience is that a paper that predominantly uses Sherpa, ISIS, SPEX,
or PINTofALE will often also mention XSPEC, whereas the converse is
typically not true. (A cursory examination of the papers also seems
to indicate that a large fraction of the SPEX references are for its
atomic database, rather than as a fitting package per se.) The results
are presented in a postscript file, fit_pack_stats.ps.
From 2000 through 2006, Sherpa accounts for some 12% of the total
references, and 14% of the UC journal references that also mention
Chandra. (Note: we have not determined for which of these Chandra was
the main instrument. A fair number of these references deal with
mutli-wavelength observations.) The peak use of Sherpa was 2004, with
16% of all references (and 17% of the UC journal references that
mention Chandra). Whether the downward trend in Sherpa use is real is
difficult to say, especially as the 2006 references are likely
incomplete. Sherpa use is predominantly associated with mentions of
Chandra; however, one of the major goals of the rewrite is to make
Sherpa easier to use for other missions, including non-X-ray missions.
We have not yet conducted a search for ChIPS, but suspect that it
would not add many more references. Each use of Sherpa implicitly
also uses ChIPS, whether it is referenced or not. (Likewise, we do
not expect to find many references to XSPEC that separately and
explicitly reference PGPLOT or QDP.) We are open to suggestions from
the CUC as to other useful metrics, and would be happy to discuss
these results at the next CUC meeting. SDS will also consider
methods to improve the dissemination and usage of CXC science tools
and report on these efforts at the next CUC meeting.
>
> (5) Catalog: The CUC continues to regard the Chandra Source Catalog as
> an extremely important part of Chandra's scientific contribution.
> The rapid community utilization of the XMM point source catalog
> highlights the need for Chandra to produce its catalog on the most
> rapid timescale possible. If it hasn't been done so already, the
> CUC requests that a real schedule with goals and deadlines be
> established for the development of the catalog. We also request
> that the latest version of the requirements document be made
> available to the committee members.
>
A version of the Requirements Document will be made available
to the CUC by February 1. This version will incorporate the
necessary additions and revisions that will clarify the requirements
and eliminate confusion present in the current version of the
document.
The Chandra Source Catalog is being developed as fast as possible
consistent with producing a reliable, robust, and well-characterized
product for the user community. The Beowulf cluster hardware needed
for processing has recently been upgraded, and appears to be stable.
Of order 60 observations have been processed through the prototype
source detection and per-source pipelines, and the results are
providing feedback to improve the pipeline operations and scientific
integrity. Scientific development of a new local background algorithm
- one of the major missing components for the source detection
pipeline - is nearing completion, and is expected to be incorporated
into the pipeline in the next few weeks. Within the past several
weeks the calibration team has provided a beta version of the SAOSAC
raytrace software that will run on the Beowulf cluster - which was
another major missing component. The first version of the science
requirements for the merge pipeline are being coded for testing. The
archive (file) infrastructure has been developed, and development of
the requirements for the catalog database and user interfaces is in
progress. Once the above work is done, we will be in a more realistic
place to lay out an updated schedule, for presentation at the next
(late April 2007) CUC meeting.
> (6) EPO proposals and activities: On the basis of community feedback,
> the CUC requests that the password distribution system for EPO
> proposals be improved. Distributing passwords via direct phone
> is both un-necessary use of CXC personnel and can delay a potential
> PI. We request that passwords be distributed via an automated
> email/web-based system.
>
> The committee also requests an update on EPO activities at the
> next CUC meeting.
>
We are reviewing and revising the EPO proposal submission software.
An automated password assignment capability will be incorporated for
Cycle 9.
>
> (8) Extremely Large Projects: The CUC is fully supportive of the
> Director's proposed plans with regards to ELPs. We also appreciate
> the cautious manner in which the Director is proceeding and fully
> support the call for white papers that was issued in early
> November. Specific recommendations of this committee are:
The Chandra Director's Office appreciates the thoughtful and
cooperative help of the CUC in discussing and developing the
parameters of a possible program for Extremely Large Projects,
as well as the call for white papers. The call for white papers
has been circulated through our Newsletter and Bulletin,
and posted on the Chandra website at
http://cxc.harvard.edu/proposer/elp.html
with a due date of Feb 1, 2007. The CDO will discuss the response
with the CUC.
