The single-backend bin and empty-epoch bugs in makegp_ecorr

[Wang-weiYu]

There are two potential bugs in makegp_ecorr: 1. the starting bin of pulsars which has only backend; 2. the empty-epoch crashing in ECORR noise
which is in

discovery/src/discovery/signals.py

Line 159 in ebd7edb

def makegp_ecorr(psr, noisedict={}, enterprise=False, scale=1.0, selection=selection_backend_flags, name='ecorrGP'):

• The first one is for the first valid bin that we start to count.
  It has been mentioned in
  

  discovery/src/discovery/signals.py

  Lines 168 to 169 in ebd7edb

  	# TOAs that do not belong to this mask get index zero, which is ignored below.
  	# This will fail if there's only one mask that covers all TOAs

In function makegp_ecorr, we first create masks to identify different backends, like

 masks = [np.array(backend_flags == backend) for backend in backends]

Then, we bin them like

bins = quantize(psr.toas * mask)

Because the we set the ToAs observed at different bins are False, which means 0,
we need to discard the first bin like

Umats.append(np.vstack([bins == i for i, cnt in zip(uniques[1:], counts[1:]) if cnt > 1]).T)

But, if one pulsar has only one backend needed to consider about ECORR noise,
there is no False / 0 in the bins. We need to consider about the fist bin.

• The second one is for the empty-epoch problem.
  If we consider about the ECORR noise of backend backend_A in code and we consider about the case of enterprise = True, which means we need to consider about the bins that has more than two ToAs. This problem is also mentioned at ECORR and enterprise=True #96 . We might want to change the least number in bins we consider about. But, for now, if in backend_A, there is no ToAs are observed at the same time and we want to consider about the backend_A. It will arise an error.

I am preparing a PR to fix these in the PR.

[meyers-academic]

@Wang-weiYu

Thanks for opening this issue. Apologies for taking a long time to get to it.

(1) I agree with the first issue. If I understand, the point you are making is that psr.toas * mask produces a bunch of zeros, which get aggregated into the first bin of bins, and then we ignore that bin. However, if there are no zeros, then we not properly applying ECORR to whatever corresponds to uniques[0].

I will note that one can use makegp_ecorr_simple in these situations, which applies a single ECORR to all TOAs. However, we shouldn't necessarily expect the user to check beforehand.

I will take a look at your fix.

(2) I agree that there is an issue with the enterprise implementation of single-TOA observations. However, if all of the TOAs are from distinct observations, why would one use ECORR? Then wouldn't ECORR be equivalent to EFAC? Again, I suppose we shouldn't expect the user to know this a priori, but I guess I can only see this issue coming up in situations where one includes ECORR associated with that pulsar, but then only uses a subset of TOAs that have single-TOA observations. Can you think of other examples?

More broadly, though, this could arise when enterprise=True and enterprise=False case, as you say, when there are specific backends that do not use ECORR at all (and that parameter does not exist, but the code expects it), mixed with backends that do use ECORR. We can run into this with the IPTA (where some PTAs do not use ECORR). That is what selection is for, which can be specified by the user. We should add a docstring to explain this. That selection could potentially be a workaround for the issue you present.

I will take a look at the pull request.

@vallis do you have anything to add here?

[Wang-weiYu]

Hi @meyers-academic

Thank you so much for looking into this!

(1) Yes, it is exactly what I mean.

Yes, we can always use makegp_ecorr_simple and that's true that we shouldn't necessarily expect the user to check beforehand.

(2) For my understanding, the psr flags of EFAC/EQUAD could be different from the ECORR flags. For example, if there are 3 toas toa_a, toa_b, toa_c in one psr, the 3 toas shares the same EFAC/EQUAD parameters, psr_abc, but toa_a and toa_b shares the same ECORR flag psr_ecorr_ab and toa_c just has psr_ecorr_c flag. I think this could be the case which the single toa needs ECORR.

Yes, I understand we could use selection function to do that, but if we want to selection that ECORR band, we will loss the single toa.

Thank you very much for your looking into the related pull request.

Best regards,
Wangwei