Hi all,
I reinstalled PINT in a linux (Ubuntu 14.04) virtual machine. PySPICE compiled correctly, setup.py modified accordingly. PINT installed both "in place" and with the standard setup.py install. But when I try to use PINT, I get the following error:

In [1]: import pint.toa  
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-24f6be3bb6b2> in <module>()
----> 1 import pint.toa

/software/PINT/pint/__init__.py in <module>()
      9 import astropy.constants as c
     10 import astropy.time as time
---> 11 from . import utils
     12 
     13 # light-second unit

/software/PINT/pint/utils.py in <module>()
      9 import astropy.units as u
     10 from astropy import log
---> 11 from spice_util import str2ldarr1
     12 
     13 class PosVel(object):

ImportError: ./spice_util.so: undefined symbol: furnsh_c

do you have the same problem? How did you solve it, in this case?

When trying to run the examples, I run into an issue every time it gets to the import pint.models step. In model_builder.py there is a line "from .dd_wrapper import DDwrapper"
but in the pint/model directory there is no dd_wrapper.py file, though there is a dd.py file.

PINT would benefit from a GUI that has the functionality of the plk plugin for Tempo2.
It will surely add some more dependencies, so it should not be required for any basic PINT operations.

In the PINT directory:
ipython
import pint.models as pm
m = pm.get_model('J1744-1134.t2.par')

m.read_parfile('J1744-1134.t2.par')

AttributeError Traceback (most recent call last)
in ()
----> 1 m.read_parfile('J1744-1134.t2.par')

/Users/vhaaster/research/code/PINT/pint/models/timing_model.pyc in read_parfile(self, filename)
334 # combinations of parameters, etc, that can only be done
335 # after the entire parfile is read
--> 336 self.setup()
337
338

/Users/vhaaster/research/code/PINT/pint/models/astrometry.pyc in setup(self)
59
60 def setup(self):
---> 61 super(Astrometry, self).setup()
62 # RA/DEC are required
63 for p in ("RAJ", "DECJ"):

/Users/vhaaster/research/code/PINT/pint/models/spindown.pyc in setup(self)
65 for ii in range(self.num_spin_terms, -1, -1):
66 term = "F%d"%ii
---> 67 if getattr(self, term).value==0.0 and
68 getattr(self, term).uncertainty is None:
69 delattr(self, term)

AttributeError: 'J1744-1134.t2' object has no attribute 'F2'

In [9]: exit()

The tests in the tests subdirectory make different, inconsistent, assumptions about the current working directory. For example test_bt.py tries to read '../tests/J1955.par', while test_model.py tries to read 'tests/J1744-1134.basic.par'. This means that test_bt.py runs correctly if you are in the main PINT directory (which is how it is run if you use the run-tests.sh script), while test_model.py runs correctly if your CWD is PINT/tests.

So, what is the preferred way to specify the path to files that need to be loaded by the scripts in the test suite?

what version of astropy should be used with PINT?
i'm trying to run tests/test_model.py and get the following error:

Read/corrected TOAs in 24.739 sec
Computing residuals...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/mnt/sda14/nirinA/pint_test_model.py", line 39, in <module>
    p = m.phase(tt)
  File "pint/models/timing_model.py", line 77, in use_cached_results
    result = function(*args, **kwargs)
  File "pint/models/timing_model.py", line 121, in phase
    delay = self.delay(toa)
  File "pint/models/timing_model.py", line 73, in use_cached_results
    return function(*args, **kwargs)
  File "pint/models/timing_model.py", line 140, in delay
    delay += df(toa)
  File "pint/models/solar_system_shapiro.py", line 77, in solar_system_shapiro_delay
    self._ss_mass_sec['sun'])
  File "pint/models/solar_system_shapiro.py", line 51, in ss_obj_shapiro_delay
    rcostheta = obj_pos.dot(psr_dir)
  File "/usr/lib64/python2.7/site-packages/astropy-0.4.dev-py2.7-linux-x86_64.egg/astropy/units/quantity.py", line 1166, in dot
    value = np.dot(self, b, out=out)
ValueError: Cannot find a common data type.

nirinA

Phase jump is such a terrible name, but that's what it is called in the tempo(2) code: phaseJump. Really, it is a phase wrap, where the pulse number should be shifted by some integer.

These parameters have the id 'PHASE' in the par or the tim-file, and they indicate whether to have a positive (+1) or negative (-1) phase wrap.

We need to implement these in some way. However, ideally it is possible to add/remove phase jumps dynamically. How would we achieve this? The current setup of the timing model class does not really allow that to be done elegantly...

I just ran the unit tests and I get failures in ltinterface.py. In several places is uses lts, when I think what is needed is u.lts. For example:

             'A1': lts,

@vhaasteren can you check on this. It seems to be your code.

The error I get is:

======================================================================
ERROR: Failure: NameError (name 'lts' is not defined)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/loader.py", line 418, in loadTestsFromName
    addr.filename, addr.module)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/Users/paulr/src/PINT/pint/ltinterface.py", line 60, in <module>
    'A1': lts,
NameError: name 'lts' is not defined

How does numpy math function handle the longdouble precision? We have to make a short unit test for numpy math function longdouble precison keeping.

I've run into a few issues with PINT relative to python3, mostly print() type issues and a few others. I was also having a hard time with PySPICE and python3, even though it should theoretically work. I found a possible replacement, written by a student at UVA called spiceypy. Seems to be fairly drop in. I've been running through the example notebook and making changes as necessary. Would you like me to fork the repo and try to make the changes in such a way that "import blargh from future" will let things work with python2.7?

We should be able to handle both barycentric timescales. This is important especially since TEMPO2 used TCB by default.

Currently, TOAs.get_mjds() returns an array of astropy.Time objects, rather than an astropy.Time object containing an array of MJDs. The latter is probably more convenient for plotting since matplotlib fails when trying to access an array of Times.

@aarchiba suggests that we make this function return an astropy.Time object with an array of MJDs, but notes that we still do need an easy way to get out high-precision floating point MJDs.

Add support for DMX (strided DM fit) model to PINT. Needs to be supported in the model builder as well.

I have started implementation of a new 'BT' model. It is not fully feature complete, but it already does more than the current implementation in the timing model. See pint/models/btmodel.py

Overview of progress:

[v] = Done, [x] = With errors, [ ] = Not done

Calculations

[v] Pulse period (Pobs)
[v] Pulse delay (delay)
[v] Derivatives of Pobs (d_Pobs_d_xxx)
[x] Derivatives of delay (d_delay_d_xxx)

Interface

[v] Caching (with decorator)
[ ] Astropy units
[v] Setting & getting parameters

Code quality

[ ] Docstrings
[ ] Unit tests (wrt tempo2 or internally?)
[x] Formatting (pylint)

Open issues

[x] In delayR(), I would think we need to use self.pbprime().
However, tempo2 seems consistent with self.pb()
[ ] We are ignoring the derivatives of delayR() at the moment. This is a decent
approximation for non-relativistic orbital velocities (1 part in ~10^6)

For some reason, the pickle files don't read on Macs. The error looks like this:

INFO: Reading toas from 'examples/NGC6440E.tim.pickle.gz'...
 [pint.toa]
Traceback (most recent call last):
  File "examples/fit_NGC6440E.py", line 18, in <module>
    t = pint.toa.get_TOAs(timfile)
  File "/Users/paulr/src/PINT/pint/toa.py", line 33, in get_TOAs
    t = TOAs(timfile,usepickle=usepickle)
  File "/Users/paulr/src/PINT/pint/toa.py", line 223, in __init__
    self.read_toa_file(toafile, usepickle=usepickle)
  File "/Users/paulr/src/PINT/pint/toa.py", line 518, in read_toa_file
    tmp = cPickle.load(gzip.open(filename+ext, 'rb'))
ValueError: non-string names in Numpy dtype unpickling

This should be fixed, and a unit test designed specifically to test the TOA pickle/unpickle process should be added. All other unit tests should not use pickling.

Add support for JUMPs in PINT models.

Right now PINT can not take ecliptic longitude and latitude which Nanograv 9yrs data set are using. We need to get is working very carefully. TODO:

1. Understand the definition of astropy ecliptic coordinate and how consistence with our definition.
2. Implement the ecliptic parameters fitting.

Looks like the clock correction parser fails when trying to read $TEMPO/clock/time_pks.dat

In [5]: toas.apply_clock_corrections()
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-33-16b1cf8a7638> in <module>()
----> 1 toas.apply_clock_corrections()

/Users/paulr/src/PINT/pint/toa.pyc in apply_clock_corrections(self)
    535             if (key['obs'] in observatories and key['obs'] != "Geocenter"):
    536                 mjds, ccorr = obsmod.get_clock_corr_vals(key['obs'])
--> 537                 tvals = numpy.array([t.mjd for t in grp['mjd']])
    538                 if numpy.any((tvals < mjds[0]) | (tvals > mjds[-1])):
    539                     # FIXME: check the user sees this! should it be an exception?

/Users/paulr/src/PINT/pint/observatories.pyc in get_clock_corr_vals(obsname, **kwargs)
     41     # of normal TEMPO-style clock correction files
     42     mjds, ccorr = numpy.loadtxt(filenm, skiprows=2,
---> 43                                 usecols=(0, 2), unpack=True)
     44     return mjds, ccorr
     45 

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/npyio.pyc in loadtxt(fname, dtype, comments, delimiter, converters, skiprows, usecols, unpack, ndmin)
    926 
    927             # Convert each value according to its column and store
--> 928             items = [conv(val) for (conv, val) in zip(converters, vals)]
    929             # Then pack it according to the dtype's nesting
    930             items = pack_items(items, packing)

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/npyio.pyc in floatconv(x)
    657         if b'0x' in x:
    658             return float.fromhex(asstr(x))
--> 659         return float(x)
    660 
    661     typ = dtype.type

ValueError: could not convert string to float: H

It seems to be trying to read columns (0,2) from the clock correction file, but that is not OK for the Parkes file. Here are the first few lines of that file. It dies when it tries to convert 'H' to a float.

    MJD       PKS-TID  GPS-PKS  NSITE  Date and comments

  44000.0       0.0               2    ATCA
  60000.0       0.0               2    ATCA
  44000.0       0.0               H    JBmk2
  60000.0       0.0               H    JBmk2
  44000.0       0.0               E    MOST
  60000.0       0.0               E    MOST
 44000.00       0.092             7    PKS
 48811.00       2.033             7    080792
 48812.00       2.128             7    090792
 48813.00       2.296             7    100792
 48814.00       2.396             7    110792
 48815.00       2.492             7    120792

In the most recent commit if I try to read in the tim file from the example ipython notebook I get an error related to this:

310         elif obs in observatories:
311             if  location is not None:
312                 raise ValueError("Specifying location for observatory TOAs is not currently supported.")
313             if type(MJD) in [float, numpy.float64, numpy.float128]:

and complains that global location is not defined.

Any ideas Paul? It's from the new block of code that you added in toa.py. I assume that it just needs to be initialized somewhere but I can't sort out exactly where.

There is a Python package named "pint" on PyPI that is quite popular and has existed for a few years:
https://pypi.python.org/pypi/Pint/
https://github.com/hgrecco/pint

It's about physical quantities, so probably there will be users that have that package installed and then if they want to install this one with the same name there's a conflict and confusion.

Is renaming this package (and reserving the new name on PyPI) an option?

Currently, the timing model parameters do not behave uniformly with units. For instance:

m = m = pm.get_model('J1909-3744_NANOGrav_dfg+12.par')

print(m.RAJ.value)

19h09m47.438s
print(m.RAJ.value.value)
19.163177231166664
print(m.F0.value)
339.3156927586801522
print(m.F0.value.value)
AttributeError ....

Of course, the reason is that RAJ.value and DECJ.value have astropy units. This is not the case for any other parameter. Of course, the units are consistently kept in m.xxx.units, but we need to decide whether the 'value' attribute will have the astropy units.

Both the nonlinear and the weighted least-squares fitter should ready for prime-time.

At the moment the fitters do work, but not very elegantly due to the required checks for units of the timing model parameters. Especially the wls_fitter has troubles with this.

Once we have the units dealt with properly, polishing the fitters is easy.

We need a capability to set global configuration variables. Defaults could be read from some config or .pintrc file, for example, then any code should be able to set them as needed.

These would be things that control the overall operation of PINT. Examples might include which clock correction files to use (although that might be better to be in the TOAs class), setting log levels, and other things I can't think of at the moment. These should be parameters that aren't specific to the TOAs, TimingModel or Fitter classes, which of course can have their own configurations. Partially, these could be a way to deal with par file parameters that need to get communicated to the other places (see this wiki page)

Create an interface that is compatible with the libstempo interface. There is much demand for this for PTA analysis codes that currently already work with libstempo. A libstempo interface would make PINT a drop-in replacement.

Progress: ltinterface exists, but it currently has difficulties with units. Also, many features are still missing.

At the moment on the master branch, the examples/fit_NGC6440E.py and many of the tests in the tests directory are failing. I think most of these are due to some API changes to things like get_mjds() that have not been updated in the tests. This should be fixed so tests can be run successfully before merging pull requests.

A common use case is to compute barycentered times from a TOA or set of TOAs. PINT should support this in a user-friendly way!

Here, barycentered means converted to the time system TDB (or TCB when that is supported as an option) and the Solar System delay terms from the model should be applied.

Currently, this is not very easy to do. The example in the sample notebook is only correct for isolated pulsars:
tt['tdbld'] - m.delay(tt) / 86400.0

I created a convenience routine to compute this quantity, but then realized that it uses all the delay terms, including the binary delay terms, not just the Solar System delays. It seems that we need some metadata associated with delay terms that specify whether they are Solar System or binary delays. This would allow simple routines to apply the delays appropriate to the Solar System Barycenter, or the binary barycenter (which I think is what you get currently with the above code).

I have updated to IPython 4.0, which splits the notebook functionality into a new package called Jupyter. When I read in the PINT example notebook, it gets updated to version 4.0, which I believe is not backwards compatible with older versions.

We need to decide whether to commit updated notebooks to the repo. Will we be making it hard for people? Any thoughts?

The get_mjds() has problem to get mjds.
"""
Traceback (most recent call last):
File "examples/fit_NGC6440E.py", line 22, in
xt=[x.value for x in t.get_mjds(high_precision=False)]
File "/Users/jingluo/Research_codes/PINT/pint/toa.py", line 408, in get_mjds
return numpy.array([t.mjd.value for t in self.table['mjd']])
AttributeError: 'float' object has no attribute 'value'
"""

Model parameters (defined in parameter.py) should have attributes that specific the allowed range for that parameter (e.g. eccentricity should be >=0 and < 1). These should be checked for and enforced by a setter method and should be available to query, so that (for example) a fitter function could use that information to not sample values outside of the valid range.

@demorest suggested that we should refactor the TOA handling code to more cleanly split out the file reading/parsing from the class that holds the TOAs themselves (the split could either involve a new class or just a set of convenience functions for reading TOA files of various types). This would make it easier to add things like other TOA input formats, and special versions that read spacecraft event times and treat them as TOAs. This issue is to capture that suggestion.

Currently, the DD model is a copy of the Tempo2 module DDmodel.C

All these calculations need to be re-done, and re-implemented. Preferably in a way that allows easy incorporations of many of the other tempo2 binary models.

My code is crashing when trying to print a model as a parfile after doing some fitting (with my own fitter).
The issue seems to come down to set_params() in fitter.py. A simple example is below.

myfit = pint.fitter.fitter(toas=ts,model=modelin)
myfit.set_params({'T0':55000.0})
myfit.model.as_parfile()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-24-e212f792c2fb> in <module>()
----> 1 myfit.model.as_parfile()

/Users/paulr/src/PINT/pint/models/timing_model.pyc in as_parfile(self)
    328         result = ""
    329         for par in self.params:
--> 330             result += getattr(self, par).as_parfile_line()
    331         # Always include UNITS in par file. For now, PINT only supports TDB
    332         result += "UNITS TDB"

/Users/paulr/src/PINT/pint/models/parameter.pyc in as_parfile_line(self)
    198         if self.value is None:
    199             return ""
--> 200         line = "%-15s %25s" % (self.name, self.print_value(self.value))
    201         if self.uncertainty is not None:
    202             line += " %d %s" % (0 if self.frozen else 1, str(self.uncertainty))

/Users/paulr/src/PINT/pint/utils.pyc in time_to_mjd_string(t, prec)
    133     astropy does not seem to provide this capability (yet?).
    134     """
--> 135     jd1 = t.jd1 - erfa.DJM0
    136     imjd = int(jd1)
    137     fjd1 = jd1 - imjd

AttributeError: 'float' object has no attribute 'jd1'

Of course, it works if instead I do this:

myfit.set_params({'T0':astropy.time.Time(55000.0,scale='utc',format='mjd')})

But fitters usually work with bare numbers, not quantities (or times or angles). So, should set_params be setting num_value instead of value? I'm not sure how it is supposed to work with all the new changes recently.

Thoughts?

We should be able to have PINT ingest TOAs that are barycentered and work correctly. Barycentered TOAs are ones that have been externally converted to the TDB time scale and have had the Solar System delays applied for light travel time and Shapiro delay from the Sun and Planets. (Question: Can they be either infinite frequency or finite frequency, or must they be infinite frequency).

When these TOAs are used in PINT, the timing model must correctly handle them, and not apply the Solar System delays a second time.

Hi folks,
I was trying to use cache in parameter.py. But if failed to import. Do you have any idea what is happening? Thank you.

ERROR: Failure: ImportError (cannot import name Cache)

Traceback (most recent call last):
File "/Users/jingluo/anaconda/lib/python2.7/site-packages/nose/loader.py", line 413, in loadTestsFromName
addr.filename, addr.module)
File "/Users/jingluo/anaconda/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath
return self.importFromDir(dir_path, fqname)
File "/Users/jingluo/anaconda/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File "/Users/jingluo/Research_codes/PINT/tests/test_parameters.py", line 1, in
from pint.models import parameter as p
File "/Users/jingluo/Research_codes/PINT/pint/models/init.py", line 5, in
from .timing_model import TimingModel, generate_timing_model
File "/Users/jingluo/Research_codes/PINT/pint/models/timing_model.py", line 4, in
from .parameter import strParameter
File "/Users/jingluo/Research_codes/PINT/pint/models/parameter.py", line 16, in
from .timing_model import Cache
ImportError: cannot import name Cache

Data taken within about a month of the present time is not covered in the IERS A file that is downloaded from http://hpiers.obspm.fr/iers/eop/eopc04/eopc04_IAU2000.62-now.
This causes PINT to abort on recent data. Scott says that the IERS B product includes extrapolations, so we may want to use that or do our own extrapolation somehow. We should do a bit of thinking about the best solution. But for sure, PINT should work on TOAs even on the day they were taken.

A possible lighter-weight alternative to PySPICE is the python-jplephem package. This needs to be evaluated to see if it meets PINT's needs.

For clock corrections, PINT should have the option of reading Tempo2-style clock corrections from $TEMPO2/clock. In Tempo2, the clock correction chain goes all the way from observatory time to some (specified) realization of TT. In TEMPO, if I understand correctly, the clock corrections only go from observatory time to GPS (which is assumed to be close enough to UTC for most work, <10 ns). So, if PINT is given an option to use the Tempo2 clock files, it should probably just use obs2gps.clk and gps2utc.clk, and not go all the way to TT. In PINT the conversions from UTC to TT and TDB are handled differently (using astropy.time).

Support should be added for TOAs (such as those from spacecraft, but also with other potential applications) that come with a 6-vector of position and velocity, rather than an observatory code from observatories.txt.

This could be done before or after #22 but certainly the two efforts need to be coordinated.

Looks like we need to update setup.py. The list of modules it installs is not complete:

    py_modules = ['pint.models.timing_model', 'pint.models.model_builder',
        'pint.models.astrometry', 'pint.models.glitch',
        'pint.models.dispersion', 'pint.models.spindown',
        'pint.models.parameter', 'pint.fitter',
        'pint.ltinterface',
        'pint.models.solar_system_shapiro',
        'pint.models.btmodel', 'pint.models.polycos',
        'pint.models.bt', 'pint.models.dd',
        'pint.orbital.kepler'],

I hadn't noticed this since I have never installed PINT with setup.py. I just use it out of the dev directory, but non-dev users should be able to install it with python setup.py install --user

Currently, there are some issues with the par files output by model.as_parfile() that should be dealt with.
The first is there is no "UNITS" line, so Tempo2 assumes it to be TCB, which is wrong. Since PINT only supports TDB so far, this is an easy fix, and I added "UNITS TDB" to the output produced by as_parfile().

In addition, the binary model should output the "BINARY BT" line. This has to be implemented differently since it breaks the 1 par file line per parameter paradigm that as_parfile() assumes.

There may be some other control-type parameters that should be included in the output as well (CLK, MODE, etc...). I haven't thought this all through yet, but I wanted to capture it as an issue.

Traditionally, there is a hidden overall phase offset in TEMPO timing model fitting. It would be better in PINT to make this an explicit parameter that can be fitted for, or not, as desired.

One possibility is to have TZRMJD, TZRSITE, TZRFRQ define the phase 0 and make TZRMJD explicitly a fittable parameter. In this case, the site and frequency could be chosen by the user and would not be chosen according to the strange rules that govern TEMPO and Tempo2's handling of these parameters.

An alternative, suggested by @demorest is to make a new parameter (with a different name!) that is an MJD(TDB) specifying phase 0.0 at infinite frequency at the barycenter. This is simpler from a conceptual standpoint, since the phase model for the pulsar spin is defined in TDB units (modulo issue #37). This new parameter could be fitted or not, as desired by the user. This is somewhat the way it is currently done in PINT, but the parameter name is TZRMJD, which is confusing.

So, we need to make a choice for PINT's implementation and put this functionality in.

On the wiki we have some documentation of the TOA classes. However, there isn't really anything on the model classes. I suggest we add a wiki page on the models that has a few pieces of information/examples:

• An overview of the model classes philosophy, and a description of the useful methods
• An example of how to create a model object from a par file
• An example of how to create a model object from scratch
• A tutorial on how to add a new model (e.g. a new binary model)

The above might make the most sense after the pull requests that modify the binary model structure have been merged. It seems that is being prevented by conflicts. @luojing1211 can those be resolved?

In the parfiles, we can have START and FINISH parameters that prescribe the MJD range where we will fit for parameters. Although technically not 'parameters' of the timing model, they are read in from the parfile, so we should treat them as such and make them 'frozen'.

Several ideas on how to deal with them:

1. Ignore these parameters everywhere, except in the 'fitter' classes
2. Make a decorator for class methods of the TimingModel derivatives that 'slice' the toas astropy table that is passed to all the class methods of the timing model.
3. ...

I think it should be option (1), but let's discuss...

There should really be a unit test in PINT/tests that verifies that bt.py is working and computing the expected results.

Also, when a BT model is read from a par file, a warning is issued that 'BINARY BT' is not recognized. This should probably be fixed.

Currently, the units of the timing model parameters are not dealt with consistently.

Issue 1

Currently only RAJ and DECJ return an astropy unit. For J0613, this

print m.RAJ.value, m.F0.value, m.T0.value

returns

6h13m43.9757s 326.600562023 53113.9550956

Issue 2

The fitter has to do some acrobatics to deal with the units:

def set_params(self, fitp):
    """Set the model parameters to the value contained in the input dict.

    Ex. fitter.set_params({'F0':60.1,'F1':-1.3e-15})
    """
    for p, val in zip(fitp.keys(), fitp.values()):
        # If value is unitless but model parameter is not, interpret the
        # value as being in the same units as the model
        modval = getattr(self.model, p).value
        # Right now while the code below preserves the unit, Angle types
        # become generic astropy quantities. Still, the timing model appears
        # to work.
        if (not has_astropy_unit(val)) and has_astropy_unit(modval):
            if type(modval) is ang.Angle:
                val = ang.Angle(val, unit=modval.unit)
            else:
                val = val * modval.unit
        getattr(self.model, p).value = val

For the StandardTiming model, this works. But for the BT timing model, this chokes on T0, which then is a time object.

Issue 3

In bt.py. It seems that parse_value is set to np.bool for almost all parameters, instead of the default fortran_float. Is there a reason for that?

Model objects should be able to compute orbital phase, for example so you can plot residuals vs. orbital phase.

This requires having a clear definition of what orbital phase means. Also, this is related to the hoped-for general capability to have binary delay models be able to work with different orbital phase specifications (e.g. PB, PBDOT vs FB0, FB1, FB2, ...)

PINT should support the creation of polyco.dat files. Eventually, there might be a PINT-specific format for phase predictions that are rapidly evaluateable without having all of PINT installed, but the first priority is a capability compatible with TEMPO (and the produces the same results).

For several reasons, such as Doppler fitting of pulsar orbits, and computing residuals in phase units, it would be nice for model objects to have a method that returned the barycentric frequency of the pulsar at a given time (or set of times), computed according to the spin evolution and radial velocity in the binary orbit.

Currently, resids.get_PSR_freq() is kind of a hack, because there is no generic mechanism to get the pulsar frequency. And, for Doppler fitting, I ended up using PRESTO's binary_psr code because it has a radial_velocity method.

Thoughts on how difficult this might be in PINT?

If this is done, it might also be nice to compute the topocentric observed frequency at an observatory as well.

The clock correction parsing does not handle time_pks.dat correctly for MJDs prior to 50844. Special case code needs to be added to deal with this.

Set up auto-download of PySPICE into the PINT directory to make it as easy to install as possible and remove the need to put the absolute path the PySPICE in the setup.py

I think that @vhaasteren said he was going to look into this issue.