psAstrometry questions

[gusciora@…]

---

For psGrommitAlloc(), we don't know how to calculate several members of the
psGrommit structure based on the info provided in psExposure. Those members
are:

grommit->abberationMag
grommit->height
grommit->wavelength
grommit->lapseRate
grommit->refractA
grommit->refractB
grommit->siderealTime

I calculate the following

grommit->latitude = exposure->dec

Is that correct? Does the latitude equal the declination?

Also, I do:

grommit->longitudeOffset = exposure->ra

Is that correct?

Why is psGrommitAlloc() part of the public API, but then p_psGrommitFree()
is a private function?

In psGrommitAlloc(), if the "exposure" parameter is NULL, then I return
NULL. Is that correct?

---

We assume that if a cell has more than one readout, all readouts have the
same coordinates. Is that true?

---

In psCellinChip():

1: if we find no cell with has this coordinate, we return NULL.
2: if either the chip or chipCoord argument is NULL, I return NULL.

---

I have run across the tangentPlane<->FocalPlane transformation many times,
which is a plane distort transformation. Where should I get the 3rd and 4th
arguments for those transformations from?

---

psCoordCelltoSky(): my implementation requires a new psGrommit be created
for each transformation. This is because the "psExposure" is a part of the
psFPA struct, but "psGrommit" is not. Should we add psGrommit to the psFPA
struct?

---

psCoordCelltoSkyQuick() converts linear cell coords to spherical sky
coords. It is supposed to use the cell->toSky transform. However, that
transform is linear transform. How can I produce spherical coordinates from
it?

---

In psCoordSkytoCell(), how do I determine the psGrommit, which is necessary
to perform the Sky->FPA transform?

---

psCoordSkytoCellQuick() How should I perform this transfrom?

---

This is a question on the polynomial functions:
Page 39 of the SDRS talks about using the mask terms in the evaluation of
various polynomials. Should the psEvalPoly() functions take that mask into
consideration? (NOTE: I chose to implement the coordinate transfromation
without a call to the psEvalPoly() function.)

[Paul Price]

Regarding members of the psGrommit, these come from SLA_AOPPA
(​http://star-www.rl.ac.uk/star/docs/sun67.htx/node21.html#SECTION00048000000000000000);
see also the PSLib ADD, PSDC-430-006-02, p14. In particular, the latitude will
be provided by the user (it's known a priori); it is not the declination
(there's a handy guide to the "Celestial Triangle" at
​http://prodevweb.prodev.usna.edu/Seanav/NN204/lectures/Student%20Guide/Less%207%20Celestial%20triangle.pdf
).

Regarding the freeing of grommits (public/private), this is due to the memory
interface: all objects are freed using psFree, which knows the particular
destructor to call from the psMemBlock. Hence the user doesn't need to have
access to psGrommitFree, and so it's private. I believe this is the standard
method of operations.

For psGrommitAlloc(), since an allocator shall never return NULL, if the
"exposure" parameter is NULL, then the allocator cannot do its job, and so
should generate an error.

---

Regarding the coordinates of readouts in the same cell, I can't see why there
would be offsets, but it might happen. This is why psReadout has x0 and y0,
which should be filled in for each readout in a cell. Why would it be necessary
to assume that the readouts have the same coordinates?

---

Regarding psCellInChip, I suggest that the function shall generate an error if
the chip or or coord argument is NULL: the user has clearly made a mistake
somewhere.

If no cell is found with the specified coordinate, I agree that NULL should be
returned. However, this requires that the cell argument is pre-set to NULL by
the user; otherwise there's a potential for a memory leak.

---

I'm not sure which function you mean by "the tangentPlane<->FocalPlane
transformation", and specifically the "3rd and 4th arguments".

If you mean psCoordFPAToTP:
psPlane *psCoordFPAToTP(psPlane *out, const psPlane *in, const psFPA *fp);

The transformation is contained in fp->FPtoTP, and that should be all that's
required.

---

I agree we should add a "psGrommit *grommit" member to the psFPA struct to allow
coordinate transformations.

---

Regarding psCoordCellToSkyQuick() and psCoordSkyToCellQuick(), thanks for
pointing out the insufficiency of the current design. Here's what I suggest:

• We rename "cellToSky" in a psCell to "cellToTP", and use this to go from the

cell coordinates to tangent plane coordinates.

• We add a "psProjection *projection" to psFPA, which can be used to go between

tangent plane and sky coordinates quickly (psProject, psDeproject). The "R" and
"D" members of the psProjection would be set to the telescope boresight. The
"Xs" and "Ys" members aren't all that important (since they are redundant with
the cellToTP transformation) and should probably be simply set to 1.0. The
projection type is PS_PROJ_TAN.

Then, psCoordCellToSkyQuick does the following:

• Applies the cellToTP transformation to get TP coordinates.
• Deprojects the TP coordinates to the sky.

And psCoordSkyToCellQuick does the following:

• Projects the sky coordinates to the TP
• Generates an error if the cellToTP transformation is not linear
• Calculates the inverse transformation for cellToTP
• Applies the inverse transformation to get the cell coordinates.

What do you think?

---

To perform psCoordSkyToCell(), the psGrommit can be retrieved by following the
"parent" links up to the FPA, if we put the grommit in the FPA, as you suggested.

---

Regarding evaluation of polynomials, yes, the mask should be used when
evaluating the polynomials. Is there a reason to have two implementations of
the polynomial evaluation?

[Paul Price]

I just realised that instead of "generate an error", we should probably psAbort
so that the user can trace what went wrong.

[gusciora@…]

Regarding the call to SLA_AOPPA(), there are still quite a few values which I
don't know how to generate inside the psGrommitAlloc() function. From the page
you mentioned, how are DATE, DUT, ELONGM, PHIM, HM, XP, YP, WL, and TLR calculated?

---

regarding psGrommitFree(): okay.

---

regarding the multiple readouts: okay. It might have made it easier/faster to
imlement psCellInChip() if we only had to check the coords of a single readout.
However, I will assume they might be different.

---

Regarding the NULL arguments to psCellinChip(), it's true that the user probably
made an error if he calls these functions with NULL arguments, however, when
searching for the appropriate cell/chip/FPA in other functions, this function
might be called in many different functions, and it might be easier to simply
make it return NULL, rather than abort.

---

Many functions must transform tangentPlane to FocalPlane and vice versa. In
order to do this trasnformation, one must call psPlaneDistortApply(), which
requires two additional parameters corresponding to the color and magnitude of
the object, I believe. How do I calculate those parameters?

---

I added a grommit member to psFPA, so we should be done with that item.

---

I renamed the cellToSky member, actually it was already renamed toSky, to
"toTP". I am asuming that the projection member of the FPA is set somewhere
else, though it currently is left to the user: there are no Alloc functions for
psReadout, psCell, psChip, psFPA, etc.

[gusciora@…]

Regarding the masks and the polynomials: okay. There was no mention of how the
mask was to be used in the SDRS (I believe) and I just wanted to clarify.

Are the various evalPolynomial functions supposed to be using the coeffErr[]
members in some way?

[gusciora@…]

Regarding the masks and the polynomials: okay. There was no mention of how the
mask was to be used in the SDRS (I believe) and I just wanted to clarify.

Are the various evalPolynomial functions supposed to be using the coeffErr[]
members in some way?

[Paul Price]

No need to worry about the coeffErr members at the moment.

For multi-dimensions, certainly, they'll be hard to calculate.

[Paul Price]

Ack, I had no idea all this astrometry stuff was so convoluted! We might have
to delay this for a bit, until we finish researching how to handle times (leap
seconds and all that). Hopefully, we'll have that sorted out by Monday, but
here's a map of where we're going:

DATE: "mjd" in psExposure will become a psTime from which it will be possible to
derive UTC.
ELONGM, PHIM, HM, TLR: Should be known a-priori, and will be put into a new
struct, psObservatory, which will be put into psExposure.
DUT, XP, YP: Use zero for now. We are currently researching what's the best way
to do all the timing stuff.
WL: We should add a "const double wavelength" to psExposure.

---

For psCellInChip(), one may want to distinguish between a NULL returned because
"it's not on this chip" and a NULL returned because "you gave me silly input".
I guess it's only a matter of whether the user pre- or post-tests. I'm not
overly fussy, but prefer the additional error-checking of aborting if the chip
is NULL.

---

In transforming between the TP and FP, you're right that one needs the colour
and magnitude. We should add these to the APIs, after the input coordinates:

/ Convert focal plane coords to tangent plane coordinates */
psPlane *
psCoordFPAToTP(psPlane *out, /< Coordinates to return, or NULL

const psPlane *in, /< input FPA coordinate
double color, /< Color of source
double magnitude, /< Magnitude of source
const psFPA *fpa) /< FPA description
);

---

I'm surprised to see that I didn't define allocators for the different
astronomical images. We shall certainly need them. I'll define some and get
back to you.

[Paul Price]

SDRS for astronomy images at 11 August 2004, CoB.

[Paul Price]

Fixed the astrometry functions in the SDRS. This was the issue about color and
magnitude missing. The remaining issue from this bug is the psTime stuff, which
I hope to resolve tomorrow or Monday.

psPlane *psCoordFPAToTP(psPlane *out, const psPlane *in, float color, float mag,
const psFPA *fpa);
which converts coordinates \code{in} on the specified focal plane
\code{fpa} to tangent plane coordinates, applying the appropriate
distortion terms. The \code{color} and magnitude (\code{mag}) of the
source is necessary in order to perform the distortion between the
focal plane and the tangent plane.

The other functions that had the same addition are:
psSphere *psCoordCellToSky(psSphere *out, const psPlane *in, float color, float
mag, const psCell *cell);
psPlane *psCoordTPToFPA(psPlane *out, const psPlane *in, float color, float mag,
const psFPA *fpa);
psPlane *psCoordSkyToCell(psPlane *out, const psSphere *in, float color, float
mag, psCell *cell);

[gusciora@…]

The following functions determine which Cell or Chip corresponds to a
specific coordinate.

psCellinFPA()
psChipinFPA()
psCellinChip()

They all have the parameter "out", which I think should be eliminated. The
reason is that in all cases, we are returning a pointer to an existing
Cell/Chip, and never allocating a new one. If this argument "out" is not
NULL, it does not really make sense to copy an entire cell or chip data
structure into it. Does that sound right?

For all of the above, if there is no Cell/Chip in the structure which
contains that coordinate, then I return a NULL. NOTE: even though a
coordinate might physically lie with in a chip, it might not correspond to
any cell, and the result might be NULL. This can happen for a few reasons.
1) the cell is not functioning. B) the coordinate lies between two cells.
Is all of the above correct?

I modified the psCoordCellToSkyQuick() to do what you suggested:

Transform cell coordinates to tangent plane coordinates.
Deproject the tangent plane coordinates onto a sphere using the

PS_PROJ_TAN projection.

Return those spherical coordinates.

Is that correct? Or, do I have to somehow do a spherical-to-spherical
transformation to get those above coordinates mapped into the sky, or
something like that?

In general, if a function is called with a parameter, other than "out", which
is NULL, on your advice, I will psAbort(), rather than return NULL.

Take psCoordFPAToChip() for example. What is to be done if no chip
corresponds to the combination of FPA and FPA coordinates? Returning NULL
seems appropriate. But then, as you pointed out, this can cause a memory
leak if the "out" parameter is not NULL. What should we do?

From a user's persective, the format of some functions seems odd. For example:

psCoordFPAToChip(chipCoord, fpaCoord, chip)

What seems odd to me is that the coordinate is in the FPA, but the argument
is the chip. Further, that FPA coordinate does not necessary lie on that
chip. We have to determine the parent FPA for that chip, then figure out
the correct chip. Why not simply change that 3rd argument to be an FPA?
The same argument applies to psCoordChipToCell().

I added your (color, magnitude) arguments to the functions that need them:

psCoordFPAToTP()
psCoordCellToSky()
psCoordTPToFPA()
psCoordSkyToCell()

however, I should point out that the psPlaneDistortApply() functions appear,
at least in the SDRS, to take those arguments in the opposite order
(magnitude, color).

[Paul Price]

Removed the "out" parameter in functions psCellInFPA,psChipInFPA,psCellInChip.
If the coordinates for the Chip (say) do not correspond to any of the cells,
then I agree that NULL is a very natural value to return. With the "out"
parameter gone, I think that gets rid of the potential for memory leaks.

I think your description of the implementation of psCoordCellToSkyQuick looks
fine. The idea is that the transformation to the tangent plane does most of the
work, and it should go straight to the standard sky system (ICRS) from the
tangent plane using the psGrommit without the need for another transformation.

With respect to functions such as psCoordFPAToChip, the function shall return
the position relative to the chip, no matter if the coordinates are off the
chip. That is, if it comes out to be (-12345,54321), then that's fine. That
means there's no memory leak, because I specify the particular chip that I want
the coordinates relative to; also, the function doesn't have to work out which
chip the FPA coordinates are on.

I cleaned up the discussion in the SDRS of psPlaneDistort to make it
consistently refer to the ordering of x,y,color,magnitude. This is the logical
order to refer to them, since we expect there to be a decent color dependency,
but (hopefully) not a magnitude dependency. My apologies for the confusion.

[gusciora@…]

The explanation of the psCoordFPAToChip() opens a few questions for me. The
description of that function in the SDRS instructs me to call psChipInFPA() to
determine which chip contains the specified coordinate. This led me to believe
that psCoordFPAToChip() should return chip coordinates on whatever chip
contained the specified FPA coords. However the latest explanation indicates
that the returned chip coordinates are not necessarily defined in the specified
chip. If that is so, than what is the purpose of calling psChipInFPA() to
determine the proper chip? Can you review your explanation and the SDRS and
make sure it makes sense?

The rest of the explanation looks fine. The only open issues remaining with the
psAstrometry.c file are:

The input parameters for the Wallace's grommit stuff.
Possible unit conversion that might be required when calling the SLALIB
functions.
Test cases. It might be best if we worked on these together since I have no
idea how to create many of these transformations.

[Paul Price]

From the SDRS:

"psPlane *psCoordFPAToChip (psPlane *out, const psPlane *in, const psChip *chip);
which converts the specified FPA coordinates \code{in} to the
coordinates on the given Chip. The specified chip need not contain
the input coordinate. To find the chip which contains a particular
coordinate, the function \code{psChipInFPA}, defined above, should be
used."

The FPA coordinates are converted to coordinates on the given chip. That means
that it does not need to find the chip that the coordinates are on. This
function is intended to be used in conjunction with psCoordChipInFPA, which
identifies which chip the coordinates are on. Oh, OK... I see the confusion:
the last sentence, I guess was addressed to the user---the *user* is to use
psCoordChipInFPA to get which chip the coordinates are on. Sorry about that.

Presumably, psCoordChipInFPA iterates over all chips in the FPA, running
psCoordChipToFPA on each to get the coordinates of 3 of the chip corners on the
focal plane, from which can be inferred which chip the coordinates of interest
belong to. Having identified the chip, then psCoordFPAToChip gets the
coordinates on the particular chip.

I will get back to you shortly on the Grommit stuff, and unit conversion.
Drop me a note offline about test cases.

[Paul Price]

Regarding the time stuff needed for SLALIB, these have now been specified.

There is a "const psTime *time" in psExposure (replacing "mjd").

UT1-UTC may be calculated via:
double psGetUT1Delta(psTime *time);

Conversion to a MJD is achieved via:
psF64 psTimeToMJD(psTime *time);

The pole coordinates (xp,yp) will be returned via:
psSphere *psGetPoleCoords(psTime *time);

Each of these are scheduled to be coded in the next cycle. Until then, I
suggest you might just use place-holders for psGetUT1Delta (= -0.5),
psGetPoleCoords (=0.1,0.5). psTimeToMJD is defined as the following:
MJD = seconds_since_1Jan1970 / 86400 + 40587
where seconds_since_1Jan1970 can be derived from the psTime struct:

typedef struct {

psS64 sec; /< seconds, negative values represent

dates before 1970

psU32 usec; /< microseconds
psTimeType type; /< type of time

} psTime;

Suggest you just implement a simple version of psTimeToMJD to allow simple
testing, and then we can fix it up properly next cycle and review the testing.

[Paul Price]

* Bug 124 has been marked as a duplicate of this bug. *

[Paul Price]

* Bug 125 has been marked as a duplicate of this bug. *

[Paul Price]

I assume this bug is resolved, following our meeting at MHPCC a month ago.