Checkout1 Pulsar analysis

I agreee with Seth about pulsePhase. Also the prompt
How will timing model be specified? (FREQ, PER) [] :
doesn't accept lower-case input. If the default input ("") is given, it doesn't seem to realize
that this is unacceptable. It should re-prompt.
The prompt
Enter value of epoch of timing model 0 :
doesn't tell what units used for the epoch. MJD? Seconds since 1970?

Why is it that pulsePhase will work with either period or frequency, but stpsearch works only with frequency?

Is there some way to print or save an image of the histogram produced by stpsearch? I have clicked all over the window. It shows lots of options for modifying the plot, but I don't see anything for printing or saving.

The design of the histogram produced by stpsearch needs some work.

The box in the upper right corner is useless. The Mean and RMS are meaningless in this context. There's a tiny, illegible copy of the results. The only useful piece of information is Entries, which should be accompanied by the step size.

The frequency of the peak is specified in the results bar at the top, but the abscissa is in delta frequency. There's no way to link the two. The central frequency isn't specified anywhere. In fact, there's no way to know whether the abscissa is frequency or period.

The results bar says "Z2n Test" when something like "Z4 test" would be more useful. By the way, why is it 2n? Why aren't odd numbers allowed?

The font on the abscissa labels is too big. Often the various numbers overlap and become unreadable.

A note about Glbary:
I think that the user should be asked to enter the coordinates of the source not only in RA,Dec, but also in l,b. This because for example the source of Theodore are based on a lat,long system (as seems from the header of the txt file). For example a prompt for choosing what kind of coordinate system you want to use.

About PulsePhase I agree with Seth and Pat.
Which are the units for the epoch you have to enter in PulsePhase? MJD?
Do you think that can be useful to store the phase in a output file different from the input one? Or It's Ok to use the same fille and to overwrite it?

A note on Z2n test.
An integer "n" for Z2n test can be odd. What we (try to) mean by "2" in Z2n is "squared," in other words, Z2n should look like Z^2_n in the LaTeX math mode. I think it originally means "Z squared of the n-th order" or something like that. See Buccheri et al. 1983, A&A 128, 245 for more information.

About units of "epoch" to give pulsePhase.
For the current version, a value of "epoch" should be in the same unit (and in the same time system) as values in TIME column in an event file (FT1), because internally pulsePhase subtracts a value of "epoch" from values in TIME column without any conversion.

so, I put a few lines here follwoing a discussion with Seth. I dont know if it gets us anywhere closer:
Anything that obsSim simulates has a timing in seconds relative to the following GLAST start time: 2005-07-18T00:00:00.0000 . This is hardcoded in flux or astro (I would have to check). Now, if I take vela.txt in flux/vXrXpX/sources directory, which is used to create the vela-galactic source from GalPulsar spectrum class, I see that a T_zero is defined as: 51595.370251 . Seth's understanding is that this value is an MJD time when the phase of Vela was 0.
Then, given Masaharu's commment above, the value to be input when PulsePhase asks for epoch would be this 51595.370251 transformed so as to be in seconds relative to 2005-07-18T00:00:00.0000 (and could become negative obviously.)

If somebody knows how to do this computation, I would like to learn. Also I guess that the astro package has all the classes necessary to write such a small calculator program....

(21-oct2004) - Problem with simple lightCurve

Before to perform more complicated issues, I've tried to see if I can simulate a very simple lightcurve and then recover it after Glbary and pulsePhase.
This is because I'd like to study more in detail the baricentric corrections and the phase assigment before to go to the period search.

So I've decided to use the PulsarTemplate, and I make this tag:

<source name="PSRMuroTemplChiang">
<spectrum escale="MeV">
<SpectrumClass name="Pulsar" params="15.4,2.19,0.1,0.0,0,MuroTemplate.dat"/>
<celestial_dir ra="50" dec="20"/>
</spectrum>
</source>

If I well undestood the parameters in the source, I create a fake pulsar (Muro means "wall" in italian, because of the elementary shape of the profile).
The flux source is 100 times the Crab, has 0.1 sec of period, no Pdot, ant the t0 is choosen to be 0. the Phase at t0 is also 0.
This is the shape of the profile:
http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/MuroTemplate.gif

As you see is very simple and elementary.
Then I've performed the baricentric corrections, where I inserted the position of the source (RA and Dec), and then I've performed the pulseShape, where I inserted the values I used in the template (of course, for sake of semplicity I've set the parameters in the XML = 0.0 where possible)
I would expect a wall-shaped light curve, but I obtain this one:
http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/MuroPhase.gif
Completely different.

Can anyone tell me where I'm wrong? something in the declaration of the template source? or in the position in Glbary?
Someone has tried the same experiment?

I'm using the release STv5r1p1

Massimiliano

Massimiliano:

This looks familiar. I fell into this too. When you use <SpectrumClass name=Pulsar"> the event times are already "corrected" for barycenter effects. Don't use glbary.

Actually it is difficult to produce "uncorrected" times. It requires some difficult computation. Some people are doing it, but I don't know the details.

Johann:

From the EGRET days we have a little utility that does time and coordinate coversions. It tells me that this T_zero is 02/21/2000 08:53:09.686.

Massimiliano, The source you are using does not apply the barycenter "decorrection", so one should not apply glbary to the data you have generated. Please see Pat Nolan's JIRA post:

http://jira.slac.stanford.edu/browse/PULS-12

I've used this source and epoch folded the resulting events and have recovered the light curve I expect. Please try again, without glbary.

Thanks for the suggestion, in fact I try without glbary and It seems to be fine. But there's another thing I would like to know:

I used the XML source I described before, adn I used pulsePhase with this output:
#######################
razzano@pcglast27 STwork$ ../pulsePhase/v0r1p3/rh9_gcc32/pulsePhase.exe
Name of the input file Muro_noBg10ksec_events_0000.fits :
How will timing model be specified? (FREQ, PER) PER :
Enter value of epoch of timing model 0 :
Enter base value of phase at this epoch 0 :
Enter pulse period at this epoch 0.1 :
Enter first time derivative of pulse period (pdot) at this epoch 0 :
Enter second time derivative of pulse period (p2dot) at this epoch 0 :
####################

I've found the profile that is very similar to the original template, but not exaclty equal. In fat I've noticed some "background" of counts. Of course this background is very small (the main peak has about 730 count), so it 's a small effect.

This is a zoom of the profile I've found:

http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/MuroPulseRecovered.gif

P.S> - I used astroROOT to convert from FITS to ROOT tree, what I can manage with some macro. But the bg still exiist in the FITS file too.

It's this background a normal effect? Has anyone already found that?

Massimiliano, Thanks for pointing this out. I suspect that the algorithms for assigning phases in the Pulsar source and in the pulsePhase application are not quite compatible. In principle, the recovered light curve should be perfectly consistent with the input light curve. I'll have a look at both implementations to see if there is a bug somewhere. Since you have set pdot=0 in the input to the Pulsar source, you should be able to epoch fold the events at the 0.1 s period directly, without having to use pulsePhase. Could you try that to see if you still get the "background" events?

I have been having trouble with stpsearch and obsSim. Some of you may have noticed my abortive attempts to add comments yesterday. I have found a serious problem, which probably a bug in stpsearch. I will make a JIRA issue of this too.

I think stpsearch is getting the sign of the frequency derivative wrong. Pulsars have positive Pdot, so fdot (= -Pdot/P^2) must be negative. When I put positive values of fdot into stpsearch, I get good power spectra with sharp peaks at the right frequency. With negative fdot values the results are worse. The Crab data, with a fairly small fdot, produces a recognizable power spectrum shifted from the correct frequency. Vela, with a larger fdot, produces garbage.

As far as I can tell, stpsearch uses the pulsePhase::TimingModel class for encapsulating the ephemeris data for any given pulsar. Therefore, I would have expected the phase assignments from the pulsePhase application to suffer from the same problem Pat describes. This does not seem to be the case. I ran pulsePhase for a Crab_Pulsar sim, with appropriate P, Pdot (both positive) and also for the corresponding f, fdot (f >0, fdot<0) and recovered the Crab light curve I expected in both cases.

As suggested, I've tried to apply a simple folding to the file generated by the Pulsar Template.
I used the same sources as before, and I apply this very simple algorithm:

phaseEv = ((timeEv - int(timeEv/Period)*Period)/Period);

where timeEv is the time of the photon, phaseEv the phase estimated and Period here 0.1.
I've found exactly the same results as before:

http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/MuroSimpleFold.gif

In order to be more sure, I plot the differences in this case and by the folding using pulsePhase,and this difference is constant equal to 0.
The files FITS and ROOT you can see at this URL, all the files used are with the prefix MuroPT_noBg10ksec
in http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/

I've performed the same exercise and find similar results. I've had a look at the algorithm in the Pulsar class and see no obvious problems. Massimiliano: Would it be possible to perform a similar exercise with your PulsarSpectrum source?

I performed the exercise after some modifications to PulsarSpectrum, and I've obtained no background events.
I've continued to check the phase assignment (in case of Pdot and t0 different from 0) with your template. In fact I've found some errors by applying pulsePhase to Pulsarspectrum with pDot and so I think your template is more reliable for investigating the Dot and t0 stuff.
I've reported here the results of this first exercise with pulsePhase:
http://www.pi.infn.it/~razzano/Pulsar/STCheckout1/pPhaseExerc1/pPhaseExerc1.htm