...
The purpose of this page is to detail for Masa, James, et al what the limitations are, make a list of modifications and/or additions to the pulsar Science Tools ordered by the pain-to-gain ratio of each item, to then be able to discuss with GSSC about what, if anything, should actually be changed.
Please note that Masa et al maintain a "pulsar tools do-list" at http://glast.gsfc.nasa.gov/ssc/dev/psr_tools/status.html .
A discussion on how to resolve bug and issue of the Tools 'gtpphase' and 'gtbary' is at: gtpphase & gtbary
The topics
In approximate order of increasing pain-to-gain:
...
- HIGHER ORDER ROTATIONAL PARAMETERS Masa's vision, as we understood it in March, is that no matter how complex a multi-year timing solution might be, it can always be broken down into piecewise phase-connected bits, for which f0, f1, and f2 suffice. The classic illustration of this is the monthly Crab ephemeris provided by Jodrell. What's wrong with this is that it is not necessarily what the radio and/or Xray timing people would most naturally provide to us. Some examples...
- The Jodrell Crab ephemeris is done by hand by Mark Roberts, a senior staff scientist who has been doing this for years. He takes a couple of hours each month to find a solution that is phase-connected to the previous months. This level of effort is unlikely to be made for a large number of young, noisy pulsars.
- What they more naturally do is use lots and lots of higher order coefficients to "whiten" the timing noise. Here are some fun examples --
- "Long-term Phase-coherent X-ray Timing of PSR B0540-69", Maggie Livingstone, Vicki Kaspi, Fotis Gavril in ApJ 633:1095-1100, (2005). Using ELEVEN (!) frequency derivatives they obtain timing residuals of +/- 15 ms from 1996 to 2003 for this 50 ms pulsar. They state (figure 4) that they needed so many to have residuals less than one-half period. It is a great gamma candidate and they (or John Marshall maybe, I don't remember) Frank Marshall will be providing us RXTE measurements after GLAST launch. How will we shoe-horn their 11 parameters into the D4 and gtpphase? We probably won't. We'll probably extract gamma times from the LAT data and do the analysis with TEMPO. Adding many higher order terms to the Taylor series expansion in gtpphase strikes Bordeaux as a small pain-to-gain issue.
- "The Magnetar XTE J1810-197: Variations in Torque, Radio Flux Density, and Pulse Profile Morphology", F. Camilo, I. Cognard, S. Ransom, et al in ApJ 663:497-504 (2007). Figure 1 is worth taking a look at --daily radio pulse profiles changing weirdly. Absolute phase coherence is critical for this study (as it is for the LAT). The caption says "eleven frequency derivatives". Speculation is rampant about whether or not GLAST will detect magnetars in gamma rays. To give it our best shot, we'll use the best long term ephemeris that the radio folks can build.
- "A Statistical Study of Pulsar Timing Irregularites Using Observations from Jodrell Bank Observatory", Hobbs, Lyne, and Kramer in MNRAS draft attached. They show how very weird pulsar spin down is, and how f0, f1, f2 just ain't enough over years and years. Check out their pages of residuals, they're neat.
- GLITCHES Recently we've been having a lot of fun in Bordeaux searching EGRET data for pulsations, for one really hot pulsar discovered recently at Parkes, and two very warm pulsars discovered about ten years ago at Nancay, that they never got around to publishing. For the latter, after ten years of timing, they have an accurate proper motion and a series of glitches.
- If gtbary doesn't handle proper motion, then that means that the multi-year timing solution provided by the timing people can't be used to stack gamma rays over a long period. We need to specifically ask them to provide piecewise, phase-coherent solutions. As a matter of fact... we did already ask them to do this, when Johnston was in Bordeaux and when we were in Manchester, and they said "yes". They took it as one more, reasonable task to do for us. In the case of Nancay, it's in any case Lucas who builds the timing solutions on the Nancay computers from the Nancay raw data, and so he builds them with the D4 & Science Tools limitations in mind. Oh but I was supposed to be talking about glitches not proper motion.
- Glitches are intrinsically interesting. Speculation abounds (wrongly, in our mind) that there could be "puffs" of gamma rays when one occurs.
...
There is nothing inherently wrong with Masa's concept of the pulsar science tools architecture and implementation. We have stacked Crab optical pulsar data over many epochs using the Jodrell monthly ephemerides that have only f0, f1, f2, and it works very nicely (ApJ 566 343-357 (2002)). An important element of the pulsar ST concept is that the user tailor his/her D4 file to the specific study being performed, which we have indeed done during ours studies. It works nicely, and it is a guiding principle in the conception of the A Web-based D4 creatormentioned above.
The "problems" (to the extent that there are any) are more on the side of the timing solutions that are going to be provided to us. Piece-wise phase-coherent ephemerides can be made, and the radio astronomers are even willing to make them for us, since in any case they'll be doing a lot of solutions specifically for us. However... they also already have a lot of high-quality timing solutions in hand, that they will continue to extend into the future, independent of GLAST. At present, Science Tools can't use those -- we have to get custom ephemerides made. To make them ourselves, you need access to the radio TOA's, which they share sparingly.
Furthermore -- if we understand correctly, gtpphase finds the best ephemeris for the whole file being analysed, and then applies it to all gammas in that file. If we're stacking photons downlink by downlink, that's fine. But in Bordeaux our tendancy has been to create a single large FT1 file for a given pulsar for a long integration time (e.g. 1 year Service Challenge simulation, et cetera) in which case you have the worst of both worlds, i.e. only 3 rotation parameters to cover a very long exposure time with a single ephemeris. We're unclear about what Standard Recommended Procedure is (sorry -- we didn't read your recent update of the Workbook, tell us if we should).
Feedback
Here are interesting reactions from Dave Thompson and Roger Romani:
Date: Tue, 04 Dec 2007 13:45:09 -0500
From: Dave Thompson <David.J.Thompson@nasa.gov>
To: D.A. Smith <smith@cenbg.in2p3.fr> Cc: Alice Harding <ahardingx@yahoo.com>, Roger W. Romani <rwr@astro.Stanford.EDU>
Subject: Re: limitations of pulsar science tools (fwd)
Hi David,
This issue was a lot easier on EGRET, when we had viewing periods.
The danger with a multi-year ephemeris, even with many fitting parameters, is that it may still have residuals that go unnoticed (and there is that pesky problem of possible changes in DM). One of the reasons that 1951+32 was the last pulsar to be found in the EGRET data was that we were trying for quite a while to use a single long-term ephemeris, and it just didn't do the job. Breaking up the data into pieces that match simple timing solutions may seem harder operationally, but it adds some confidence that the phase assigned to each photon is good. Once that is done, adding up the results is pretty simple. I'll go for a high-confidence result over an elegant one every time.
Dave Thompson
==================================
Date: Tue, 04 Dec 2007 16:02:21 -0800
From: Roger W. Romani <rwr@astro.stanford.edu>
To: D.A. Smith <smith@cenbg.in2p3.fr> Cc: rwr@astro.stanford.edu, ahardingx@yahoo.com, David.J.Thompson@nasa.gov, rwr@astro.stanford.edu
Subject: Re: limitations of pulsar science tools (fwd)
Hmmm -- I think that if we are going to have a robust science tool PSR environment, we need at least a bit of a wrapper code that takes each selected photon and grabs a default ephemeris from the D4 data base before computing the phase. If we use a simple critereon (e.g. TOA MJD furthest from the validity boundary of the chosen ephemeris, or chose ephemeris with smallest rms among those covering the TOA MJD), then we can make the existing tool general enough to be usable. Certainly all we need is a decent set of phases for any given photon set. Forcing high polynomial approximations to fit timing noise is NOT the way to go, though...
What do you think? If we want this, who writes it? -- Roger
====================================
Dave Smith comments: "wrapper code" assumes that nothing changes in the ST's, but probably the best technical solution is a modification of how the "best" ephemeris from the D4 for a given photon date is chosen, given that file start & stop times in general won't match ephemeris begin & end times. Before getting into "who" writes the code, let's get clear with the SSC about "what" is the right solution.
In any case, we have a consensus from the users' side that piecewise ephemerides is the way to go. So it seems that a change to gtephcomp's ephemeris selection algorithm may be what we need.
Even if we agree that in general and in most cases we'll want piecewise timing solutions, allow me to insist that the pain-to-gain of adding higher-order derivatives to both the D4 and to gtpphase etc is small. It's just some columns, and some higher-order terms in the Taylor series. We would then have the flexibility of using ST's with ephemerides found in the literature. The alternatives are a) to track down the author and convince him/her to re-generate 3-parameter timing solutions for the epochs that suit us, or b) extract the dates from the FT1 file and use TEMPO instead of ST's.
=========
Further exchanges lead Dave S to this summary:
The pulsar Science Tools in their present state work fine *IF* the user is careful to keep the data in separate FT1 files that are more or less matched to the validity periods of the D4 lines he/she uses.
In practice: Joe User goes to the GSSC Data Portal and enters ra,dec,tstart,tstop into the web interface (or other request mechanism).
If Joe User is pulsar-savvy, he'll have a list of (tstart,tstop) pairs that he got from the D4. He'll get one fits file per pair. Then he'll stack gamma phases nicely.
If Joe User is naive, he'll ask for tstart=launch and tstop=now, he'll get one fits file, ST will treat those many months of data with a single ephemeris, and he'll wonder why he sees no pulsations.