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

Compare with Current View Page History

« Previous Version 8 Next »

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.

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 the few 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. (caveat -- dave is writing this while lucas is out of the office, I may have gotten some details wrong, but not the gist. Lucas when you read this please correct, and remove this parenthesis.)
  • 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) 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 Parkes, 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)).

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

 

  • No labels