-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fit ellipse/polynomial to UVW coordinates and evaluate at averaged TIME_CENTROID #171
Comments
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. |
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 |
I think fitting an ellipse will be more than good enough. |
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 |
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. |
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. |
Sure, but because we're averaging we don't need to evaluate the polynomial at the endpoints? |
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 |
@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
|
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. |
@bennahugo. A Cubic spline implies a cubic polynomial per spline segment?
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. |
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, ***@***.***> 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
<#171>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4RE6RQQOY2FQXSBTK5PTDRAGRMZANCNFSM4KNATCVA>
.
|
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 |
In the averaging code, UVW coordinates are linearly interpolated which probably introduces slight error. At the moment this seems to be acceptable (ratt-ru/xova#8 (comment)) but if it ever becomes a problem in future it would be better to either:
(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
The text was updated successfully, but these errors were encountered: