Introduction

The Bordeaux group has been exercising the pulsar-related Science Tools using real and simulated data, with two goals: 1) to hunt for bugs and/or get acquainted with "features", 2) to become expert at the subtleties of pulsar timing, to help us with our twin tasks of a) centralizing the radio and X-ray timing efforts into a D4.fits ephemerides database to be used by the LAT collaboration, and b) to get a head start on the arcania we need to know to effectively phase-stack gamma photons after launch.

 We have presented our work as we've gone along. Two milestones:

In March 2007 we met with Masa, James P, et al at GSFC, which resulted in        https://jira.slac.stanford.edu/browse/PULS-31

In November 2007 we presented an update at the Collaboration Meeting at NRL, see  https://confluence.slac.stanford.edu/download/attachments/39850/LG_EphemLightCurves.pdf?version=1 

Specifically, slide 5 of the latter is called "Limitations of the Science Tools" and evokes the concept of "expert mode" that is, trickier analyses where experienced users may be tempted to extract lists of dates from the LAT data, leave the Science Tools environment, perform their analyses with tools such as TEMPO, to then perhaps return to the Science Tools to use e.g.  gtlikelihood for phase resolved spectroscopy, etc.  

The conceptual progress we've made comes from intense discussions with the radio astronomers (see for example "Report on timing discussions with S. Johnson, M. Kramer, and I. Cognard"  at the 30 October 2007 Pulsar group meeting, https://confluence.slac.stanford.edu/pages/viewpage.action?pageId=27719 ) and from the studies we've done using Giant Radio Pulses and  XMM data on a binary pulsar (see this work by Lucas).

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:

• Many more variables in TEMPO than in D4. We clearly don't want all of them, but a few more (several?) could be worth adding. At NRL, David Band and Tom Stephens seemed to feel that D4 could in any case store all the variables that the radio and X-ray people send in TEMPO and TEMPO2 .par files even if the Science Tools don't use all of them. Presently, Bordeaux is building an archive with a web-based interface to make all the .par file contents available, in addition to building custom D4's. See A Web-based D4 creatorby Lucas at the 27 November pulsar meeting. The archive will further contain the timing templates used by the radio people when creating timing solutions -- this is related to the phase reference time (JIRA-34). Amongst things to perhaps add to D4:

1. "Binary orbital parameters" is already being addressed in JIRA-33.
2. "Position epoch & proper motion" was raised (partically?) in JIRA-36 which Masa closed with a "won't fix". We'd like to beat this horse a little more ==> see below.
3. "More than just f0, f1, f2 for the rotational parameters" ==> see below.
4. Glitch parameters.

Supposing that you add stuff to D4 -- what gt-tools changes might you want to make to actually use the new variables?

• POSEPOCH  Some pulsars have had their positions measured using interferometers. Not only is the position then more accurate than that obtained by a timing solution, but you have one less free parameter in the timing solution. This is why some pulsars have POSEPOCH (when the position measurement was made) different from the epoch of the rotation parameters. In the case of GRPs from PSR B1937+21, POSEPOCH was linked to the proper motion measurement. But gtbary doesn't use POSEPOCH which doesn't exist in D4. So Lucas copied 5 lines from the TEMPO code that handle this into a local copy of gtbary in order to get the right light curve out. We think that the pain-to-gain ratio for this is very low.

• 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 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.

• • It would be good if gtpphase users were, at a minimum, alerted to the fact that a glitch occured during the time span of the gamma rays being processed. We suggest that the TEMPO glitch flags be read from D4 and a message printed by the code. The user could then decide to shift into "expert mode", that is, phase-stack the gammas using TEMPO instead of gtpphase.
  • The rotation parameters immediately after (and before?) the glitch will be weird. You'll want to change lines in the D4 file. Watching a pulsar just when it glitches is a very rare thing, and GLAST survey mode "seeing all things all the time" means we'll catch some, including on Vela which is gamma bright enough that we may see something happen.

• • In real life -- we'll know weeks or months after the LAT data is recorded that the radio folks saw a glitch. We'll then want to come back and analyse carefully the gammas around the glitch time. Perhaps this is an example of when "expert mode" should be applied.

Summary

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.