Polycos with Doppler shifts 0

[emmacarli]

Hello all,
I am generating polycos for a custom observatory. They are produced, but the Doppler shift due to Earth motion is 0 in each entry. This is the main effect I would like to correct for, to fold long observations with other software.

I have input my custom observatory in /PINT/src/pint/observatory/observatories.py as follows:
TopoObs('acre', aliases=['acreroad'], itrf_xyz =[3573741.1, -269156.74, 5258407.3], )

This is the Python script I used:

#%% Import packages
from pint import polycos, observatory, models
import astropy
import sys

#%% Start a log
log_handle = open('PINT_polycos_generator.log', 'w')

sys.stdout = log_handle
sys.stderr = log_handle

#%%Generate model
B032954_model = models.model_builder.get_model('B0329+54.par')
#this parameter file's data was obtained from ATNF

#%% Generate polycos
pl = polycos.Polycos() #initiate an empty polycos instance
pl.generate_polycos(model = B032954_model, mjdStart = 57969.1, mjdEnd = 57969.4, obs = 'acre', segLength = 5, ncoeff = 12, obsFreq = 407.5, method = 'TEMPO') #segment length in minutes, observing frequency in MHz, method TEMPO2 unavailable

#%% Write to TEMPO style polyco table (PRESTO uses these for folding)
pl.write_polyco_file(format='tempo', filename='PINT_polycos.dat')

This is an example of a set of polycos from PINT_polycos.dat :

J0332+543404-Aug-17 022630.00 57969.101736111109656 0.0 0.0 0.0
1390110980.94504384 1.399541538720 acre 5 12 407.5 0.0
-2.25647100421503604e-10 6.05368936507820563e-03 -1.82265915169433213e-08
-5.16412032720972806e-10 -1.29915760566270875e-10 3.98289910480010468e-10
6.39002894891700953e-11 -1.61703415153186620e-10 -1.19489570516592519e-11
2.82082280282038799e-11 7.22100001451911620e-13 -1.75994574970452220e-12

I believe pulsar name, date, UTC, MJD, 0 DM (dedispersed data) are correct; although the first two are not separated. Then there is 0 doppler shift and 0 fit residual (not sure if the latter is normal, either). Then reference phase, frequency, observatory, time span, number of coefficients, observing frequency and binary phase (single pulsar) seem all correct as well.

I can provide the contents of the log if needed.

Thank you!
Best,
Emma

Post-Scriptum: I also defined my observatory as follows, which yielded the same issue and did not save to observatories.py:

#%% Observatory definition 
acre_latitude = 55.902528 
acre_longitude = -4.307107 
acre_height = 50 #meters
acre_EarthLocation = astropy.coordinates.EarthLocation.from_geodetic(lon=acre_longitude, lat=acre_latitude, height=acre_height)
acre_itrs = acre_EarthLocation.get_itrs() 

observatory.topo_obs.TopoObs('acre', aliases=['AR', 'acreroad'], itrf_xyz = acre_itrs.data.xyz )

[luojing1211]

That looks like a bug to me. Thank you for reporting this. I will fix it as soon as possible.

[mcknightryan]

Just wanted to report that this bug is still occurring. I am using this script:

import pint
import pint.models
import pint.observatory
import pint.observatory.topo_obs
import pint.polycos

model = pint.models.get_model('0329+54.par')
obs = pint.observatory.topo_obs.TopoObs('ou', itrf_xyz=[669765.29,4903035.31,4010839.95])
polycos = pint.polycos.Polycos.generate_polycos(model, 59272, 59276, 'ou', 300, 12, 1400, progress=True)
polycos.write_polyco_file(format='tempo', filename='pint_polycos.dat')

Which results in the following output:

0332+5434  27-Feb-21       0.00   59272.00000000000            26.764100  0.000  0.000
           66.804038    1.399541538720   ou  300   12  1420.000
  1.87004501533953836e-07 -7.21712492598724966e-03  1.29610656577399389e-07
 -1.81255800549687827e-11 -2.03078521737154278e-13  1.75519496750249846e-17
  1.28698375694719245e-19 -1.02298132967174296e-23  2.80018202164220533e-26
  8.38782598612983693e-29 -1.58607722697604377e-30 -2.11376276751728109e-33
0332+5434  27-Feb-21   50000.00   59272.20833333334            26.764100  0.000  0.000
        25256.396261    1.399541538720   ou  300   12  1420.000
 -2.49553363999571171e-07 -7.16370185997541181e-03  2.28374452578088614e-08
 -1.84014215687470379e-10 -3.25534148190443973e-14  1.75478119699063529e-16
  2.59972744284108270e-20  1.75829303000904907e-23 -3.23555143657890773e-25
 -4.85847698981634702e-27  6.22414137611893710e-30  8.56800830392082787e-32
...
...

Using tempo2, with the same parfile, I define the following line in my oh.dat observatory file:
669765.29 4903035.31 4010839.95 OHIO oh

And generate polycos with the following command:
tempo2 -f 0329+54.par -polyco "59272 59276 300 12 12 oh 1420.0" -tempo1

Resulting in the following output:

0332+5434  27-Feb-21   20000.00   59272.08333333330            26.764179  0.824 -8.996
   1547667746.864415    1.399541538720   oh  300   12  1420.000
  9.65838213267680782e-11 -7.18816815330096913e-03  1.06237398065935839e-07
 -1.08756711359834878e-10 -1.65650952057712697e-13  1.10055878138959446e-16
  1.03022264884325224e-19 -4.56266883758036845e-22  1.68555416571149764e-26
  1.25562194275737789e-26 -4.48621173180283079e-31 -1.38661981288300634e-31
0332+5434  27-Feb-21   70000.00   59272.29166666660            26.764179  0.822 -8.923
   1547692936.461259    1.399541538720   oh  300   12  1420.000
  1.86913978051211772e-09 -7.16621097296041374e-03 -4.31492444640296126e-08
 -1.74087509249450033e-10  7.26867433688047070e-14  1.63262244716829360e-16
 -2.06841290978400306e-20  1.12056628249061619e-22 -1.42515383320422199e-24
 -3.60890167590257874e-27  2.59035460777992498e-29  9.89818299271486643e-33
...
...

I notice the following differences:

• Doppler shift is zero in the pint polyco file
• Log10 fit RMS is zero in the pint polyco file
• Reference phase is much bigger in the tempo2 polyco file
• The tempo2 polyco file begins 2 hours ahead of the pint polyco file and contains more total polycos (this may be intended behavior, the way that pint handles this makes more sense to me than what tempo2 does)

At least the zero doppler shift seems to me to be a bug. Not sure if the others are bugs or just intended differences in how pint operates vs. tempo2, or if I am not using the correct procedure to generate the polycos.

[dlakaplan]

Investigating a bit more:

• the number of polycos in the PINT output seems to be as expected. (end-start)/duration. Not sure what tempo2 is doing. I also get different segment times when I run it compared to what I see here.
• the difference in absolute phase comes because PINT picks the absolute phase TZRMJD to be the first segment midpoint, while tempo2 (I think) picks a time closer to the PEPOCH. Setting TZRMJD etc in the par file to begin with might solve this.