Updated: 2000 September 11
The ANDICAM is a 2-channel instrument with separately configurable CCD and IR cameras. To enable efficient queue scheduling of observations, all data with ANDICAM are acquired by means of Observation Template Files (or "obs files" for short). Obs files define the instrument, detector, and target parameters and configurations needed to acquire a single observation. In this sense, an obs file represents the smallest schedulable "unit observation". For example, to take a single long CCD image while simultaneously taking a set of short IR integrations dithered between each IR image using the internal dithering mirror, a single obs file is created that describes the observing "sequence" to be followed by each channel of the instrument. The CCD and IR data-taking sequences described by the obs file are then executed in parallel by the Prospero data-taking program.
Each obs file consists of three basic blocks:
A "unit observation" means that the choice of filters and the base integration times for each channel are fixed, but multiple images with those filters and integration times may be acquired. Similarly, IR channel observations can be dithered between images using internal tip/tilt mirror. If observations with different filters or exposure times are required, the astronomer must create separate unit observations to build up the data set, each unit having its own obs file associated with it. Some examples are described below.
Obs files can be generated using the web form described in these pages, or by using interactive commands in the newest version of Prospero (v4.5 or later) at the telescope. In principle, you could create obs files by hand with an editor, but the format is very strict and any typing errors could cause your observation to fail. This help file describes how to use the web forms for creation, management, and submission of obs files for your program.
Once you have created all of the obs files for your program, you need to submit them along with detailed observing instructions to the queue manager for evaluation, scheduling, and implementation. This is done with a separate project submission form. See the Phase II Observing Program Electronic Submission Instructions for details.
[Contents]
Obs files are created in three steps using a multi-part web form. This form is accessed by logging into the Observing Preparation Tools pages, using the Project ID assigned to your project when it was approved for implementation and scheduling.
Step 1: Enter Target Information
The first step in creating a set of obs files for a target is to specify the information for the target proper:
After entering the target info, you will be given a blank form for entering the exposure parameters for the observations. As described above, obs files are used to perform unit observations with a given instrument configuration. These units can be combined into multi-part imaging "sequences" using Prospero scripts that execute each of the separate obs files in turn.
For example, to take BVI images of an object, you would create three separate obs files, one for each filter (B, V, and I). A filter change is an "instrument configuration change". You would then have the on-site observers execute the obs files one at a time by hand, or provide them with a Prospero script to execute them in a sequence (thus reducing three execution steps into one: executing the script). For programs that require a number of obs files executed in a particular sequence, chaining them together into scripts will enhance the efficiency of the observing (and eliminate the possibility of operator mistakes).
Once you have entered the exposure parameters for a given configuration, hitting the "Next>" button will then validate and analyze the entries.
You will next be shown a summary of the observation parameters you entered on the previous form along with an execution time analysis. At this point you need to review the parameters for errors. The project PI's are responsible for making sure that everything is correct before submission. You can use the browser's "Back" button to return to the exposure parameter entry form, make changes, and iterate until everything is ready before submitting the final obs file.
Execution Time Analysis
The exposure parameters you entered on the previous form are analyzed to make an estimate of the total amount of time that will be required to execute the requested exposures sequence. This estimate includes the unit integration times in each channel, number of images to be acquired, detector reset and readout times, IR mirror dithering motion overheads, etc., as appropriate. In general, the estimates are good to about 5% or so. The estimates do not, however, include instrument configuration overheads (e.g., changing filters or entering user parameters like the object name and coordinates), telescope configuration, etc. These latter will add to the total time it takes to execute your observation program. In general, instrument-related overheads add only ~10 seconds for each target/instrument change.
The estimates provided by the execution time analysis are meant to serve two purposes:
If you need to adjust any of the exposure parameters, use the "Back" button on your browser to return to the exposure parameter entry form in Step 2, make the changes, and then repeat the validation step. You can iterate as often as you like until you get things the way you want them. This way you avoid making lots of intermediate files that pile up on the disk (you can always clean up later with the Obs File Manager, but why make extra work?
It bears repeating that the estimates of execution times do not include such factors as the time required to setup the observation (e.g., setting the filters, exposure times, object names, etc.), nor do they include the computer-to-disk data-transfer times. They only provide estimates of the time it takes to perform those operations that occur from the moment the first exposure in the sequence begins until the last image is readout. All of the other configuration and data-transfer overheads cannot be predicted with any precision, the former because it depends critically on the previous configurtion of the instrument, and the latter because the inter-machine data-transfer system has a roughly factor of 4 range of transfer speeds (roughly 1Mb/sec to 4Mb/sec) governed by such ineffibles as the disk caching, how busy the up/downstream machines are, etc. As such, the queue manager has to empirically estimate any additional overheads based on past experience, and the adjust the queue schedule accordingly on subsequent nights based on how long it takes the observers to execute the program in practice (e.g., using the times reported by the nightly data logs).
Telescope pointing, target acquition, and guide-star acquisition/lock times are not known a priori, and largely treated as overhead absorbed by the observatory operations (everybody pays more or less equally averaged over time). However, if your program requires a lot of additional operations, e.g., many offsets around the target position between observations, it will cost you in terms of total execution time. If your program proves excessively costly in additional overhead, the queue manager will contact you regarding how to modify your program to make it more efficient. Difficult programs are difficult to schedule and execute. Keeping it simple is a virtue.
Name it & Save it
If everything is satisfactory, you are then asked to give the obs file a name. Each project is assigned a working directory for its obs files. The filenames of obs files should be simple and reflect as much as possible the contents of the file. For example, if the obs file is to acquire simultaneous V and H band images of a star cluster named NGC007, you might name the obs file ngc007vh. Choosing simple, unique, descriptive names will help the on-site observers execute your program. If you make complicated names that are hard to type, it will slow down the process; please keep it simple (the filenames are ultimately for them, not you).
After selecting a name, save the final obs file to your project's working directory by hitting the "Save Obs File" button at the bottom of the form. The obs file is stored on disk where you can view it later with the Obs File Manager (which also provides tools for renaming and deleting files). You will also be shown a copy of the final, saved obs file on your browser screen. We recommend that you print out your browser screen with the final version for your records.
The following are descriptions of the entries in the obs file creation forms. These entries are accessible from within the forms themselves by clicking on the highlighted item. If you have come to this page from the web form, remember use the "Back" button on your browser to continue filling out the form in progress.
On logging into the YALO Observing Preparation Tools pages, you need to provide your name and Project ID.
The first form asks for the target name and coordinates, and the imaging mode to be used. Project PIs (or their CoIs) are responsible for entering the target name and coordinates correctly. Neither the queue manager nor the on-site observers will enter, validate or correct target names or coordinates. Although if there are problems with your coordinates, the queue manager will be in touch.
You can enter up target names up to 60 characters long (including spaces), but only the first 16 characters will appear in the observing logs (all 60 will appear in the image FITS headers).
-00:00:32 +12:12:34etc. are valid declinations. Please do not enter decimal coordinates.
The default equinox is J2000.0 coordinates, and we would prefer that you precess coordinates to J2000.0 before entering them here. If you cannot precess the coordinates, enter the Equinox in the box provided (e.g., 1950.0 for B1950.0 coordinates; omit the "J" or "B").
If your target is a solar system object, enter approximate coordinates for the observing season to assist in queue scheduling, and remember to check the "Solar System Object" box next to the Target Name. All of the planets are already in the YALO telescope controller system, but for minor planets or planetary moons you will have to provide the queue manager with an accurate ephemeris. Contact the queue manager for instructions on how to submit ephemerides for solar system targets.
You may change the imaging mode used for a given target by returning to Step 1 with the Back button on your browser.
The second form asks you to enter the CCD and/or IR imaging exposure parameters for your target for the imaging mode selected. This includes filter selection, and setting up the dithering parameters for IR imaging.
An integration time of 0 seconds will result in a "bias" or "zero" frame being acquired. If you do not wish to take CCD images with this obs file, back up to the target info form and select "IR-only Mode" as the Imaging Mode.
NOTE: you cannot select 0 CCD images. If you do not wish to take CCD images with this obs file, back up to the target info form and select "IR-only Mode" as the Imaging Mode.
NOTE: You cannot select 0 IR images. If you do not wish to take IR images with this obs file, back up to the target info form and select "CCD-only Mode" as the Imaging Mode.
In general, co-adding is most useful when a target is sufficiently bright that you are restricted to very short integration times to avoid saturation, and so would need a very large number of single images to build up sufficient signal. Co-adding helps build up signal while producing a reasonable number of final image files, and with the additional benefit of a slightly reduced overhead penalty compared to taking a large number of single images. The cumulative readout noise penalty, however, is the same regardless.
To dither between images, check the "Dither between images" box, and select scale the dithering pattern ("dither scale") from the pull-down menu. The default dither scale is "10", which corresponds to a dither throw of approximately 5 arcseconds on the YALO 1-meter. Dither scales range from 10 to 100 in steps of 10 (5-50 arcsec in steps of 5 arcsec).
Once the exposure parameters have been entered in step 2, the obs file creation form generates the obs file and estimates the execution times for the CCD and/or IR images requested. You are asked to first validate your entries, using the estimated execution times to help adjust your exposure parameters to optimize your observations, and then select a filename for the obs file and save it to your project's working disk.
The estimated execution times give the approximate amount of real time required to execute the requested exposures, from the first detector array reset until the end of the last detector readout (not including any instrument or telescope configuration overheads). The various data-acquisition overheads were measured on 2000 September 6 with the current ANDICAM setup, and yield estimates based on our CCD and IR Array readout models that are accurate to within 5%. Be warned, your mileage *will* vary, so don't expend too much effort time optimizing out the last second of dead time in dual-channel observations - reality *will* have the last word. For those interested in factoring in instrument configuration overheads, at most this amounts to 10-seconds per observing template (assming change of name, filter, exposure time, and CCD binning factors). Telescope pointing, target acquition, and guide-star acquisition/lock times are totally up for grabs. If your program requires a lot of hand offsets around the field, it will cost total observation execution time. If your program proves excessively costly in overhead, the queue manager will contact you regarding modification of your program.
Each YALO project is assigned a private directory on the queue server for storing their observation template files.
This field asks you to provide a filename for your new obs file. The filenames of obs files should be kept simple, and reflect as much as possible the contents of the file. For example, if the obs file is to acquire simultaneous V and H band images of a star cluster named NGC007, you might name the obs file ngc007vh. Including the object name in the filename like this helps to ensure relatively unique names.
Filenames are case sensitive, and may contain only letters and number, no special characters (e.g., +, -, _, etc.) are allowed.
If the filename you provide will overwrite an existing obs file in your directory, you will be given a warning and asked to confirm that you really want to overwrite the existing file. Detailed instructions are provided if this occurs.
Note that the obs files will be given the .obs files extension automatically by the web forms, so you should not include a file extension with the filename you type in the box provided.
[Contents]
Once you have a set of Obs files created, you can later go back and edit them with the Obs File Editor. This form will read in the contents of a existing Obs file and let you modify the entries, either to replace an old Obs file or to create a new Obs file using an old one as a template. In cases where readout or overhead times change substantially (e.g., in September 2000), the editor can be used to re-evaluate old Obs files and modify them to reduce deadtime in DUAL mode.
The basic entries are the same as on the Obs file creation form described above. The one potential point of confusion is if you are editing an Obs file that was originally either CCD-only or IR-only imaging mode. In these cases, the editor form provides boxes for the unused channel (after entries for the active channel). These entries will be ignored unless you decide to change the imaging mode as part of your editing session. It's easier to try than read about, trust me, you'll figure it out.
The Obs File Editor forms are a new tool released on 2000 Sept 10.
[Contents]
After a while, you can get quite a collection of Obs files. To provide a way to manage these semi-sensibly, we have provided the Obs File Manager Form. The file manager is a table-based web form that shows you all of the obs files that have been created for your project, and lets you view, delete, or rename individual files. This lets you clean up after making your obs files, fix ugly filenames, etc., without having to go back through the creation or editor forms.
Obs files "deleted" from the active list are moved to the wastebasket for your project, where they are held until you decide to either delete them once and for all, or to "undelete" them and return them to the active list. If there are any files in your project's wastebasket when you open up the file manager, they will appear in a separate "wastebasket table" beneath the table of active files. This is a safety feature to prevent you from accidentally deleting obs files (you can delete them, we just make you think about it first).
Editing existing obs files is not an option during the early parts of the testing phases (the file parser is not working yet), but we hope to have something working eventually.
The instructions for using the File Manager are described in a separate document.
[Contents]
Example 1: I-band CCD Imaging
This is an obs file to take one 300-second CCD image of MB99018 with the I-band filter. The IR channel is kept idle during the observation (CCD-only mode).
# Prospero Observation Template File # Created: 2000 Sep 9 [13:35:50] by saveobs.pl Version 1.3 # For: R. Pogge # PROJECT=O39901 IMGTYPE=OBJECT OBJECT=MB99018 RA=18:01:07.7 DEC=-28:31:41 EQUINOX=2000.0 MODE=CCD # # CCD Imaging Parameters # # Estimated Execution Time: 379 sec # CCD: FILTER=0 # I EXPTIME=300.0 NIMGS=1 CCDBIN=1 ENDExample 2: IR K-band Imaging
This obs file takes a sequence of five (5) 60-second images at K of a Seyfert 1 galaxy, dithering between images with a dither scale of 20 units (about 10 arcsec). The CCD channel is kept idle during this observation (IR-only mode).
# Prospero Observation Template File # Created: 2000 Sep 7 [13:27:45] by saveobs.pl Version 1.3 # For: Rick Pogge (OSU) # PROJECT=O39901 IMGTYPE=OBJECT OBJECT=Mrk 1347 K RA=12:39:47.3 DEC=-23:27:16.0 EQUINOX=2000.0 MODE=IR # # IR Imaging Parameters # # Estimated Execution Time: 350 sec # IR: FILTER=3 # K EXPTIME=60.0 NCOADDS=1 NIMGS=5 DITHER=T DSCALE=20 ENDExample 3: Dual IR/CCD Imaging
This obs file takes simultaneous V and K-band images of 47 Tucanae, one 180-sec integration at V and three 75-sec integrations at K, dithering by a factor of 40 between IR images.
# Prospero Observation Template File # Created: 2000 Sep 7 [13:41:59] by saveobs.pl Version 1.3 # For: bailyn # PROJECT=Y20006 IMGTYPE=OBJECT OBJECT=47 tuc RA=00:26:00 DEC=07:02:22 EQUINOX=2000.0 MODE=DUAL # # CCD Imaging Parameters # # Estimated Execution Time: 259 sec # CCD: FILTER=6 # V EXPTIME=180.0 NIMGS=1 CCDBIN=1 # # IR Imaging Parameters # # Estimated Execution Time: 255 sec # IR: FILTER=3 # K EXPTIME=75.0 NCOADDS=1 NIMGS=3 DITHER=T DSCALE=40 ENDNote that instead of three 60 second integrations at K, the astronomer has increased the base integration time to 75 seconds to roughly equalize the amount of real-time required to execute the CCD and IR observations (259-sec compared to 255-sec for CCD and IR, respectively). Attempting to optimize the difference by more than 10-20 seconds, however, is usually a waste as this time can easily be consumed by various system latencies that are unpredictable (not all dual-channel operations can be made parallel).
[Contents]
If you came here from one of the entry forms, use the "BACK" button on your browser to return to the obs file generation form in progress.