You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Science tool development directions

This page was started 31 October 2006

Inquiring minds would like to know what directions the science tools will take over the year remaining before launch (or the ~2 years before tools are delivered to guest investigators). The science tools in question are those that will be part of the standard set that will be made available to guest investigators. The idea is to define what is needed and what is desirable, and what fits within the time/person-power constraints.

In the near term feedback from the GUC beta test will undoubtedly influence development work, although I'm not forecasting any major overhauls.

Likelihood analysis

Some standard topics come to mind, pointed observations being one of them.

GRB analysis

Is the current complement of tools complete?

Pulsar analysis

From Masa: "In the pulsar tools area, the major works are:
1) to implement blind search tool (A4 tool),
2) to create a new tool to plot a pulse profile (w/ periodicity test results),
3) and to introduce a method that contains the full functionality of the tool, so that a software developer (or a Python script) can call it as a part of their software."
[He has updated the current status page for pulsar tools with these items, including some more details.]

"Another major task is to develop a system to ingest and distribute pulsar ephemerides database. Other than that, we have several minor improvements in mind, such as, improving gtephcomp output, implementing more time systems, and technical refactoring for easy maintenance."

Observation simulation

Will an orbit/attitude simulator with at least semi-realistic attitude profiles/knowledge of constraints really be part of the SAE? Should we assume that pointing history files will be made available (or generated on request) for various scenarios?

Are any important source types missing? Is simulating residual background at the gtobssim level important, and is it feasible?

Infrastructure

GUI(s)?

Utilities

In the past, I've argued that we need a utility in the SAE for examining/displaying the IRFs.

Question: Did anyone else try out the event display tool during DC2? It was impressive and fun to play with, but I didn't need it.

Other issues

Delivery of science tools to the GSSC

In terms of delivery, a long time ago the SSC-LAT working group, or whatever we called ourselves, declared that it would be the group that decided when a given tool was 'ready' for delivery. I think that we probably don't need to re-convene the group, but I'd like your opinions about whether the tools should pass some not-yet-written battery of tests beyond the unit tests for the packages before they are accepted. And whether, during the mission the GSSC will be issuing incremental releases of the SAE tools at the same rate that the LAT team 'delivers' them.

Real life

I think that Jim has generalized the IRF look up to allow for time dependence of the IRFs. I don't know how likely we are to need to have response functions be time dependent - e.g., owing to something like a hardware failure - but at least in principle we could want to make analyses (with Likelihood or gtrspgen) that span these changes. The only obvious problem would be with live time cubes.

Also, we'll need to figure out how we'll really assign ID numbers to events.

Live time and pointing history

The 'accumulated livetime since start of mission' is looking quite difficult to obtain - at one time it was going to be easy. I think that the need for it is sufficiently small that we should consider omitting it from the FT1 file.
The FT2 file will need to continue to have accumulated live times for each interval of time, for exposure calculations. The attitude and position information that we'll get from the spacecraft, and will want to use for L1 processing, are not in anything like FT2 format - among the differences are the frequency of updates (much greater), the use of quaternions, the availability of angular velocities, and the asynchronicity of the attitude and position information. Do we want to change the FT2 format to more closely relate to what comes in the telemetry?

  • No labels