- Survey Strategy --
The Survey Strategy Requirements Document has been taking shape under the
care of C. Lonsdale, and several aspects that affect 2MAPPS were discussed.
- Scan Contiguity
The document already contains the requirement that when the critical
survey scanning constraints are satisfied by the observing plan, to the
extent possible, contiguous regions shall be scanned sequentially in
time. The discussion centered on identifying those aspects of the 2MAPPS
processing that would be favorably affected by contiguous scanning and
whether there were any negative impacts. None of the latter were
identified. Areas where advantages would result were calibration,
confirmation, and product uniformity.
- Orthogonal Scans
A suggestion had been made at the survey strategy meeting in Amherst
that sometime (probably after the survey was finished) it might be a good
idea to rotate the chopped/scanning secondary 90 degrees and execute some
scans along constant declination. This would provide some orthogonal
sampling relative to the survey scans and might allow them to be
"stitched together" better. The consensus was that this idea was a bit
vague, that the impact on software design was unclear, and that the basic
idea might be good if quite a lot of scans were done in this way, but
allocating enough time to make something out of it appeared unlikely. It
was decided that further consideration of this idea should be
postponed.
- Strip Geometry
The current strip geometry, i.e., the layout of desired survey scans
on the celestial sphere, does not appear to incorporate the 10 arcsec
pointing-control safety margin or the accomodation for precession. This
refers to the geometry in the UMASS model being used for simulation and
survey planning. The document contains requirements for these safety
margins, and the consensus of the working group was that they are indeed
necessary and should be incorporated in the simulation as soon as
possible. As long as the survey planning is done with the less constrained
model, false conclusions about survey progress may be obtained, although
it is hoped that since these additional constraints are small, their
effect will also be small on the survey design.
- Processing Turnaround Time At IPAC
Concern was expressed about a requirement that IPAC process all data
within two weeks; this appeared to be a possible interpretation of one of
the requirements in the draft document. The consensus was that this was
not a requirement to process end-to-end all data within two weeks of
observation, but rather to determine to a fairly high level of confidence
that the data were usable within two weeks of receipt at IPAC. It was
noted that some southern data may not even be at IPAC within two weeks of
observation.
This led to some 2MAPPS design modifications. Since it was planned
anyway to load the tapes on disk upon receipt in order to verify that the
tapes can be read, 2MAPPS will have an operating mode in which it
processes only the calibration scans, which can probably be done
immediately after loading to disk. Quality checking on this much
should reveal whether extensive problems requiring significant
rescans are needed in most
cases. Isolated survey scans with fatal problems peculiar to themselves
would slip through, but this may not be a frequent failure mode, and
normal processing may still be done soon enough so that rescans could be
requested while the sky is still available. When none of this succeeds,
the rescans would have to be done when the sky comes around again, and
this kind of recovery is expected to happen occasionally. So the plan as
stated would have a high probability of solving the problem of
identifying unacceptable coverage within two weeks of data receipt
in a large fraction of the cases.
The conclusion was that the document should state the requirement
clearly with this interpretation, and 2MAPPS will incorporate the ability
to run in a calibration-only mode. It was decided that keeping the
products from this mode was probably not cost-effective, and that the
calibration scans should be run again when the entire night's data are
processed.
- SIS Scrutiny --
As part of the preparation for the CDR on January 26, it is desired that
the "key" SIS's be scrutinized to increase the probability that all of the
right information to support the final products is flowing through the system.
The "key" SIS's are primarily those which transmit the data of final
scientific interest or impact them directly. Although putting the SIS's
in immaculate form before the Christmas holidays is not considered a
realistic goal, it is advisable for each cognizant engineer to begin a
careful examination of the SIS's that are input and output by his/her
subsystem, and if time permits, the other SIS's.
One useful suggestion that came out of the SIS discussion was that a
standard FDD coding requirement should be incorporated that requires each
output table or FITS file header to contain a line indicating the version
identification of the generating program and the processing date and time (J.
Fowler may be contacted for information on obtaining the date/time information
in Fortran). In the case of table files, the corresponding line from the
program that generated an input table file should be carried over into any
output table files, along with other header information (this is normally done
anyway with FITS headers, where entire headers are copied from input to
output, with "history" lines being added to indicate processing program version
and date/time). There was some concern about snowballing the file size, so
the information carryover idea will be considered a guideline, not a
requirement.
- Persistence Blanking in Images --
A tangential point that arose from the discussion of the SIS's was that
the requirements may be interpreted to include blanking out persistence objects
in the coadded images, and no place in 2MAPPS has been identified where this
is done. Some disagreement ensued over whether such blanking was preferable to
providing a list of persistence source locations in the image and leaving the
image alone, as well as whether ghosts and other probably identifiable
artifacts were to be treated in this way. The possibility of leaving the image
alone and supplying an overlay mask image was discussed; some objection to the
proliferation of images was expressed.
Whether to blank pixels or supply location information was deferred, but
the place in 2MAPPS for doing either of these tasks was identified: GALWORKS,
which has all the information needed in memory at one time.