The easiest way to do CCDPACK processing in the background is to produce a file just containing the CCDPACK commands you want performed3. The content of such files is made much simpler if use of CCDPACK’s image list accessing facility is made. The best way to do this is to get your data files organised. This organisation can be performed in several different ways, I prefer the first method…
The command file which controls CCDPACK can be written as if responding to the C shell. Examples of such CCDPACK command files are shown in §7.2.9.
The next step after creating your command file is to run:
CCDFORK saves the current environment and writes a script which when activated restores it, ensures that CCDPACK is started and executes the commands in the command file. The point in saving the current environment is that any global or current values which you have set (by using CCDSETUP) are restored to the job, without interference with any other processes.
CCDFORK has three parameters, the first is the name of the input script, the second the name of the
output script (ccdpack_fork
by default) the final is the name of the directory in which to save the
current environment. If you do not supply a name for the last option then a unique one will be
generated as a subdirectory of the parent of the directory that holds the environment ($ADAM_USER
or
$HOME/adam
). Using this command results in a script file which may be directly executed or forked
(hopefully at nice
priority) into the background.
Since the execution environment of the current process is saved when CCDFORK is run any previous CCDPACK global and current values, which are in force, will be restored to the background process. Thus one labour saving strategy would be to set the global parameters for a CCD device using CCDSETUP interactively, this command does not then need to be repeated in the background job. So the chances of making a mistake in this crucial stage are reduced. A typical preparation sequence is:
3This section does not apply to IRAF/CL users