XCCDRED -- Experimental version of CCDRED Package This external package is an experimental version of the CCDRED package which supports the ARCON multiple readout image format. The only task which has been modified from the V2.10.3beta version is CCDPROC. Note that to make preparing and using this experimental version as easy as possible the task names are unchanged. Therefore, you should avoid loading both XCCDRED and CCDRED at the same time. CCDPROC will use the following keywords where the example is for a two amplifier readout: AMPLIST = '11 12 ' / Readout order in y,x ASEC11 = '[1:1056,1:2048]' / Section read with Amp11 CSEC11 = '[1:1024,1:2048]' / Section in full CCD for DSEC11 DSEC11 = '[1:1024,1:2048]' / Image area in raw frame for Amp11 TSEC11 = '[1:1024,1:2048]' / Trim section definition for Amp11 BSEC11 = '[1025:1056,1:2048]' / Bias section definition for Amp11 ASEC12 = '[1057:2112,1:2048]' / Section read with Amp12 CSEC12 = '[1025:2048,1:2048]' / Section in full CCD for DSEC12 DSEC12 = '[1089:2112,1:2048]' / Image area in raw frame for Amp12 TSEC12 = '[1089:2112,1:2048]' / Trim section definition for Amp12 BSEC12 = '[1057:1088,1:2048]' / Bias section definition for Amp12 CCDPROC identifies the ARCON format by the presence of the AMPLIST keyword. If this keyword is not found then the behavior will be as before. The AMPLIST words, which are whitespace delimited, are appended to roots ASEC, BSEC, CSEC, DSEC, and TSEC. Note that this means the names need not be as shown but could be things like A, B, 1, 2, X1Y1 though limited to four characters. The geometry looks at the data sections, DSEC, to define the input regions, and pieces them together on output according to the CCD sections, CSEC, except that origin is shifted to pixel (1,1). The origin shifting would only be needed if a subsection of the detector is readout. The bias sections, BSEC, are used as one would expect. After trim and overscan processing all the keywords are removed yeilding an image which looks like a normal single amplifier readout. Note that the trim sections given by TSEC are not used but are deleted after processing. In order to provide the option of leaving the bias regions in the data (with or without bias subtraction) if the trim option is not set then the ASEC descriptions are used for both input and output and the keywords are not deleted A requirement is that data sections form a regular grid though there is no requirement that the size all be the same. In other words, all data regions along a column have the same width and all data regions along a line have the same height. The example below (with more than two across to indicate the extension to a mosiac) is acceptable. +----+--------+--------------+ | | | | | | | | +----+--------+--------------+ | | | | | | | | | | | | | | | | +----+--------+--------------+ The following example is not acceptable. +----+ | |--------+-----------+ | | | | +----+--------+ | | | |--------------+ | | | | | | | | +----| | | +--------+--------------+ REVISIONS April 19, 2001 1. SETINSTRUMENT was fixed and the default site is ctio. 2. The CCDDB files were updated. February 17, 2000 Fixed a bug with the overscan sections using uninitialized memory. Fixed a bug with SETINSTRUMENT doing "epar ccdred" instead of xccdred. Otherwise this is the same as the version from 1994. ================================================================================ INSTALLATION INSTRUCTIONS Installation of this external package consists of obtaining the files, creating a directory containing the package, compiling the executables or installing precompiled executables, and defining the environment to load and run the package. The package may be installed for a site or as a personal installation. If you need help with these installation instructions pr questions about the package please contact iraf@noao.edu or call the IRAF HOTLINE at 520-318-8160 [arch] In the following steps you will need to know the IRAF architecture identifier for your IRAF installation. This identifier is similar to the host operating system type. The identifiers are things like "ssun" for Solaris, "alpha" for Dec Alpha, and "linux" or "redhat" for most Linux systems. The IRAF architecture identifier is defined when you run IRAF. Start the CL and then type cl> show arch .ssun This is the value you need to know is without the leading '.'; i.e. the IRAF architecture is "ssun" in the above example. [1-site] If you are installing the package for site use login as the 'iraf' user and edit the IRAF file defining the packages, i.e. hlib$extern.pkg % cd $hlib % vi extern.pkg Define the environment variables xccdred to be the pathname to the xccdred package root directory. The UNIX pathnames MUST be terminated with a '/'. Edit extern.pkg to include the following. reset xccdred = //xccdred/ task xccdred.pkg = xccdred$xccdred.cl Where "" is the place you unpacked the package distribution files. Near the end of the extern.pkg file, update the definition of helpdb so it includes the xccdred help database, copying the syntax already used in the string. Add this line before the line containing a closing quote: ,xccdred$lib/helpdb.mip\ [1-personal] If you are installing the package for personal use define a host environment variable with the pathname of the directory where the package will be located (needed in order to build the package from the source code). Note that pathnames must end with '/'. For example: % setenv xccdred /local/xccdred/ In your login.cl or loginuser.cl file make the following definitions somewhere before the "keep" statement. reset xccdred = /local/xccdred/ task xccdred.pkg = xccdred$xccdred.cl printf ("reset helpdb=%s,xccdred$lib/helpdb.mip\nkeep\n", envget("helpdb")) | cl flpr If you will be compiling the package, as opposed to installing a binary distribution, then you need to define various environment variables. The following is for Unix/csh which is the main supported environment. # Example % setenv iraf /iraf/iraf/ # Example path to IRAF root % source $iraf/unix/hlib/irafuser.csh # Define rest of environment % setenv IRAFARCH ssun # IRAF architecture where you need to supply the appropriate path to the IRAF installation root in the first step and the IRAF architecture identifier for your machine in the last step. [2] Login into IRAF. Create a directory to contain the package files. These directory should be outside the standard IRAF dir- ectory tree. cl> mkdir xccdred$ cl> cd xccdred [3] The package is distributed as a tar archive for the sources and, as an optional convenience, a tar archive of the executables for select host computers. Note that IRAF includes a tar reader. The tar file(s) are most commonly obtained via anonymous ftp. Below is an example from a Unix machine where the compressed files have the ".Z" extension. Files with ".gz" or ".tgz" can be handled similarly. cl> ftp iraf.noao.edu (140.252.1.1) login: anonymous password: [your email address] ftp> cd iraf/extern ftp> get xccdred.readme ftp> binary ftp> get xccdred.tar.Z ftp> get xccdred-bin..tar.Z (optional) or .... ftp> get xccdred-bin..tar.gz (optional) ftp> quit cl> !uncompress xccdred.tar cl> !uncompress xccdred-bin..tar (optional) The readme file contains these instructions. The in the optional executable distribution is replaced by the IRAF architecture identification for your computer. Upon request the tar file(s) may be otained on tape for a service charge. In this case you would mount the tape use rtar to ext- ract the tar files. [4] Extract the source files from the tar archive using 'rtar". cl> softools so> rtar -xrf xccdred.tar so> bye On some systems, an error message will appear ("Copy 'bin.generic' to './bin fails") which can be ignored. Sites should leave the symbolic link 'bin' in the package root directory pointing to 'bin.generic' but can delete any of the bin. directories that won't be used. If there is no binary directory for the system you are installing it will be created when the package is compiled later or when the binaries are installed. If the binary executables have been obtained these are now extracted into the appropriate bin. directory. # Example of sparc installation. cl> cd xccdred cl> rtar -xrf xccdred-bin.sparc.tar # Creates bin.sparc directory The various tar files can be deleted once they have been successfully installed. [5] For a source installation you now have to build the package executable(s). First go to the package root directory with cl> cd xccdred If you are updating to a newer version and you earlier built the libraries and executables it is necessary to delete these. Otherwise, depending on the dates of files in the new version and the locally built libraries, it may cause the new version to be ignored. To do this the package is configured "generic" which puts all the binary files in one binary directory, the files are deleted and then you continue in the same way as a completely new installation. cl> mkpkg -p xccdred generic cl> delete bin./* # Substitute sparc, ssun, alpha, etc. Configure the package for the particular architecture to be built. cl> mkpkg -p xccdred # Substitute sparc, ssun, alpha, etc. This will change the bin link from bin.generic to bin.. The binary directory will be created if not present. If an error occurs in setting the architecture then you may need to add an entry to the file "mkpkg". Just follow the examples in the file. To create the executables and move them to the binary directory cl> mkpkg -p xccdred # build executables cl> mkpkg -p xccdred generic # optionally restore generic setting Check for errors. If the executables are not moved to the binary directory then step [1] to define the path for the package was not done correctly. The last step restores the package to a generic configuration. This is not necessary if you will only have one architecture for the package. This should complete the installation. You can now load the package and begin testing and use.