Store the phase offset calculated in formResiduals

Issue #73 resolved
Matt Pitkin created an issue

Currently, in formResiduals the phases for each TOA stored in the phase5 array get an offset (phas1) removed to set the first phase residual equal to zero. I’d like to have this phase offset stored for which I’ve attached a patch. I’d find this useful, so would be grateful if this could be added?

Comments (7)

  1. Michael Keith

    Hi Matt,

    phas1 is kind of arbitrary I think… Is it guaranteed to be referenced to PEPOCH? I wonder how DM and telescope come into it.

    For problems where absolute phase tracking is important, I implemented the option “REFPHS TZR” which which is intended to make all residuals be referenced to the TZR parameters (which are designed to refer to a specific epoch, position and frequency). This aught to mean you can track the absolute phase of any ToAs relative to the epoch you define.

    Does this solve your problem, or is it anyway useful to store the phas1?

  2. Matt Pitkin reporter

    Aha! That option could well be what I was looking for. I’ll give it a go, thanks.

    Just for some back story, I’m currently rewriting the code that I use for the searches for GWs from pulsars and wanted to have the option of using TEMPO2 to calculate the phase evolution. This way I don’t have to try and maintain the current separate code we have to imitate TEMPO2 - it’ll also mean I won’t have a list of caveats when asking for pulsar ephemerides based on the limitations of our current code. The code is written in Python, so I’ve been able to access the residuals via libstempo which I can use. However, I need to make sure phases for each GW detector I include (the data from which may have different start times) are referenced to the same epoch, therefore I need a way to specify that phase epoch.

  3. Michael Keith

    Yes… sorry the documentation is so lacking. Let me know if that works for you, or otherwise we can look at what other things might do better. Absolute phase tracking is something important for a few projects, but just not something normally cared about with pulsar timing.

  4. Matt Pitkin reporter

    I’ve not got it working (via libstempo) yet, but I was just wondering if line 2254 is correct. Should it instead be:

    if(psr[p].refphs==REFPHS_TZR){
    

    to be consistent with line 438?

  5. Michael Keith

    Yes, I think you are correct - tempo2 is really inconstant with passing pointers to a specific pulsar vs passing an array and an index, which causes this type of bug. Fixed in 61bc06a

  6. Matt Pitkin reporter

    Even without the fix, I actually did get things working (I think) as expected. For now this should do the trick, in particular if I set TZRMJD to be the same as PEPOCH and at TZRSITE to @. Thanks for your help Mike. I'll mark this as resolved.

  7. Log in to comment