Fit ellipse/polynomial to UVW coordinates and evaluate at averaged TIME_CENTROID

[sjperkins]

In the averaging code, UVW coordinates are linearly interpolated which probably introduces slight error. At the moment this seems to be acceptable (https://github.com/ska-sa/xova/issues/8#issuecomment-578886660) but if it ever becomes a problem in future it would be better to either:

1. Synthesise the UVW coordinates at the averaged TIME_CENTROID
2. Fit and ellipse to the UVW track and evaluate it at the averaged TIME_CENTROID

(2) is likely faster as it can be evaluated in numba, as opposed to (1) which requires calling measures in raw python

/cc @bennahugo @SpheMakh

[bennahugo]

The best is to use measures and synthesize new uv coordinates for the telescope. However casacore measures is notoriously thread unsafe. I propose doing this as a final step outside of dask.

[bennahugo]

Fitting an ellipse is a first order approximation that may work if the averaging interval is short enough and the baseline isn't too long where leap seconds may start inducing phase ramps on the band

[SpheMakh]

I think fitting an ellipse will be more than good enough.

[sjperkins]

Fitting a polynomial might be more appropriate since we'll be fitting a chunk of rows and therefore not all samples (and therefore UVW coordinates) will be available for fitting an ellipse.

I also think it'll be good enough

[bennahugo]

I don't quite agree. To approximate an ellipse you need a high order polynomial, so you will be subject to Runge effects near the end points of the polynomial.

[bennahugo]

The current lerping induces dynamic range limitations of 1e-4 which is a problem for high dynamic range imaging. I don't know what casa does under the hood, but it very likely resynthesizes coordinates internally.

[sjperkins]

Sure, but because we're averaging we don't need to evaluate the polynomial at the endpoints?

[bennahugo]

Even it the runge effect doesn't bite you that much near the centre, surely we are averaging more than 3 points per baseline. In the first order approximation you only need 3 points to describe the geometry, instead of fitting for many many more variables. Fitting an ellipse will still be much faster

[sjperkins]

@bennahugo I take your point regarding polynomials, maybe splines would be more appropriate.

Basically I'll order the unaveraged samples by time for each baseline, then

1. fit a spline through the UVW points,
2. Average time centroids
3. Evaluate spline at new time centroids

[bennahugo]

I still think you will need a high order spline to approximate the geometry. Why the adversity to fitting a function that needs at most 3 variables? In other news I can confirm that CASA gives almost exactly the same error (same order of magnitude). So I would say we are at least as good as the current standard toolkit but substantially faster.

[sjperkins]

I still think you will need a high order spline to approximate the geometry.

@bennahugo. A Cubic spline implies a cubic polynomial per spline segment?

Why the adversity to fitting a function that needs at most 3 variables?

Because we need to chunk the data, so I'm not confident we'll have enough points to accurately fit the ellipse.

We would have a segment of the ellipse and I want to fit that with splines.

[bennahugo]

But this is not measured data with noise that we are talking about. It is points given by analytic functions. So I don't see how chunking would affect the fit?

On Wed, 29 Jan 2020, 17:57 Simon Perkins, notifications@github.com wrote:

I still think you will need a high order spline to approximate the geometry.

@bennahugo https://github.com/bennahugo. A Cubic spline implies a cubic polynomial per spline segment?

Why the adversity to fitting a function that needs at most 3 variables?

Because we need to chunk the data, so I'm not confident we'll have enough points to accurately fit the ellipse.

We would have a segment of the ellipse and I want to fit that with splines.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ska-sa/codex-africanus/issues/171?email_source=notifications&email_token=AB4RE6QSUO64GTR5SPZ647TRAGRMZA5CNFSM4KNATCVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKHW7HI#issuecomment-579825565, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4RE6RQQOY2FQXSBTK5PTDRAGRMZANCNFSM4KNATCVA .

[Joshuaalbert]

Just saw this. In the DSA codebase we have a high precision UVW coordinate engine that allows choosing inertial reference frame: earth's barycentre or solar system's barycentre