search

nanograv / PINT

PINT is not TEMPO3 -- Software for high-precision pulsar timing
Other
118 stars 101 forks source link

Error in reading P0 parameter in the par file #1330

Open AkashA98 opened 2 years ago

AkashA98 commented 2 years ago

When working with one of the CHIME pulsars, where the par file looks like

PSRJ J1605-01 RAJ 16:05:08.808 DECJ -01:05:42.36 P0 1.67586 PEPOCH 58896.57911736168 DM 32.711 EPHEM DE430 CLK UNCORR

which has P0, instead of F0 (=1/P0), pint fails to register this as F0, saying

UserWarning: Unrecognized parfile line 'P0 1.67586' warnings.warn(f"Unrecognized parfile line '{p_line}'", UserWarning)

and when we look at the par file itself

{'Spindown': Spindown( floatParameter( F0 0.0 (Hz) frozen=True), MJDParameter( PEPOCH 58896.5791173616800001 (d) frozen=True)), 'AstrometryEquatorial': AstrometryEquatorial( MJDParameter( POSEPOCH UNSET, floatParameter( PX 0.0 (mas) frozen=True), AngleParameter( RAJ 16:05:08.80800000 (hourangle) frozen=True), AngleParameter( DECJ -1:05:42.36000000 (deg) frozen=True), floatParameter( PMRA 0.0 (mas / yr) frozen=True), floatParameter( PMDEC 0.0 (mas / yr) frozen=True)), 'SolarSystemShapiro': SolarSystemShapiro( boolParameter( PLANET_SHAPIRO N frozen=True)), 'DispersionDM': DispersionDM( floatParameter( DM 32.711 (pc / cm3) frozen=True), floatParameter( DM1 UNSET, MJDParameter( DMEPOCH UNSET)}

it registers this as having F0==0. pintk throws a matplotlib error when such a par file is used, but fixing this might fix that as well.

paulray commented 2 years ago

This is a duplicate of #410

AkashA98 commented 2 years ago

Oh, okay, thanks, so is there a consensus on this, it's not clear reading the original issue? Do we need to manually change the par file to make it F0 or is anyone planning to write a small snippet to read the period? If this is still an open issue, I am very happy to kick start my pint development with this...

paulray commented 2 years ago

I think there is a consensus that we should translate on read. I'm not sure exactly how that should be implemented in our model builder code. Perhaps @aarchiba has an idea?

aarchiba commented 2 years ago

I believe we handle this sort of thing with PB/PBDOT versus FB0/FB1/FB2/... - not necessarily well. Also the model builder code is difficult to work with and I'm not sure what its current state is. Parameter objects have a facility for aliases, but those are simply different names for the same value. I'm not sure we have any examples of conversion.

Perhaps create Parameter objects for P0 and P1 (and maybe the full prefixParameter family) and then when setup() is called these would be used to set F0, F1, ... and then forcibly unset (so they wouldn't need updating when F0 is changed)?