A positive POS TARG moves the target along the POS TARG axis in a +X direction, so the detector will move in the negative direction on the image of your target. (See ISR 2010-09 "Dithering Strategies for WFC3" for more information).Figure 2: Illustrates the full detector apertures and the POSition TARGet coordinate system for the UVIS (left) and IR (right) detectors.
You can use Aladin to demonstrate the movement:
1) To see the HST focal plane layout, display an exposure in Aladin.
2) Click on the FOV icon in the APT window.
3) Zoom out until you can see the entire layout (Note: The orientation of this layout depends on the
ORIENT of the visit).
4) Create an exposure with no POS TARGs, then one with a POS TARG X or POS TARG Y.
5) Compare the exposures in Aladin.
At the moment aXesim does not allow you to do this directly. However, there is an indirect method which will achieve the same thing:
1) Use APT to simulate a given observation with a specific ORIENT.
2) Use Aladin to display the resulting field on the sky.
3) Use the coordinates of the sources listed by Aladin to create a catalog specific to that ORIENT.
4) Feed this catalog into aXesim.
5) Repeat for additional roll angles.
For the IR Grism the dispersion direction is in the +x detector direction (see Figure 2, right). When viewed with Aladin in APT
with an orient of 0, this ends up going from upper-right to lower-left. This is ~135 degrees relative to North up in Aladin.
One way to visualize is to draw a distance vector from the center
of the WFC3 array with a position angle of 135 degrees.
For the UVIS Grism, the dispersion direction is in the -x detector direction (see Figure 2, left). The same method works as noted above, but the the direction is 180 degrees opposite, that is,
~315 degrees relative to North up in Aladin.
Use the G280-REF aperture for the UVIS direct imaging. This places the target at the same location as in the dispersed images.
For the IR array there are 5 apertures to choose from:
GRISM1024 - Full frame G102 or G141 spectra
GRISM512 - 512x512 subarray
GRISM256 - 256x256 subarray
GRISM128 - 128x128 subarray
GRISM64 - 64x64 subarray
Selection of these apertures should be based on the science
goals of your program. Using a subarray is often related to
science goals in which one or a few bright objects are of
interest and rapid readouts are needed to avoid or reduce
saturation effects. It is important to keep in mind that as
smaller apertures are used, the extent of the grism spectra
becomes a consideraton.
In the case of full frame (1024x1024), 512x512, and 256x256 arrays, the direct image and grism image should use the same aperture, e.g. for full frame (1024x1024) observations use the GRISM1024 aperture for both exposures, for 512x512 use the GRISM512 for both exposures, for 256x256 use the GRISM256
for both exposures.
In the case of the 128x128, or 64x64 subarrays, the "reference pixel" is different for the direct and grism apertures. The
reference pixel in the direct image refers to the x and y
coordinate of the specificed RA and DEC. The reference pixel
will change in grism mode because that mode is designed to
make sure most or all of the +1 order falls within the aperture.
The user has two choices to assure that the direct and grism
images both contain the object of interest:
1) The reference pixels (desginated GRISM128,64 + Fnnn)
have been defined (see illustration below) so that the
grism aperture (e.g., GRISM64) can be used for both
grism and direct images (Fnnn filter). This requires a small
angle maneuever, subject to overheads and maneuver
inaccuracy (~10 mas). The offset between the Fnnn and
Gmmm exposures will be (-120, +22) and (-86,+22)
for G102 and G141, respectively. This is the default setting.
2) Use a 256x256 or 512x512 aperture (according to affiliated grism) and the SAME POS special requirement (as shown below). This involves no movement of the telescope, but does require greater data volume.
ExpNo Aper SpecEl SpecReq
1 GRISM128 G102
2 IRSUB512 F098M SAME POS AS 1
Yes, there is an APT "cheat sheet" addressing issues, including those specific to WFC3 that should aid in using buffer dumps.
Yes. The task simdata can be used to create simulated grism images without background signal, readnoise, or Poisson noise.
You need to set back_flux_disp = 0, RDNOISE=0, and exptime_disp=0.
If you wish to add realistic noise (poisson, readnoise, background levels, etc), one can use the task MKNOISE in the ARTDATA package of IRAF:
1) Use the WFC3 Grism ETC to estimate your background contribution.
2) Add the constant background value to the noiseless aXesim image and then scale by the desired exposure time.
3) Use the task MKNOISE to add Poisson noise and the appropriate readnoise (see the WFC3 Data Handbook)
Users have reported problems when running aXe tasks
from the STSDAS package in an IRAF v2.15.x installation. This appears to be due to incompatibility issues between the calls
made to IRAF tasks by some aXe routines and the 64-bit implementation of IRAF. The aXeprep and aXedrizzle tasks in particular seem to cause crashes. aXe version 2.3 contains new implementations of some aXeprep and aXedrizzle modules
that eliminates the calls to IRAF tasks and replaces them with equivalent calls to python, pyfits, and numpy operations.
Direct calls to IRAF from aXe tasks will continue to be replaced
in subsequent versions.
Also note, testing seems to indicate that if the command flprc
is used, this may clear “stuck” processes and avoid some
4.2) My observations were obtained using a sub-array mode, but aXe crashes when I attempt to process the data. Is there a workaround?
Observations taken in sub-array mode with either the UVIS or
IR grisms need special handling before processing with aXe. All
of the spectral traces, dispersions, and flux calibration
information used by aXe are based on pixel locations within the
full field-of-view (FOV) of each detector. Any object positions
given in sub-array coordinates will be misinterpreted. The workaround for this is to imbed the sub-array images into a
blank full-frame FITS image before doing any processing with
aXe. It is suggested that the values of the pixels outside of the original sub-array be flagged with DQ (Data Quality) values > 0
so those pixels will be ignored during processing.
DQ=4 (generic bad pixel) is the recommended setting to use.
Please note we will soon make available a script which will insert sub-array data into a full frame and set the DQ values correctly. Users will be notified when it is available.
The object list does not have to be created with SExtractor, users are free to use any object detection scheme they choose.
However, the catalog which is submitted to IOLPREP, and
used for aXe must contain the following columns:
And the Input Object List file (*_prep.cat) header must be formatted as follows:
# 1 NUMBER Running Object Number
# 2 X_IMAGE Object Position along x [pixel]
# 3 Y_IMAGE Object Position along y [pixel]
# 4 X_WORLD Barycenter position along world x axis [deg]
# 5 Y_WORLD Barycenter position along world x axis [deg]
# 6 A_IMAGE Profile RMS along major axis [pixel]
# 7 B_IMAGE Profile RMS along minor axis [pixel]
# 8 THETA_IMAGE Position angle (CCW/x) [deg]
# 9 A_WORLD Profile RMS along major axis (world units) [deg]
# 10 B_WORLD Profile RMS along minor axis (world units) [deg]
# 11 THETA_WORLD Position angle (CCW/world-x) [deg]
# 12 MAG_FNNNN Kron-like elliptical aperture magnitude [mag]
Where FNNNN is the pivot wavelength of the filter used for
the direct image. Please keep in mind that the fluxcube
method for contamination estimation uses the SExtractor segmentation map.
Prior to aXe Version 2.3 the aXeprep task will quit with an error
if your input source catalog has any entries with magnitude > 90. This value occurs when SExtractor is not able to compute a valid magnitude for an object. Beginning with aXe version 2.3 the
error has been modified to be a non-fatal warning and aXeprep
can successfully complete processing. Subsequent aXe steps
will skip processing for these objects based on the setting of the MMAG_EXTRACT parameter in the configuration file. If the magnitudes are incorrect this can also affect contamination estimates in subsequent steps.
4.5) How do I use the “dimension_info” parameter in the task IOLPREP for objects outside the normal field of view?
Section 4.1.2 of the aXe manual incorrectly describes the use
of the dimension_info parameter for the IOLPREP task. In
order to extend the coverage to objects outside of the normal
field of view, all values should be given as positive numbers.
For example, to extend coverage 100 pixels outside the left
side of the image use dimension_info=100,0,0,0. Or to
extend the coverage an extra 50 pixels outside all four borders
of the image, use dimension_info=50,50,50,50.
To compute a contamination estimate using the Gaussian
model, aXe needs to have a flux value for each source, which
is computed via one or more AB-magnitudes within some filters.
The pivot wavelength of each filter's throughput curve needs to
be encoded in the *.cat files. This is done by renaming the MAG_AUTO column, to MAG_Fxxxx, where xxxx is the pivot wavelength of the filter used (e.g. MAG_F1392 would be used
for direct images taken with the F140W filter). The pivot wavelengths for the WFC3 filters can be found in Table 6.2
(for UVIS) and Table 7.2 (IR) in the WFC3 Instrument
The model is used to provide an estimate of which pixels are contaminated by overlapping spectra from other sources. The
data array for the contamination model is contained in the 
extension of the 2D *.mef.fits file and as a binary table in the extracted 1D *.SPC.fits file. The contamination model is never actually subtracted from the data array at any point in the aXe processing. Users are cautioned that contamination models are unlikely to sufficient for accurate de-blending of spectra.
4.8) I’m a little confused about contamination model choices for aXecore. How do they differ and what do I need for each to work properly?
aXecore is a wrapper task for several low-level aXe tasks,
including estimating contamination due to spectra from other
objects in the field. You can pass one of three parameters to
the contamination keyword:
If the only imaging data you have for the sources comes from
the direct image, then you must use the gauss option. It
creates a Gaussian model of the source luminosity distribution
for each object using the A_IMAGE, B_IMAGE, and MAG_FNNNN
values (in AB mags) in the Input Object List file (*_prep.cat).
This is done for the zeroth and higher order spectra of each
source. The contamination model spectra are then subtracted
from each source they overlap. It is possible to use multiple
flux values for objects in the field. This requires adding
additional columns with MAG_FNNNN values (AB mags)
where _FNNNN is the pivot wavelength of the filter. These
additional flux values can come from sources other than WFC3
or HST imaging.
If you have several direct images of the field, then you can
use the fluxcube option which may provide a more robust
method for estimating contamination. The fluxcube option
uses both the morphologies and fluxes (measured in several
filters) of the sources to estimate contamination. There are
two important caveats:
1) direct images must have the same pixel scale as grism images;
2) the World Coordinate System (WCS) of the images must match.
The easiest solution is to use WFC3 images taken with the
same imaging array. However, it is possible to use ACS or
WFPC2 images if you process them with multidrizzle to
re-sample the data to the same pixel resolution as your grism
data. The fluxcube option requires several extra steps before aXecore is called (as outlined below):
1) Apply the task multidrizzle to the imaging data to create
*_drz files. The fcubeprep requires several multidrizzled direct images, and the segmentation map generated by SExtractor
(from the direct image) which corresponds to the object catalog used for extraction. ALL multidrizzled images and segmentation maps (*_wht files) must to be registered with each other. If the images were not obtained in the same visit then you will have to align them using a reference image with multidrizzle in order
to use them with fcubeprep (for more information on how to do
this see Chapter 6.3 in the multidrizzle handbook).
2) Create a file called dir_ims.lis which contains the
image name, central wavelength (pivot wavelength) and
zero point. For example:
f110w_drz.fits 1153.4 26.07
f140w_drz.fits 1392.2 25.39
f160w_drz.fits 1536.9 24.70
3) Make sure that the *_coeffs1.dat files associated with each
drizzled image is in the same directory as the file called dir_ims.lis and the *_drz and *_wht files.
4) At the prompt enter:
fcubeprep grism_image=‘f140w_drz.fits’ segm_image='f140w_wht.fits' filter_info='dir_ims.lis' AB_zero='yes' dimension_info=0,0,0,0
Note that dimension_info controls the effective area for the inclusion of objects in the task and AB_zero=‘yes’ uses AB
mags while AB_zero=’no’ uses ST mags. The task will then
create a file with a *_flt_2.FLX.fits suffix for each *.flt input
The last option is geometric. This method is quicker but
does not account for the amount of contamination, only that
pixels ARE contaminated. The information from the *.PET files
are used to determine which pixels suffer from contamination.
The aXeprep task applies several different operations to the
*.flt.fits file in order to put the data into the units expected
by aXe tasks. The norm parameter is used to normalize the
image data by the exposure time (i.e. convert from counts
to count rates) and the gaincorr parameter is used to apply
gain conversion (i.e. convert from DN to electrons). The
UVIS *.flt.fits data are in units of electrons (e-) and need
the norm parameter to convert to e-/sec. The WFC3 IR
*.flt.fits data are already in units of e-/sec and therefore
don't need the norm correction applied by aXeprep. Neither
the UVIS, nor the IR arrays need the gaincorr correction
If you have a very crowded field, it is possible that the
spectral trace of a faint object so heavily contaminated by
nearby, brighter sources, that all pixels for the faint spectrum
get flagged as unusable in aXedrizzle. This can lead to a divide-by-zero error in the drizzleobjects.py module
when running aXedrizzle. This error, along with other
instances of potential divide-by-zero operations, has been
fixed in aXe version 2.3.
The aXedrizzle task will crash if the total length of your environment paths + file names are greater than 80
characters. This is the result of legacy code in IRAF.
The dither.py module used by the axedrizzle task has
been updated in aXe version 2.3 to check the length of the
file names passed to the IRAF drizzle task and quit with a
useful error message if they are longer than 80 characters.
Users are advised to use short absolute or relative path names
4.12) Can aXedrizzle resample spectra with pixel sizes smaller than the native platescale (like multidrizzle can with imaging)?
Yes, it is possible to use aXedrizzle to produce spectra with
effective pixel sizes that are smaller than the native detector
pixels if small dithers were made during the observations to
recover sampling information. Note, that this refers to
DRIZZLE, and not MULTIDRIZZLE. Drizzling the spectra to a
finer resolution can be done by modifying the parameters "drzresola" and "drzscale" in the instrument configuration
(*.conf) file. For example, to produce drizzled spectra with
about half the normal pixel size for the WFC3 IR G141 grism,
you could set:
DRZRESOLA 21.75 (instead of the normal 46.5)
DRZSCALE 0.06 (instead of the normal 0.128254)
in the WFC3.IR.G141.V2.0.conf file. It is also possible to control certain other drizzle task parameters, such as
pixfrac (input pixel drop size), or scale (relative size of
the output pixel scale). This is done by adding these parameters
to the aXe configuration files. For example, you could add:
Note that you must have version 2.2 or later of the aXe
software for this to work properly. Previous versions had a
bug in the drizzle_utils.c module, which caused the
drizzled 2-d stamp images to be truncated in the X
(dispersion) direction when using non-standard DRZ values.
There was also a bug in the spce_output.c module that caused
the estimated errors to be too large for spectra extracted with oversampling. For more information on the parameters in
drizzle type help drizzle at the Pyraf prompt.
To guarantee that aXe extracts the spectrum vertically, you must set the following:
a) In your catalog file (*.cat) set the THETA_IMAGE column (column 8) to a value of "-90.0"
b) When you call axecore, use the keywords "orient=yes"
To guarantee that aXe extracts the spectrum using a specific aperture width:
a) The aperture diameter depends on the angle of the extraction (see 4.13 above to set that to vertical), the A_IMAGE, B_IMAGE
and extrfwhm keyword passed to axecore. For a vertical extraction, APERTURE DIAMETER = A_IMAGE * extrfwhm
b) In your catalog file (*.cat) make sure that A_IMAGE=B_IMAGE (column 6 and 7), i.e. they are set to the same value.
c) When you call axecore, set the keyword "extrfwhm=n"
where n is the value you have selected.
So for an extraction diameter of 20 pixels:
A_IMAGE = B_IMAGE = 5.0 and "extrfwhm=4.0" and you have selected vertical extraction only.
Yes, the dispersion, trace, and absolute flux (sensitivity)
calibrations are currently valid only for sources located
near the geometric center of each chip. Please see
ISR 2009-01 for more information.
5.2) Is there a difference in how 2-chip data (WFC3/UVIS) is processed compared to 1-chip data (WFC3/IR)?
Yes, because WFC3/UVIS contains 2 chips which are processed independently of each other with aXe. Like the method for the
IR array, first create a direct image of the entire field of view
(FOV) by running multidrizzle on a direct image, and then
run SExtractor to produce a catalog of sources with position information within the entire 4k x 4k field of view. The aXe
task iolprep can then be run on the source catalog to
produce catalog files for each of the individual direct image
-> iolprep direct_drz.fits f200lp.cat
This will produce 2 output *.cat files for each *.flt.fits file
that went into making the drizzled image. The
*_1.cat contains the sources on chip 2 and the *_2.cat
contains the sources on chip 1. You then construct an input
file list (e.g. G280.lis) that looks like the this:
grism_flt.fits direct_flt_2.cat,direct_flt_1.cat direct_flt.fits
Column 1 contains the name of the *.flt.fits grism exposure,
column 2 contains the list of chip1 AND chip2 catalog files (separated by a ','), and column 3 contains the name of the
direct image *.flt.fits file. The catalog files should reference
the locations of sources within the entire 4k x 4k FOV of the
UVIS channel. The aXe tasks will then determine on which
chip each source is located. Tasks like axeprep and axecore
are then run by listing the names of the configuration files for
both chips, such as:
-> axeprep g280.lis WFC3.UV.CHIP1.TV3_sim.conf,WFC3.UV.CHIP2.TV3_sim.conf ...
-> axecore g280.lis WFC3.UV.CHIP1.TV3_sim.conf,WFC3.UV.CHIP2.TV3_sim.conf ...
This will produce 2 *.STP (stamp) and 2 *.SPC (spectrum) files
for each of the 2 grism images, with filename suffixes of
*_2.STP.fits and *_5.STP.fits. Note that '2' indicates it's data
from FITS HDU 2 (chip 2 science image) and '5' indicates
FITS HDU 5 (chip 1 science image). More detailed information
can be found in the aXe manual here.