The shortest possible time per non-destructive readout is ~2.9 seconds for full-frame readout.
Another option is to use sub-array readouts, which shortens the exposure time per read. The first-order G141 spectrum extends ~130 pixels, so it's possible to use either a 512x512 sub-array or even a 256x256 sub-array, while still including the whole spectrum of your target. RAPID mode readouts with the 512x512 sub-array give you readout times of 0.853 sec, and with the 256x256 you can get down to 0.278 secs per read.
NICMOS Grism observations had the option for a "de-focus" mode. We do not allow this mode for the WFC3 grism, but a mode using spatial scans (to spread the spectrum in the cross-dispersion direction) is currently undergoing testing for implementation in the future.
There are several reasons why it is ill advised to skip the direct imaging for the UVIS Grism:
1) First, the 0th order trace is slightly dispersed and often saturated, making it difficult to centroid.
2) Second, while you can often (but not always) see the 0th order in the dispersed images these may be contaminated by spectra from close by sources (due to heavy order overlap and bent spectral traces), again making it difficult to centroid.
3) The calibration and data-reduction software we offer (
aXe) requires the position of the source(s). The most effective method to do this is to use direct images obtained in the same visit as the grism observations in order to process the data.
Therefore, to avoid problems, the standard procedure is to observe a direct image followed by a dispersed image. While it may appear less efficient to take a direct image for the UVIS, there is a greater risk of being unable to determine the correct solution without it. Please note that there are offsets between the position of the source on the direct image and the 0th order.
A resolution element corresponds to 2 pixels for the IR and 3 pixels for the UVIS.
Due to both the curvature of the spectra and the relatively high throughput of higher orders (predominantly the 2nd), 1st order spectra longward of 4000 Angstroms are likely to be overlapped by the 2nd order flux longward of 2000 Angstroms (see Figure 1 below). This is particularly important for “hot” sources.
Figure 1: Closeup of the postive G280 spectral orders on the UVIS detector (Figure 8.2 from the WFC3 Instrument Handbook).
The following are the recommended filters for direct imaging:
G280 F300X or F200LP for faint targets
G102 F098M or F105W
G141 F140W (F160W for red objects)
However, ISR 2010-12 contains measured offsets for all of the IR filters. Therefore, it is now possible to use any of the medium or narrow-band filters for direct imaging in cases where the target objects are very bright.
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
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.
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
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,
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)
Grism images do not use flat fields in the traditional sense.
Calwf3 only applies a unity flat to the grism data. While this flat does not change the Q.E. variations, it does modify the pixel values to correct for relative changes in gain for each quadrant.
Grism images require the use of a 3-d flat field cube, which contains the flat field value at each pixel as a function of wavelength. This is applied by the
aXe spectral extraction to the flt images produced by
Calwf3 once each 2-d spectrum in the image has been identified and extracted. It's only at that point that you know the wavelength of the light falling on a given pixel and therefore can interpolate within the 3-d flat field cube to obtain the correct value to use.
To produce data in calibrated units of ergs/sec/cm2/Angstrom you must divide your extracted counts (in e-/sec) by the values in the SENSITIVITY column of the sensitivity files. The pixel size must be accounted for when applying the grism sensitivity function. This is done by dividing the spectral data by the dispersion per pixel (i.e. Angstromss/pixel).
The sensitivity files for the three grism settings, including different orders, can be found at the following links:
Yes, it is possible to use the IRAF task
noao.onedspec.scombine to combine multiple extracted spectra for a given source. The task
odcombine, also in the
noao.onedspec package, can also be used for this and allows for the use of bad pixel masks.
Yes. It is possible to use a program like
multidrizzle on grism/prism images to find and mark CR hits, which will then be rejected during subsequent
aXe processing. To do this, first run
multidrizzle on the original *.flt.fits files for the grism/prism exposures. This will place CR flags into the DQ arrays of the *.flt.fits files for pixels found to contain CRs. You can then either use these modified *.flt.fits files as input to
aXe, but it's usually best to copy the updated DQ arrays into "fresh" copies of the *.flt.fits files (i.e. ones that haven't been modified in any way by
multidrizzle processing) and use those as input to
aXe. Note that
aXe processing can NOT be performed on the drizzled versions of grism images that come out of
multidrizzle, because all of the spectral trace and dispersion solutions are based in the distorted geometry of the *.flt.fits files, not the geometrically-corrected space of drz files.
In principle, yes. One could use tasks in the IRAF
imred.ccdred package such as
badpiximage to detect and mark CRs and then assign these the appropriate DQ value (see Table E.2 in the WFC3 Instrument Handbook). Then copy this image into the *.flt.fits files that will be used by
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
aXedrizzle tasks in particular seem to cause crashes.
aXe version 2.3 contains new implementations of some
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 crashes.
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]
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.
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.
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
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 Handbook.
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.
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
gaussoption. It creates a Gaussian model of the source luminosity distribution for each object using the
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 thesame 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 grismdata. 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
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 eachdrizzled 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
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 grism image.
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.
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 applied.
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.
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 for:
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
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
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 *
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
=n" where n is the value you have selected.
So for an extraction diameter of 20 pixels:A_IMAGE = B_IMAGE = 5.0 and
=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.
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
iolprep can then be run on the source catalog to produce catalog files for each of the individual direct image (*.flt.fits), e.g.:
-> 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
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.
aXe (src/drizzle_utils.c, 40):
Fatal: Order of dispersion solution: 4!
At most quadratic solutions are allowed!
aXeError: An error occurred in the aXe task: aXe_DRZPREP
drzprep task can only handle spectra with dispersion solutions up to a 4th order polynomial. The WFC3 G280 grism uses a 5th order dispersion solution. Therefore, at present, G280 grism data can not be processed with
Just like the
aXedrizzle can only handle spectra with dispersion solutions up to a 4th order polynomial. The WFC3 G280 grism uses a 5th order dispersion solution andG280 grism data can not be processed with
Version 1.3 Sep 2011