Hi Dave & Jonathan,
Thanks for discussing these ARF issues -- this is a good example of the
usefulness of the chandra-users mechanism! (Someday maybe there will be a
Chandra news group which provides for threaded discussions.)
> I think mkarf is the tool Pat is looking for, but perhaps didn't know
> that it averaged over the aspect.
> I think that the calcarf program from the swap page is what you want
I appreciate very much both your suggestions, but I think I perhaps didn't
communicate my problem clearly. I'm pretty sure I understand what mkarf does,
and I use it in my recipe. My need to sum & average ARF's produced by mkarf
comes from two considerations:
* For point sources which span multiple CCD's (due to dither) one must of
course run mkarf for each CCD. If one chooses to combine the event data and
perform a single spectral fit (e.g. for very faint sources) then one must SUM
the two ARFs to get the correct sec*cm^2. dmarfadd will be applicable here
when the keyword errors are fixed. I'm currently using an addarf (an FTOOL).
A useful upgrade to mkarf might be to have it figure out for itself which
CCD's contribute to a given sky position and produce N ARFs.
* When generating an ARF for any single CCD, if the sky position you specify
falls on a part of that CCD's exposure map that is changing rapidly on spatial
scales comparable to your source extraction radius (e.g. 10's of pixels) then
a paranoid observer might not be satisfied with sampling the "shoulder" of the
"exposure map" at a single (dithered) point when the extraction region is a
big circle. For example, one could theoretically have a fat off-axis point
source whose sky position never actually touches CCDn, even though lots of its
photons fell on CCDn. In that case the ARFn would be zero. Maybe it all
comes out in the wash, but my intuition is to cover the extraction region
(circle) with a bunch of ARF's and then average them (a crude form of
integration). I'm currently using addarf to perform this average.
I realize that one really wants to integrate the source's actual spatial
distribution over the sec*cm^2 surface (rather than my crude technique of
"integrating" with a flat disk corresponding to the extraction region), but
that's too hard for me.
I've briefly looked over the calcarf package. It seems just right for big
extended sources that fall within the bounds of one CCD. However I don't see
how it could deal with point sources falling in chip gaps since as far as I
can tell it doesn't know anything about aspect (i.e. it can't know how long my
source spent in the gap seeing zero effective area). If I've misunderstood
the package please set me straight.
In case you're interested, I attach below a Perl script that performs the ARF
averaging over an extraction circle, and the ARF summing for multiple CCD's
for a source list as described above.
I welcome more discussion of this topic, especially wise voices which point
out places where people (like me for instance) are picking theoretical nits
that don't actually matter. It's all to tempting for engineers like myself to
fixate on theoretical flaws in a recipe that actually are way down in the list
of error sources.
Patrick S. Broos, Systems Analyst/Programmer firstname.lastname@example.org
Department of Astronomy and Astrophysics My office 814-863-7947
Penn State University
525 Davey Lab FAX 814-863-8686
University Park, PA 16802-6305
http://www.astro.psu.edu Group office 863-9550
This archive was generated by hypermail 2b29 : Wed Jun 19 2013 - 01:00:02 EDT