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.

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

Make barycentered TOAs work correctly #23

Closed
paulray opened this issue Mar 16, 2015 · 9 comments
Closed

Make barycentered TOAs work correctly #23

paulray opened this issue Mar 16, 2015 · 9 comments

Comments

@paulray
Copy link
Member

paulray commented Mar 16, 2015

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.

@paulray
Copy link
Member Author

paulray commented Mar 16, 2015

@paulray is working on this.

@paulray
Copy link
Member Author

paulray commented Aug 12, 2015

Currently if you call model.phase(toas.table), it tries to evaluate the full model for each TOA. It actually should not evaluate the solar system delay terms for TOAs at the 'Barycenter'. This needs to be fixed so that one could have TOA tables that intermix Barycentric and normal TOAs.

@scottransom
Copy link
Member

I think it is likely a one-liner (or near one-liner) that we can put in to the solar_system_geometric_delay() method to return 0 for TOAs where the observatory is Barycenter.

@demorest
Copy link
Member

Shouldn't this all already work out OK if the observatory position is set correctly (ie to 0,0,0) for the barycentered TOAs?

@scottransom
Copy link
Member

Ah, but that isn't the correct barycenter position.... that is the geocenter position. And we want that as well.

@scottransom
Copy link
Member

(unless you meant in barycenter coordinates!)

@demorest
Copy link
Member

Yes, I meant the vector stored along with pint TOAs ("toas['ssb_obs_pos']") which is relative to the barycenter. This is what the astrometry class uses.. if it's zero things should work fine although I agree we might want a special case just to avoid unnecessary calculation.

I don't know if barycentered TOAs (which as we've discussed before are kind of a hack to begin with) typically have had SS shapiro delay applied or not... depending on how this was done the shapiro delay part might need disabling, or changing as the observatory wasn't really at the barycenter.

@paulray
Copy link
Member Author

paulray commented Aug 14, 2015

It should be easy to correct, but I am having trouble figuring out the Python to make it work (elegantly).
An example of a function that needs to be modified is below. The 'toas' argument is really the toas.table, which is grouped by observatory. So, how do we elegantly loop over the groups and make the delay = 0.0 for the 'Barycenter' key and use the computation for the rest?

def solar_system_shapiro_delay(self, toas):
    """
    Returns total shapiro delay to due solar system objects.
    If the PLANET_SHAPIRO model param is set to True then
    planets are included, otherwise only the value for the
    Sun is calculated.

    Requires Astrometry or similar model that provides the
    ssb_to_psb_xyz method for direction to pulsar.

    If planets are to be included, TOAs.compute_posvels() must
    have been called with the planets=True argument.
    """
    psr_dir = self.ssb_to_psb_xyz(epoch=toas['tdbld'].astype(numpy.float64))
    delay = self.ss_obj_shapiro_delay(toas['obs_sun_pos'],
                                      psr_dir, self._ss_mass_sec['sun'])
    if self.PLANET_SHAPIRO.value:
        for pl in ('jupiter', 'saturn', 'venus', 'uranus'):
            delay += self.ss_obj_shapiro_delay(toas['obs_'+pl+'_pos'],
                                               psr_dir, self._ss_mass_sec[pl])
    return delay

@demorest
Copy link
Member

demorest commented Nov 8, 2016

I believe this was fixed. If not, someone re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants