Use of single pointers for next-lower level in psCell/psChip/psFPA.

[robert.desonia@…]

From section 5.4.3-5.4.5 (SDRS ver. 02), the structs defined have
single-pointers to the next-lower logical unit (e.g., psChip has a psReadout*
member, etc.). Being, however, a single-pointer, this requires that all
psReadouts, for example, be allocated as a contiguous block of structs. Having
this definition somewhat limits you, as all of these lower-level structs must be
allocated at one time, making it not easy to add or remove them from its parent
(e.g., removing cells from a chip), and makes their existence separated from the
parent a bit more cumbersome.

Did you actually want this, or did you mean to have an array of pointers to
these objects? This might help in that any object extracted from a parent
(e.g., a cell from a chip) could be reference counted and safely handled
separately from its parent.

Actually, a psVector (or maybe a psList or psImage) of pointers would also be a
perfectly valid choice here; where they considered as containers for these
objects? You'd get some interesting functionality using these containers,
making things abit more flexible.

Also, a focal plane has the concept of separate nChips and nAlloc (like
psVector), while the other levels do not. You might want to make things more
uniform in design. Using a psVector in every logical-level would effectively
take care of this.

[eugene]

I certainly agree that we need to have a collection of pointers to, eg, psCell,
rather than an array of psCell. I lean towards using psList rather than a flat
array of psCell pointers.

The additional comments bring up a couple points:

1) the mixture of void * elements and numerical elements in psVector. I have
been thinking of psVector as a purely math objects, but it does have this
vesitige of the void *. we should revist whether that is an appropriate choice
or if another structure is needed.

2) it is now unclear why the other structures don't specify the number of
possible (chips, cells,etc) instead of only FPA.

[eugene]

we discussed this somewhat at the 29 June videocon, and did not really come to a
specific conclusion. It was generally agreed that the contained elements should
be referenced by lists of pointers, and we discussed the advantages of psList vs
psVector as the container (the difference being that in one case it is easy to
refer to the Nth element of the container [psVector] while it is easier to add
and remove entries from the other). There was some discussion of the validity
of having the void * element in the psVector container, which is principally a
math data type not a data container (at least in the implementation so far).
There was a suggestion to create a psArray type which would be equivalent to the
psList in having only void * elements, but would have ordered elements. RdS was
concerned about duplication of code between psVector and psArray. Again, no
firm conclusions were reached in the discussion.

I am going to make a fiat decision on this and say that:

1) we make a new container, psArray, which has only a void * element type
2) we use the new container to carry ordered lists of objects (as opposed to
numbers)
3) we use psArray as the container of psCell in psChip, etc

I note that among the currently defined PSLib functions which operate on or
return psVectors, only psVectorToList and psListToVector are relevant to void *
elements. The rest (ie, psSort, psMinimize, psVectorFFT, etc) cannot be used
with non-numerical elements.

I have added such an array to the SDRS with the following structure:

typedef struct {

const int n; /< size of array
const int nalloc; /< allocated data block
void data; /< pointer to data block

} psArray;

and have removed the void void entry from psVector.

[robert.desonia@…]

I noticed that the use of psArray for psCell, psChip, etc., never made it into
the SDRS.

rel2 has my current understanding of the desired struct attributes. See
src/astronomy/psAstrometry.h

[Paul Price]

* This bug has been marked as a duplicate of 105 *

[Paul Price]

Should be fixed in SDRS-07 and ADD-06 (7 September 2004).