search

nanograv / pint_pal

A long-lived repository for NANOGrav Pulsar Timing workflows and analysis.
MIT License
6 stars 16 forks source link

Output of large_residuals no longer seems to work with bad_toa #47

Closed gooddc closed 7 months ago

gooddc commented 11 months ago

The last couple times I've gotten a run lite_utils.large_residual and then plugged the output into the bad-toa block, the bad-toa block seems to now give me errors. I ran lu.large_residuals(fo, threshold) for some data and got back

[guppi_56614_J1713+0747_0004.15y.x.ff, 20, 1]

Per my understanding/what the doc string says, I popped that directly back into the bad-toa block in my config and got

traceback.txt

Have I messed up large_residuals somewhere along the way or has something changed in the excision that makes the output of large_residuals no longer just work?

rossjjennings commented 11 months ago

It looks like the error message is complaining about the lack of a subint flag in at least some of the TOAs you're using. The NANOGrav 15-year TOAs all have this flag, and bad-toa tries to match against it -- the two numbers at the end of the large_residuals() output are meant to be the values of the chan and subint flags.

rossjjennings commented 11 months ago

Using bad-toa-averaged could be a workaround here, but I'm not entirely clear on how that would work in a case like this. Presumably it would remove other TOAs from this epoch too, which we don't want.

The right way to deal with this is probably to check for the existence of the chan and subint flags on a per-TOA basis before trying to match against them. It would require some fiddling with the apply_ignore() function. If done properly, though, it could make bad-toa flexible enough that we wouldn't need a separate bad-toa-averaged field.

JPGlaser commented 7 months ago

I merged this into the main branch. This should solve the problems you were having @gooddc .

~ Joe G.