[LSST|dm-astrometry #2] LSST Astrometry and Photometry

[Robert Lupton the Good]

Dear Dr. Astrometry,

I'm sending you this email in response to a useful meeting with those on the CC list re the involvement of the French (IN2P3/LPNHE/CNRS/??) group in LSST astrometric and photometric calibration.  Pierre Astier presented a proposal for an astrometric solver with functionality similar to Emmanuel Bertin's SCAMP (which I'm appending without permission...).

At the end of the meeting we decided that the LSST folk would make a proposal on how to start our collaboration, but Les Français are of course more than welcome to take part.

The point of this email is to make sure that everyone's on the mailing list (you can subscribe at https://lists.lsst.org/mailman/listinfo/dm-astrometry), and to let everyone else on the list know what's going on.

So as to have *some* content, I'll also add my notes on Pierre's presentation.
	- I assume that clipping of outliers is included in all the solutions

	- It's nice to be able to solve for the relative astrometry without any external catalogue.  Otherwise errors in the external catalogue can drive distortions in the internal catalogue.  I realise that the system is under-determined without at least 2 externl fixed points, but it'd be good to allow a solution either adopting the mean position and scale of the internal points, or leaving the overall position and scale set to e.g. (0, 0) and 1.0

	- I'd much rather not spend our time thinking about Calabretta-'n'-Greisen FITS WCS conventions.  Let's define the "Wcs" as a mapping from pixel to world coordinates without restriction on the representation.  I totally agree that we need a way to map this to de-factor standards such as TAN-SIP for external users, but let's decouple the problems.  For example, LSST's been looking at Starlink/Dave Berry's AST classes.

	- In the same spirit, let's not think about I/O and FITS files.  The LSST code assumes data structures in memory, and that's what this astrometric solver should manipulate.  We do need to do I/O, of course, but that's a separate problem.

	- When you say, "Use polynomials initially" I hope you're thinking of Chebyshev polynomials.  The problem is still linear, and Chebyshev's behave much better between data points and when you might want to truncate the solutions.

	- I mentioned freeing up the CCDs in the camera.  I don't think that we need this in the initial version, but I'm thinking of a model where one CCD (probably near the boresight) is fixed, and the others are connected by "springs" whose spring constants can be varied when minimising the X^2 (i.e. add a term sum k_ij (x_i - x_j)^2 to the cost function, where x_i and x_j are the positions of CCDs i and j.  I'd probably set k_ij == k initially, but I can imagine a different k between CCDs in a raft and between rafts).  If we make k very large the system becomes rigid).

	- If the matrices get too large, does it make sense to think of some sort of tiled or hierarchical fitter?

	- You're thinking of Cholesky decompositions.  Have you thought of pre-conditioned conjugate gradient solvers (as used by e.g. the CMB community)?  They are designed for Very large sparse systems, and can be easily parallelised using openMP or MPI (actually I'm not sure how easy the MPI versions are).  If you're interested, Jon Sievers is a colleague of mine (now in South Africa) who wrote the solvers for the ACT dataset.

	- When you say, "proper motion" I assume you mean parallax too.

						R


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sim-astro.pdf
Type: application/pdf
Size: 351133 bytes
Desc: not available
URL: <https://lists.lsst.org/mailman/private/dm-astrometry/attachments/20150422/09937e96/attachment-0003.pdf>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.lsst.org/mailman/private/dm-astrometry/attachments/20150422/09937e96/attachment-0003.sig>