Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Polycos with Doppler shifts 0 #595

Open
emmacarli opened this issue Jan 19, 2020 · 3 comments · May be fixed by #1713
Open

Polycos with Doppler shifts 0 #595

emmacarli opened this issue Jan 19, 2020 · 3 comments · May be fixed by #1713
Labels
bug

Comments

@emmacarli
Copy link

emmacarli commented Jan 19, 2020 •
edited

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
Copy link
Member

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

@mcknightryan
Copy link

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 dlakaplan linked a pull request Jan 15, 2024 that will close this issue
Draft
@dlakaplan dlakaplan linked a pull request Jan 15, 2024 that will close this issue
WIP: basic support for polyco doppler and rms #1713
Draft
@dlakaplan
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

WIP: basic support for polyco doppler and rms dlakaplan/PINT
4 participants
@dlakaplan @luojing1211 @mcknightryan @emmacarli