Service Observing Description
Please read this and follow the
instructions carefully.
We will do our very best to get the observations you want, but for
that we need to know what you want. Therefore, we ask you to carefully
read the below and follow the instructions in detail. If you have any
questions or comments, please contact service!
Introduction
The general aim of service observing in flexible queue mode is to use
observing time in an efficient way. For this to be successful we need
to be sure that the observations provide useful data. An important
part of this is to provide a way (for the PI) to define the
requirements of the observations, and (for us) to make sure that
observations meet the goals of the proposed programs.
For this we have set-up a system of Observing
Blocks which define the requirements for a set of observations.
The general philosophy is similar to that for OBs as defined by ESO,
but in our case the main aim is to administrate the scheduling and
execution of the service observations, which are done by us manually,
instead of a direct link to a complete observing system as part of a
data flow system.
Overview
Observations are divided in Groups. Each
group consists of a set of observations which must be executed in a
single night (e.g., an object and a standard star). Each group
consists of one or more Observing Blocks
(OBs) which define the details of the instrument set-up and the
exposure(s) (in the form of (an) observing
script(s)). By definition, an OB consists of a preset to a
single object with observations using a single instrument.
All Groups and OBs for a single program are linked by the proposal ID
and the overall hierarchy in the system is:
-> one Proposal
-> one/several Groups (single night)
-> one/several Observing Blocks (single target, single instrument)
-> one/several exposure(s) (as defined
in an observing script)
E.g., observations of the same object with NOTCam and StanCam would be
split over two OBs which could be in the same group if they have to be
observed in the same night. If repeated observations are required of
the same OB, create as many OBs as needed and place them within the
same group. Also, if you want to make the same observations on
different nights you can submit several groups with the same
telescope, instrument and exposure definitions as defined in the OBs
and observing scripts, but with different group names (e.g.,
`target_obs1', `target_obs2', etc.).
The system is meant to cover the most typical observations, but does
not cover all possibilities. However, comment
fields are provided in the OB and Observing Script forms to specific
any special requirements for the requested observations.
In general, OBs will be executed one at the time, the selection order
being based on the observing conditions and the requirements for the
OB. Each OB will only be executed once.
Please read the instructions below and fill out the appropriate forms.
Instructions
For the details of the individual (sets of) exposures we provide an
Observing Script generator, which includes an
execution time estimator. In the script generator you should enter the
proposal number for which the observations
are defined, and you should specify the observing
mode (either being imaging, spectroscopy or polarimetry) and
the image type (either being a regular
observations, a standard observation or a calibration observation),
which will set some FITS keywords. This will make it easier to manage
the observations taken for different proposals, and will allow to
share calibration observations among observers.
Make Observing Blocks and Observing Scripts by using the forms below. Save
the forms on your local disk, reload and edit them if you want. When
you are satisfied with the result, put them together in a tar file and send it as an email attachment to service with the proposal number as
subject. Don't forget to make OBs and scripts also for your
standard object observations.
A new web form has been developed where
target coordinates and target acquisition information (primarily the
required position angle) can be provided together with a finding
chart. When the form is submitted a sequencer script is generated that
will point the telescope, acquire the guide star and displays the
finding chart before the prompt is given back so observations such as
acquiring a target on a slit or simple imaging observations can be
started immediately after the script. You are strongly encouraged to
use this facility which is provided here. Note
that some of the information is the same as requested in the Observing
Block form discussed below. In case you want to provide more than one
finding chart you can either include it in the tar file, in which case
they should have the name of the OB they belong to, or it can be sent
directly to service with the
proposal number and name of the OB as subject.
The day before and after the the Service Observing night, appropriate
twilight, dome and/or internal lamp Flat fields
will be obtained by our staff for the different instrument
set-ups used during the night.
Upon successful ingestion of your Observing Blocks into our system,
you should receive an email confirmation. If you do not recieve the
emails within a week or so, please notify service
I - Observing Blocks (OBs)
Each OB should contain what the PI considers a useful/significant set
of observations. The total length of each block should be considered,
since the observations in one block are executed as a whole and will
not be divided up further. Detailed information about the different
overheads that should be taken in to account in the execution time of
an OB can be found here.
If you need the data to be obtained at the same time (e.g. variability
study), then put the OBs in one Group. However, the longer execution
time a Group needs, the less chance there will be that it is possible
to schedule the observations in flexible queue mode, so this needs
some balancing by the PI.
Any specific requirements you have for the execution of (a Group of)
OBs you should specify under comments .
For each OB the following information should be provided (links with
instructions for each item are also provided in the form):
- Proposal ID
- Observing Group name (no naming
restrictions)
- Observing Block namee (no naming
restrictions)
- Instrument used (currently ALFOSC,
NOTCam WF,NOTCam HR, FIES or StanCam)
- Observing conditions: maximum allowed
seeing (Any/1.3/1.0/0.7 arcsec); whether you need photometric conditions or so-called clear sky is sufficient, or you allow some
thin cirrus clouds; Moon phase
(Any/Grey/Dark); and visibility period given as useful LST
range. This refers to the time period (local sidereal time) when
you consider your target visible/observable, i.e. here you can
decide to limit the airmass if you want . Here one has to
consider to total execution time of the OB. Note that this range
must always be specified, otherwise you risk having your target
scheduled when it is at high airmass or not visible. Check
visibility by using e.g. the ING Staralt
Visibility plot form
- Object name (must begin with a letter,
and may not be longer than 20 characters. It may only contain
following characters: a-z, A-Z, 0-9), Coordinates (RA hh:mm:ss.ss, Dec
dd:mm:ss.ss ), Epoch (e.g., 2000.0) and the Position Angle
(in degrees) needed for the observations. If you require to
observe at the Parallactic Angle at the time of the observations,
enter PA as value.
If no finding chart is provided we will point the telescope using
the coordinates above. One should consider that in this case,
apart from any error in the coordinates themselves, the pointing
of the telescope can be off by maximum ~15 arcsec
- Specify the sequence of observations to
be executed as part of the OB. The basic concept is to provide in
each line a set of observations with a single instrument
set-up. Provide per line the observing mode (IMA, IMAPOL or
SPEC), the script name (see below), the instrument set-up used,
and an offset (in arcsec) to be executed at the end of each
script. There is no limit to the number of lines (i.e.,
exposures/scripts) you can give. Also, the same script can be
called more than once.
Note that the observing mode (either
being imaging, spectroscopy or polarimetry) and the image type (either being a regular
observations, a standard observation or a calibration
observation) can be defined in the observing script (see
below).
There are the following options:
- Imaging
IMA <script name> <filter>
<offset X> <offset Y>
e.g., 'IMA NGC1234 Ks 10 10' corresponds
to a set of exposures defined in the observing script (see below)
called `NGC1234' using the Ks filter. The name of the exposures
as given in the object FITS header
keyword is defined in the script. After the execution of the
script, an offset of +10 arcsec will be made along both the X and
Y direction on the detector. The direction on the sky of these
offsets depend on the Positional Angle used (see the instrument
web pages).
- Imaging polarimetry (not with StanCam, NOTCam)
IMAPOL <script name> <filter>
<polarization> <offset X><offset Y>
where <polarization> refers to
either Linear or Circular polarization observation.
For ALFOSC this defines the retarder
plate that is used and the angles at which the observations are
taken. For Linear polarization the half
wave plate is used at rotation angles 0, 22.5, 45 and 67.5
degrees. For Circular polarization the
quarter wave plate will be used at rotation angles 0, 90, 180 and
270 degrees. Note that the retarder plate cannot be changed
during the night, and only Linear or Circular polarization
observations - but not both - can be done during a single night.
E.g., `IMAPOL NGC1234 V LIN 10 10'
corresponds to 4 times executing the exposures defined in the
observing script (see below) called `NGC1234' with the V filter,
using the half wave plate at rotation angles 0, 22.5, 45 and 67.5
degrees, respectively. The name of the exposures as given in the
object FITS header keyword is defined
in the script. After the execution of the script, an offset of
+10 arcsec will be made along both the X and Y direction on the
detector. The direction on the sky of these offsets depends on
the Positional Angle used (see the web pages for each
instrument).
- ALFOSC and NOTCam Spectroscopy Finding
chart mandatory!
SPEC <script name> <grism no.>
<slit width> <order sorter filter> <offset X>
<offset Y>
E.g., `SPEC NGC1234 #4 1.0'' none 20 0'
corresponds to executing the exposures defined in the observing
script (see below) called `NGC1234' with grism #4, using the 1.0
arcsec slit and no order-sorter filter. The name of the exposures
as given in the object FITS header
keyword is defined in the script. After the execution of the
script, an offset of 20 arcsec along the X direction on the
detector will be made, which for standard slits is along the slit
(e.g., to nod along the slit as required in IR spectroscopy, or
in general to be able to define a second exposure in the next
line of the OB at a slightly different position on the
detector).
Note that for spectroscopy with NOTCam one should consider to
include the observations of a nearby telluric
standard to cancel atmospheric absorption features (and
fringes) in the data. This can be done in a separate OB in the
same Observing Group.
For night-time calibration observations use:
SPEC_CAL <script name> <grism no.>
<slit width> <order sorter filter> <lamp>
<offset X> <offset Y>
where <lamp> refers to the lamp(s)
used, e.g., (for ALFOSC) the He, Ne, ThAr or Halogen lamp, where the last one is used for
internal flat fields. More than one lamp can be used at the same
time, which should be indicated by joining them with a '+' sign,
e.g., He+Ne. After the execution of the
script, an offset in the X and Y direction on the detector will
be made, which for standard slits is along and perpendicular to
the slit, respectively. In this way one might take an object and
calibration exposure at the same position before offsetting the
telescope and taking another set of object and calibration
exposures.
In the observing script it can be indicated if these are Flat Field or Wavelength
Calibration observations which will be reflected in the
FITS keywords. These observations might be useful to other
observers. The name of the exposures as given in the object FITS header keyword is defined in the
script.
- FIES Spectroscopy Finding chart mandatory
for faint targets!
SPEC <script name> <fiber mode>
<stancam filter> <offset X> <offset Y>
E.g., `SPEC FaintStar low-res R 60 0'
corresponds to executing the exposures defined in the observing
script (see below) called `FaintStar' with the low-resolution
fiber, and using the `R' filter with StanCam to center and
maintain the object in the fiber (as long as the ADC is not
installed differential diffraction can play a role and the
effective wavelength at which the star is centered in the fiber
is of importance). The name of the exposures as given in the
object FITS header keyword is defined in
the script. After the execution of the script, an offset of 60
arcsec along the X direction on the detector will be made, e.g.,
to take a separate sky spectrum.
For night-time calibration observations use:
SPEC_CAL <script name> <fiber mode>
<lamp>
where <lamp> refers to the lamp
used, being either ThAr or Halogen lamp. In the observing script it can
be indicated if these are Flat Field or
Wavelength Calibration observations
which will be reflected in the FITS keywords. These observations
might be useful to other observers. The name of the exposures as
given in the object FITS header keyword
is defined in the script.
If you have several repetitions of the same script in imaging, we
recommend a random offset of 5-10 arcsec between repetitions.
However, the offsets at the end of each script can also been used
to make mosaic patterns, beam-switching, or any other pattern you
want. You should indicate here for the whole OB if you want to
use autoguiding or not. Note that autoguiding should not be used
with large offsets (~240 arcsec)
- Total execution time for this OB. The
execution time for each individual script is given as output from
the script generator (see below). The read-out time of the
detector is included in the execution time, but is less for a
windowed CCD (see instrument web page). For
polarimetry observations remember that the observing scripts will
be executed 4 times.
For an OB with imaging observations, allow for 3 minutes for
target acquisition, and for an OB with spectroscopic observations
allow 5 minutes. More detailed information about the different
overheads can be found here.
Sum up all these numbers as estimate of the total execution time.
It is important that this estimate is reasonably accurate as it
is used to decide if a (Group of) OB(s) can be executed (e.g., is
there sufficient time to left to finish the OBs before the end of
the night)
- Critical dates for the execution of
the OB. Normally this is left blank, but in case the observations
should be executed at a specific date this should be indicated.
Note that this date refers to the START of the night during which
the observations need to be executed (which in some cases might
be after midnight, i.e., the next calendar day). Multiple dates
can be given when the observations can be executed at one of a
number of specific dates. Note that the OB
would be only executed once and the use of `critical dates' only
applies when the observations should be executed on one of the
indicated dates. If you want the same (kind of) observations to
be executed on several (specific) dates, separate OBs/Groups
should be prepared.
More detailed information like the required precise timing of the
observation during a given night (e.g., to cover an eclipse in a
binary) should be indicated in the `Comments' field. Note that
these specific dates will apply to all OBs in the same Observing
Group. If more than one OB in a Group contains a list of specific
dates only those dates that coincide will be valid.
- Comments concerning the (Group of)
OB(s). In general the idea is that the comments should allow us
to make a better judgment when deciding to perform the
observations.
E.g., defining the daytime or twilight calibration exposures that
are required; defining a window on the detector for the
observations; noting that there are related OBs (e.g., exposures
of a Galaxy in a different filter) that are not in the same Group
as they do not need to executed on the same day; noting that
there is a very bright source close to target (please, consider
darks in between to clean the array); give specific times for
the execution of the OB in case it is time critical; all the OBs
in this group should be executed one after the other in the
following order:... ; etc.)
II - Observing Scripts
The details of the observations themselves should be provided in the
form of Observing Scripts . We have provided
a script generator which will generate a script given the requirements
for exposure times and dither pattern. Not that a script can consist
of a single exposure. To make the execution and managing of the
observations and the resulting data easier, one should define in the
script the observing mode and the image type. Each script should have
a unique name, and the name(s) of the script(s) that have to be
executed should be given in each OB (see above).
For each script the following information should be provided:
- The name of an observing script should
not contain any spaces and has a maximum of 16 characters. Note that
the script name will be part of the object
fits header keyword (followed by a number corresponding to the dither
position), and we suggest to use as much as possible descriptive names
like AlphaCen_J or
NGC1234_V .
Please indicate the proposal number, observing mode (Imaging [default], Spectroscopy,
Linear Polarimetry, Circular Polarimetry) and image
type (Object [default], Standard, Flat Field, Wave Calib.),
such that type of observations is clear and the observer and imagetyp FITS
keywords are set properly.
- Decide on the dithering pattern. For
point source fields without any extended emission the simplest
procedure is to select one of the standard dither patterns
provided.
You can select the dithering step size in RA and DEC (in
arcsec), but the pattern is predefined as shown by clicking on Information. You can also make mosaics with
these patterns by selecting large offsets, but note that autoguiding
must be OFF in this case. Note that the coordinates you provide refer
to the center of these dither maps.
For NOTCam, you may also use the template scripts
notcam.9point and/or
notcam.5point, in which case you are allowed to vary the skew'ing
of the dither grid. Remember to add your choice of all the input parameters
to these available dither scripts. Thus, in the OB form under script,
for instance give: "notcam.9point frame 10 6 my_object 10 2 1" instead of
your own "myscript.script".
For extended targets where you want to use beam-switch observations in
certain direction(s) you can use the No Dither
option in the script generator and add the exact offsets you
want in your OB definition. Here you have full control of the
offsets, and you can include small step dithering at each position
(i.e. both target and sky). For NOTCam you may use the template script
notcam.beamswitch. As shown above, give the whole command with
your selection of input parameters. NOTCam beamswitching should be used
with autoguiding.
The No Dither option can also be used if
you want to make small random offsets for point source targets. Also,
there is the flexibility in the OB form to put in random offsets
between mosaics or dither patterns that you repeat a number of times
(this is strongly recommended, but make sure you are not wandering
away from the target in the long run). The offsets
are relative to the current telescope position.
- Use the SIGNAL
program to estimate the total integration
time needed to reach the required signal to noise. Then use
the
Observing Script Generator to find the total
observing time needed, including
overheads. The preview button will show you
the script that is generated from your input. This includes an estimate
of the execution time of the script that can be used to estimate the
total time needed to execute an OB (see above).
For NOTCam, decide on the readout mode to use and the combination of
't' and 'N' for either 'frame t N' (ramp-sampling mode) or 'mexp t N' (reset-read-read mode). This is a balance between
background levels, seeing, staying in the linear regime and optimizing
the observing efficiency (check the overhead calculated by the script
generator). Note that linearity is good to about 1% only up to 20000
ADUs, and it is recommended to observe within this range (although the
non-linearity has been calibrated and can be corrected, see
NOTCam calibrations).
The latest version of the
SIGNAL
program (Exposure Time Calculator) includes the estimated peak
level (in ADUs) for your input choice of seeing, as well as the
possibility of dividing up the total exposure time in multiple frames.
Note that for ramp-sampling mode, the result of the exposure command
frame t N is to be treated as one single image of exposure
time t x N.
It is recommended to use the ramp-sampling mode
with many readouts both for efficiency and to limit the pick-up noise,
unless short exposures are required.
If, in very good seeing, the maximum count
levels get to values above 20000 ADUs, one can still use one of the
earlier read-outs (with lower counts) provided when using the ramp-sampling mode.
|
