S. Digel, 19 April 2006
Here are some notes to spur discussion about the direction of science tools development work from here.
At SLAC the focus in the ISOC right now is on the definition of the various databases needed for monitoring the LAT and processing LAT data. More than you might think are needed. The Astro Data Server is not in active development; I think that questions about scalability may remain, e.g., whether reindexing at each downlink will be practical.
How about at the GSSC? What about the 'full' event data?
Several potential topics come to mind, not all of which are necessarily relevant. We need to figure out how we are going to tell people to interpret TS values in terms of significances for any given parameter of a model (the prime example being the source flux). I suspect that we won't have a general prescription for this - one that works for all models.
We need a workable way of defining source location regions using likelihood analysis. The problem has been (and will remain) that moving source positions also means that very little precomputation can be done to speed up the evaluation of the likelihood function. So this work most likely will need to be related to figuring out speed/accuracy tradeoffs for various approximations that could be made.
We'll need to figure out how to include cuts on zenith angle in likelihood analyses. I finally realized that we are effectively already making cuts on zenith angle in the DC2 event data. If you look at the DC2 data you'll see that the maximum zenith angle for any class A or class B event is 99.9996°. You might speculate that this looks like we are already cutting at 100°. I'm sure that this is spelled out in the cut specifications, but I hadn't noticed before; of course, cutting on zenith angle is the only way to remove albedo gamma rays. (The actual horizon is ~>110°.)
The exposure calculations and likelihood function evaluations currently do not allow for zenith angle limits. If the LAT were never rocked over by more than 35° then 100° would already be 65° off axis and therefore not extremely important in terms of usable LAT response, but for DC2 the LAT pointing direction sometimes strays far more than 35° from the zenith. For most DC2 analyses I would not characterize the exposure and likelihood calculations as wrong enough to be a worry but I can't say that they are 100% right either. I haven't checked quantitatively; the larger the zenith angle of the pointing direction the greater the potential impact, of course. For the pointed observations that we will simulate someday, the earth avoidance maneuver has the LAT scanning in constant zenith angle, presumably potentially larger than 35°, while the target is behind the earth.
Source detection tool - I think this will be a useful addition to the SAE. Some potential algorithms were described at the DC2 kickoff workshop. Jean and David have applied one (MRfilter) in the catalog pipeline for DC2. For that application, sensitivity is a more important consideration than, say, the false positive rate. For the SAE that might not be the case. Anyway, we should know more about how the algorithms (in their various tunings) compare after DC2.
What is coming up after GRB localization tool? GRB trigger tool? Temporal-spectral modeling?
Masa and James will want to finish up their work on allowing a variety of time systems for timing parameters.
I think that a Pulsar periodicity search tool is back on the list, something with simple, fast, sensitive [?] algorithms. For a couple of reasons, including fairness to the GSSC scientists, I had not been in favor of proceeding with this tool, but I think that the fairness issues have been resolved.
Would this be part of the SAE? I don't see why not, for what good it would do GIs.
Max has plans for more realistic pulsar simulations - at the level of including glitches - and I think also binaries.
What else do we need that we don't have?
We need an realistic Orbit/attitude simulator - and one by Guiseppe Romeo is coming along. The tool ideally would have appropriate adjustable parameters for the attitude, and capability to a write realistic FT2 file (with SAA entry/exit noted).
Rationalizing parameter names and prompts - how are we doing?
Overall GUI interface and plotting, perennially.
Anything else?
According to my count, we are in build cycle 16, which will end on April 28. I'd be interested in getting back to defining and tracking goals for each cycle when DC2 is no longer the focus. I'm sure that James has not stopped doing this. I can't say that I have a good idea right now when DC3 will be, or entirely what the scope will be, but for certain the science tools will need to be what we imagine needing for flight data.