If you are puzzled by aspects of the pipeline software, before asking me, please look here to see if someone else has already asked it (or whether I have just invented it for that matter ..).
The place to start is to look at the brief getting started guide. It emphasizes brevity over completeness.
The problem here is that the rebinning behaviour of crop is to sum all of the pixel values that contribute to the new larger pixels (one cannot go to less binning). This is OK for the true counts but does not apply to the bias level. In fact one should really take frames of the same format for deducing the bias correctly. Otherwise dividing by the number of old pixels which contribute to each new pixel may get you to approximately the right level. This means that if you want to bin normal data you must subtract the bias from it first!!!
If you want variable aperture radii and/or optimal extraction, profile fits are needed. In this case you must specify which targets you want to use to define the profile shapes. The reposition mode 'reference_plus_tweak' also requires this. This is done in setaper. If you fail to define any such targets for a CCD, reduce will abort with an error message (prior to version 2.3 it carried on in normal mode but I realised that this would be misleading).
Tim Naylor's optimal photometry only works when you take the ratio of target and comparison. It would be possible to provide a correct normalisation if the profile fits were an accurate representation of the profiles. This is not usually the case, although I have tried to apply corrections on the basis that the profile fits are accurate. Still, its only the ratios that are useful.
Easy this one: you can't, at least not directly. As said above, optimal counts can only be used in ratios, but also they can only be used as ratios between two targets on the same frame. Therefore to put a proper scale on, one should also carry out a normal extraction of the comparison star you used, do the same for a standard star and use their ratio to provide a correction to magnitudes.
Have you set your LD_LIBRARY_PATH environment variable up correctload library path up correctly? If you don't know what this is about, look again at the installation instructions. You need to tell the software where to find shareable libraries for PGPLOT and Xerces.
Sorry I can't distribute SLALIB; you must get it from Pat Wallace at RAL. You want the C version.
This can happen if when you invoked grab to get the frames you terminated it with ctrl-C. In this case the last frame can be partial and therefore corrupt. This is typically the case if the last file was not reported as having been written by grab. If you inadvertently include such a file in your list for combine (or other similar routines), then it falls over. The solution is to delete such corrupt files.
The answer is yes, but you have to be careful. The reason why it can be difficult is that each session may access the same default files which could cause disaster if you are relying on the defaults. One way is to specify 'nodefs' which at least stops the programs accessing the default files. You would then need to specify all arguments yourself if the default defaults are no good. However, much the best solution is to specify the environment variable ULTRACAM_ENV to point at a new location for storing the defaults, as in
setenv ULTRACAM_ENV defaultsThen assuming you are operating in different directories you will be OK. I do this for my batch jobs, leaving the interactive one in the standard location.
stats gives you statistics of all pixels of a frame 'visible' through a set of windows defined in a separate file. You should imagine placing a flat mask on top of your frame with holes cut out of it corresponding to the windows of the windows file. This means that the binning factors of the windows frame are irrelevant. Then why are they needed at all? This is laziness .. I did not want to define another type of window. You should always use binning factors = 1 in the statistics windows file. This file is best defined using setwin.
I am not quite sure yet whether this is a bug or not. The key thing to realise is that any pixels in the bad pixel frame with a value above 0.5 counts as bad. In other words 0 = good. At least one instance of this problem was because all good pixels were being set = 1.
A couple of people have found that they cannot apply full-frame, unbinned calibration frames to their data. This should not be the case. Unfortunately this is the result of a fix for a problem I only spotted in January 2006. Essentially it seems that with binned data, the windows do not start at the expected X positions, but effectively seem to move out by 1 pixel (at least in xbin=2 binning). If the windows are at the edge, then they move out of the range even of full-frame images causing 'sub', 'msub' etc to fail. The fix is to trim off the pixels at the left and right edges either using 'crop', or easier by using the trim option in 'grab', 'rtplot' and 'reduce'.
Subs::Subs_Error exception: Cannot retrieve an unsigned int from int-type header itemsyou could be suffering from a simple problem caused by an upgrade when I have changed the internal data type of one of the parameters. The program then encounters a problem when reading an old file of defaults. The cure is easy. You simply delete the corresponding default file (and potentially the global defaults file). e.g. if using msub then delete ~/.ultracam/msub.def assuming that the default file is in the default location, or else $ULTRACAM_ENV/msub.def, and possibly also GLOBAL.def in the same directory.
You may sometimes encounter the following error: