Changing your mind about the recipe

Or - the DR keeps complaining about the flat and exiting

Occasionally, you will find that for some reason, the recipe that you specified whilst you were using the OT is nolonger appropriate, but you've allready started taking data with that recipe. This will usually be brought to your attention by the fact that oracdr will complain that it's unable to reduce the data and will exit. Normally, this is due to the absence of a pre-requisite for the recipe that you have specified. Most of the recipes use a flat field, and will fail if there is not one availiable. The target recipes that attempt to divide by a standard star observation and flux calibrate the data will fail if there is no suitable standard star.

There seem to be a few common reasons why this occurs:

• You're convinced that you have taken suitable calibration data, but oracdr refuses to use it for some reason.
• Your obsject is about to set, so you intentionally deffered taking flat, arc and standard star observations untill after your object frames.

Starting with the first case. Oracdr will tell you why it is refusing to calibrate, even though it can be a bit crypic sometimes.

First a note on notation. We refer to flats, arcs and other similar frames as calibration frames.

The first thing to check is that oracdr knows about the calibration data which you consider to be suitable. The pipeline keeps an index of calibration frames, and looks to this index to find a suitable one when it needs one (eg to flat field some new data). It adds the details of calibration frames to this index as they pass through the pipeline, therefor if the frame (say the flat field) hasn't been reduced by the pipeline - say for some other reason you didn't have the pipeline running when you took the flat field data, the oracdr doesn't know about the frame and thus won't use it. Simply pour the calibration data through the pipeline with a command like oracdr -list NN where NN is the frame number of say the flat field, then restart the pipeline on the frame where it fell over. If you did a sequence like Flat, Arc, star, target, then you might want to simply re-start the pipeline from the start of that sequence - ie oracdr -loop flag -from NN.

If the pipeline has processed the calibration data, but still refuses to use it, examine the output of oracdr to find out why it refuses to use it. Whe oracdr requires a calibration frame, it works backwards through it's index file of that type of frame (eg flat fields. The actuall index is a human readable text file - in this case index.flat in your reduced ($ORAC_DATA_OUT) directory), checking the headers of the indexed frames against a rule set to see if they are suitable. It will use the most recent frame that matches the rules for use. Typically, the rules file specifies that the optical configuration must be the same for the calibration and data frames - ie the grating, order, wavelength, etc etc must match. With CGS4 there is the added complication that if you move the motors to change from one optical configuration to another, then attmept to move back to the original, the optics will be at slightly different positions, simply due to the inability of the motors to position that accurately. This effect is such that flats and arcs taken before the change and change-back are NOT suitable for calibrating the data. Therefor we have this concept of a configuration index - the CNFINDEX FITS header. This is simply an integer which gets incremented each time an optical configuration motor is moved. We demand a CNFINDEX match between data and calibration frames to be sure of suing appropriate calibration frames. Therefor if you took flats and arcs then moved the motors (perhaps something failed and you had to re-datum, or you accidentally ran the wrong sequence), you need to re-do your flats and arcs.

OK, now onto the second case where you deliberately don't have the calibration data because you decided to defer those observations untill after you'd observed your target (most likely because it's setting on you, or there's some other time-critical constraint). Now, or course, it's impossible for the DR to do the normall reduction sequence, but you still want it to display your data s it comes in, as best it can, so that you can see how you're doing. The best way to do this is to specify an alternate recipe wih which to reduce the data. Note. This doesn't change the recipe specified in the headers of the data files, it simply forces oracdr to use a specified recipe for the moment. The recipies you are most likely to want in this situation are the ones ending in _NOSTD (it it's trying to divide by standard and flux calibrate, yet you don't have the standard star observations yet) or the ones ending in _NOFLAT if you don't have a flat field yet.

Later on, when you come to re-process the data after you've taken the necessary calibration data, all you have to do is reduce the calibration frames before the target frames, by means of the -list option to oracdr, then when you process the target data, it will use the originally specified recipe, with the correct (albeit taken later) calibration frames.