From: JACH::MMC 16-AUG-1991 23:14:15.58 To: JACMAIL,ROE_CENTRAL,J.DAVIES,R.GLENDINNING,MMC,T.LEE,D.PETTIE,A.LONGMORE,M.MOUNTAIN,M.STEWART,A.GLASSE,TOM CC: Subj: JAC0626 **************************************************************************** Number : JAC0626 To : J.Davies, R.Glendinning From : M.Casali CC : T.Lee, D.Pettie, A.Longmore, M.Mountain, M.Stewart, A.Glasse, T.Geballe Date : 16-AUG-91 Subject : JAC Review of features and suggestions for ALICE Sender : MMC **************************************************************************** DESIRABLE FEATURES FOR ALICE - THOUGHTS FROM JAC INTRODUCTION Everyone at JAC is looking forward to the arrival and commissioning of ALICE and the 256 arrays. The consensus is also that while we would like to see larger arrays operational as soon as possible, the project should take as long as necessary to ensure the delivery of a well tested, flexible system able to cope with a diversity of observing requirements. The "wish-list" below is not intended as a complete specification though we hope it will help you in preparing one. It consists of suggestions and features judged desirable by UKIRT scientific and technical staff, based on our experience in supporting IRCAM and more recently CGS4 observing. We will be happy to discuss any of our suggestions further with you. JAC contributors to this document, Mark Casali Tim Chuter Alan Bridger Colin Aspin Gillian Wright Malcolm Smith Tim Hawarden Tom Geballe Phil Williams Phil Daly 1. SCIENTIFIC ASPECTS BEFORE BEGINNING, SOME DEFINITIONS ..... To ensure we are talking about the same thing ! an exposure - the elementary array exposure between resets. Not transferred to the VAX but handled by ALICE. an image - the result of coadded or otherwise manipulated exposures, transferred to the VAX. 1.1 PROJECT The basic project as we understand it is that ALICE will be developed and integrated with a modified IRCAM 3, and shipped to Hawaii as a complete operating system. One of our current cryostats (probably IRCAM 1) will be returned to ROE. A second ALICE for CGS4 will then follow. 1.2 NEW IRCAM 3 OPTICS Given that between 1/4 and 1/2 of IRCAM proposals require the current 1.24" pixel scale because it gives them the maximum useable field, we believe the best pixel scale choice is 0.3" per pixel. This gives a field equivalent to that obtained currently with the 1.24" per pixel mode. In this way there will be no degradation in performance for any observer, since we achieve maximum field with twice the resolution of the current 0.6" scale. One or more carefully baffled afocal magnifiers should be designed to give higher resolutions - eg. x2, x6. These will be useable from J-M, although with some S/N penalty at the longer wavelengths. These need not be delivered with IRCAM 3/ALICE but may follow some time later. 1.3 CHOPPING A chopping capability will be necessary. It should be possible to chop after an arbitrary number of coadded exposures at each chop position. ALICE should provide the sync signal for the chopper. To ease image processing problems on the Vax as much as possible, there should be an option for ALICE to return only the Obj-sky difference frame rather than both frames. This would probably become the default option. 1.4 READ OUT OF ARRAY SUB-AREAS ALICE should have the ability to read out a sub-area of the array. This may be necessary to allow image rates fast enough to avoid saturation at broadband M. It should be possible to select the sub-area anywhere on the array, and the area should be of arbitrary rectangular size and shape. This will allow bad pixels to be avoided, as well as allowing small amplitude chopping on the array which gives 100% of the integration time on-source. The sub-area image should be embedded in its correct position in a 256x256 image transferred and stored on the Vax, with other pixels set to a dummy value. This will ensure that arbitrary sub-areas can be handled in a straightforward way by existing data reduction software. 1.5 SNAPSHOT MODE A snap shot mode capable of storing images sequentially and quickly to disk needs to be available. This option is used for observing occultations and short period variability, and would also be useful for investigations into seeing conditions and image sharpening. Each image must be stamped with UT time, and therefore requires ALICE to read the UT clock. This may require running a parallel cable to the telescope from the computer room. The number of coadded exposures per transferred image should be selectable. This allows maximum flexibility in balancing time resolution, filter used, and total length of the observation against data storage limitations. This does have the problem that coadded data requires 32 bits transferred against 16 for a single exposure, which will slow things down. A CHOP option should be included which alternates the chopper between images. This ensures proper background removal and maximum S/N when at thermal wavelengths. SNAPSHOT need not return any error frames. A very minimum capability should be to achieve the modest performance of the current IRCAM system which is 62x58 pixels of data stored to disk at 3 Hz, or higher image rates on smaller areas (eg. 32x32 pixels at ~12 hz). So "snapshot" must include the ability to read sub-areas to achieve higher image transfer rates as well as to minimize the quantity of data stored. One problem with transferring small images very fast is likely to be the overhead associated with storing individual images as separate files - one suggestion is that as each individual image completes it is stored in memory in ALICE as part of a 256x256 buffer, which could be transferred to the Vax when full and would look just like a single 256x256 image eg. for a 32x32 sub-area at 12 hz, 64 images could be stored in the buffer which would need to be transferred every 5 seconds. Limitations in the snapshot rate with current IRCAM are due to the ADP. The ethernet ceiling is considerably higher, in the Mbit range. So in ethernet-limited operation we should be able to improve over the current 3596 pixels at 3 Hz by factors of 10-100, though concern has been expressed that we not be able to even get close to the ethernet limit due loading, overheads etc. Some investigation into what is possible should be done. Finally, an interesting possibility is that SNAPSHOT need not be a special mode at all. It needs to be with the current system since the execution of multiple images in the normal observing mode requires the Vax to start each image going - however, there is no reason why the number of requested images could not be a parameter set in ALICE, thus avoiding Vax overheads. Then, for example, a 20 minute "SNAPSHOT" sequence could be achieved by setting no. of images =15000, exp time = 40 ms, no. of coadds = 2, and would use 60 mbytes of disk storage for 32x32 pixels (32 bit transfers). The "packing" of sub-areas into a 256x256 buffer as mentioned above would be the only difference from the normal observing mode. 1.6 REAL TIME IMAGE SHARPENING BY SHIFT-AND-ADD This refers to on-line shift and add image sharpening, discussed in an earlier commo (JAC0300) by MMC. It would be a real first for UKIRT, as well as allowing high resolution work, improved S/N at thermal wavelengths on point-like sources, and useful observing during nights of windshake. The design of this feature would require some careful defining of what exactly the mode would have to do - for example, how to handle flatfielding. What we need first, though, is a feasibility study to determine whether its implementation is technically possible, and/or likely to significantly delay delivery of ALICE + 256. The earlier commo by MMC giving an outline of image sharpening is probably sufficient for this purpose. Other considerations that arose during our meeting, - Image sharpening could be used with CGS4, by including a disable option for shifts along a particular axis. Thus shift and add would only be enabled along the spatial axis. - Bad pixels would need to be handled to avoid accidentally locking on to a bad one, or spreading the bad pixel area with each shift and add. A bad pixel mask could be downloaded into ALICE from the Vax. - A shift and add technique could be useful even with long exposures. At 1 minute exposures, for example, it could correct for telescope tracking errors and avoid the need for TV autoguiding. 1.7 FAST TV MONITOR DISPLAY A fast movie mode for peaking up, centreing, focussing is important. The large array size probably means that a movie mode which displays via the VAX as at present will be far too slow for 256 arrays. The mode must include sky subtraction. The mode should display each image as it completes in ALICE - thus the update rate is entirely determined by the exposure time/number of exposures per image selected , allowing tradeoffs between sensitivity and rate of update. Eg. focussing on a bright star would be done with short exposures/few coadds and thus rapid updating, while peaking up CGS4 would use longer exposures/1 coadd at short wavelengths, short exposure/some coadds at thermal wavelengths. This monitor display should also be operational during an integration, optionally displaying either the data coadded so far, or each exposure as it completes - the former might be the only option available at short exposure times, unless the monitor can work at high frame rates. 1.8 ARRAY READ SCHEME AND SYSTEM TESTING There will probably need to be lab tests to determine the best way of reading the array at thermal wavelengths. We need to be sure that a destructive read scheme with or without chopping gives near-theoretical scaling of the S/N with SQRT(number of coadded exposures). The multi-non-destructive read scheme with line fitting or similar is fine for shorter wavelength work. The array should also be studied for other funnies, such as stability of dark current, recovery from high flux exposures etc. Before shipment, software and hardware should be tested as a complete system ( including flexure tests ) for a period after initial problems have been overcome. 2 OPERATIONAL ASPECTS 2.1 FIXED FILTER SET / PIXEL SCALE FOR IRCAM Given the cost of 256 arrays, and danger of damage/contamination, it would be good operational policy to minimize the frequency of cryostat openings. This means using a single cold pixel scale for each camera, and having a 'fixed' filter set. It is not difficult to work out which filters should be available based on previous usage and likely demand given ALICE capabilities. We may need to purchase a few filters. 2.2 SPARES AND DOCUMENTATION The electronics will be using printed circuit boards throughout and for backplanes, with many of in-house design. A faulty backplane or intermittent problems of the type we frequently encounter will be difficult to track down. The circuits are fast and will be RFI shielded - this and lack of experience will make it difficult to service except by board swapping and testing in a spare system. The CGS4 ALICE cannot be considered a backup for the IRCAM ALICE or vice-versa, since one instrument is often being tested while the other is being used for observing. Therefore a complete spare system should also be delivered. Complete documentation is essential. 2.3 TRAINING We have almost no transputer experience in Hawaii (Phil Daly is the exception), therefore we see a need for one or two visits to the UK by a JAC hardware and software engineer for a period of 3 weeks at suitable points in the project. These visits could perhaps also involve attending MEIKO (or other) courses on transputer operation. 2.4 USE OF THE SECOND IRCAM AND THE SPARE 256 ARRAY Assuming three science grade 256 arrays, CGS4 and IRCAM get one each and the third is a spare. An obvious question is whether we should use the third to obtain some special filter or resolution capability in a second IRCAM cryostat. The consensus here is that we should not, since making use of the spare in this way essentially contradicts its use as a "spare". That is, losing an array in CGS4 or IRCAM would mean de-commissioning some capability. It may, however, be useful to configure the second IRCAM cryostat to be identical to the first by installing the spare new IRCAM optics, array carrier etc in the second cryostat, and simply keep the spare array in that under vacuum. Thus if we have an array failure in the operational IRCAM, we need only swap cryostats. We would of course still have to swap the array itself if a failure occurs with the CGS4 array. 3 SOFTWARE ASPECTS 3.1 THE VAX "D-TASK" There will be a D-task on the VAX which will replace the existing IRACS/CIRACS d-tasks. It will control the actions of ALICE and acquire the data from ALICE, probably placing the data into memory to be picked up by another task for storage. Ideal world: The new D-task should look the same to the outside world as the present CIRACS, i.e. have the same (ADAM) parameters and actions. This would minimise the impact of ALICE on the rest of the systems. Real world: The new d-task should be as efficient as possible and the ideal of making it look like the existing CIRACS should NOT be allowed to get in the way of the task doing its job efficiently. If this means we have to modify existing control software then so be it. Constraint on the D-task - Please use standard, supported, ADAM, Starlink and UKIRT software libraries. Do not use out of date, unsupported, undocumented software. 3.2 SPEED OF THE CONTROL VAX I am not sure this is a big problem. As long as ALICE does at least as much as the present IRACS-3 (presumably it will) then the present microVAX 3600 should be fine - maybe some more memory. 3.3 SPEED OF THE DATA REDUCTION AND DISK SPACE This will be a problem. Presently the CGS4 online DR only just keeps up with the acquisition, mostly with the help of the occasional inefficiencies of peaking up, etc. There is no way it will keep up with 256x256 arrays. A similar problem applies to off line DR, except that there it is perhaps less essential. Both the summit and Hilo will require more magnetic storage space and sufficient archiving facilities and consumables. Note that items 3.2 and 3.3 are arguably "JAC" problems and are presently being tackled through a separate course of action (bid for more money!). 3.4 MISCELLANEOUS We should strongly consider using TCP/IP rather than DECNET for the network link to ALICE. This would make any future moves to UNIX at the summit much easier. -------------------------------