Predict example uses phase centre for beam calculation instead of pointing centre

[bennahugo]

https://github.com/ska-sa/codex-africanus/blob/master/africanus/rime/examples/predict.py#L499

This line of code uses the lm coordinates of the sources relative to the phase centre and not the pointing centre of
the telescope. An additional statement should be added that this assumes that the visibilities have not been rephased
to a centre off the pointing centre.

Same as in ratt-ru/QuartiCal#37

[sjperkins]

Assuming that the pointing centre is present in the MSv2.0 FIELD subtable, which one of

• PHASE_DIR
• REFERENCE_DIR
• DELAY_DIR

do you think it would be? Currently the example assumes PHASE_DIR

[o-smirnov]

I hate to be the bearer of bad news, but none of the above...

Strictly speaking, it's in the POINTING table. Which is a serious pain, because it isn't keyed by FIELD_ID. I also wouldn't bet my house or car on it being filled correctly.

So we'd best be a little flexible.

[sjperkins]

I hate to be the bearer of bad news, but none of the above...

Strictly speaking, it's in the POINTING table. Which is a serious pain, because it isn't keyed by FIELD_ID. I also wouldn't bet my house or car on it being filled correctly.

So we'd best be a little flexible.

If we were to use POINTING.TARGET I'd imagine the RIME would require a phase term per antenna?

[sjperkins]

seeing as POINTING is keyed on ANTENNA_ID, TIME and INTERVAL

[sjperkins]

I'm sensing a return to per-antenna UVW decomposition is on the cards....

[o-smirnov]

No no, the phase term is still given by PHASE_DIR, and the UVWs are as per the MS. This doesn't change. This has nothing to do with pointing.

POINTING only determines the l,m coordinates you give to the E-jones (primary beam).

[sjperkins]

Ah, OK, got it

[sjperkins]

This wouldn't be terribly difficult to support.

[bennahugo]

It is not a big problem of course. The vast majority is non-rephased tracking scans where the pointing is the same as the phase centre (thus the position corresponds to the maximum response of the interferometer and the antennas). But I did want to raise it so that at least an error can be raised if this assumption is broken.

[sjperkins]

Yes, sorry I should have picked up the topic of conversation sooner.

BTW have we figured out what the pointing coordinate system is? Is the POINTING table populated correctly in MeerKAT MS data?

[o-smirnov]

It's a direction measure, so the coordinate system is defined by the column keywords or whatnot.

I never actually properly looked, because 99% of the time you point at PHASE_DIR anyway... exceptions being Mario's drift scans, and, as @bennahugo points out, rephased MSs.

[sjperkins]

NB as it currently stands in katdal exported MS's, the POINTING subtable directions are filled with the phase direction.

https://github.com/ska-sa/katdal/blob/4898eafc1b04aad5378fbaed3cdcf05bbcdd013f/katdal/ms_extra.py#L855-L900

[bennahugo]

To answer @sjperkins question. Katdal does not write out non-tracking scans, so this table is never actually filled. Not sure about the code above, perhaps it is never called. I would say that if one were to write this out the most native coordinate system would be to encode the altitude over azimuth from the antenna tracking encoders, and whether the row is tracking (reached target) or not. However one can just as easily store the J2000 ra / dec coordinates as katdal seemingly aim to do. One will have to check the keywords for a more generic telescope solution

[bennahugo]