STScI Logo

Hubble Space Telescope
WFC3 Grism Frequently Asked Questions


If you cannot find answers to your questions on this page, do not hesitate to contact our Help Desk.

Questions

Phase 1 Proposal Preparation

Phase 2 Proposal Preparation

Data Analysis Questions

aXe Related Data Analysis Questions

G280 (UVIS) aXe Data Analysis Questions

Answers

Phase 1 Proposal Preparation

1.1) My targets are bright in the near-IR. What is the shortest exposure time that can be used for the WFC3 IR array?

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. See the Section 7.7.4 of the WFC3 Instrument Handbook and the Phase II proposal instructions (section 14.3.6) for more info about the use and timing of IR sub-array readouts.

An alternative observing mode for bright object is Slitless spectroscopy with spatial scanning. In this mode, the telescope moves at a constant speed in the spatial direction during the exposure. By spreading a stellar spectrum perpendicular to its dispersion, more photons can be collected per exposure, and the exposure times can be longer without saturating the detector. The most prevalent scientific application is transit spectroscopy, in which a time series of stellar spectra are obtained before, during, and after an exoplanet transit or eclipse. See Section 8.6 of the WFC3 Instrument Handbook for details on this observing mode.

1.2) Why do I need a direct image accompanying the grism observations?

Grism observations with both the UVIS and IR grisms should always be accompanied by a direct image, which is used to locate sources and determine source sizes. While in limited cases it may be possible to use the 0th order spectra to determite the wavelength scale (see ISR 2015-10), this is not recommended for most observers. There are several reasons why it is ill advised to skip the direct imaging:

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.

At least one direct image should be taken during each visit, however two are recommended for cosmic ray rejection.

1.3) What are the recommended filters for direct imaging accompanying the grism observations?

The following are the recommended filters for direct imaging:

GrismFilter
UVIS G280F300X or F200LP for faint targets
IR G102F098M or F105W
IR G141F140W or F160W for red objects

However, configuration files are now available for most grism-filter combinations. Therefore, it is possible to use any of the medium or narrow-band filters for direct imaging in cases where the target objects are too faint in the recommended filters or the scientific goals of the program are better suited by a different direct imaging filter. The offsets between different filter are listed in ISR 2010-12. See ISR 2014-03 for the effect of the time-variable background emission due to metastable helium in the F105W filter.

1.4) What is the assumed size (in pixels) of a "resolution element?

A resolution element corresponds to 2 pixels for the IR and 3 pixels for the UVIS.

1.5) What is the wavelength range of the 1st order of the UVIS G280 grism that is unaffected by overlap from higher orders?

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.

uvis trace closeup
Figure 1: Closeup of the postive G280 spectral orders on the UVIS detector (Figure 8.2 from the WFC3 Instrument Handbook).

Phase 2 Proposal Preparation

2.1) Which direction will a POS TARG move my target?

You can use Aladin to demonstrate the movement of the target with POS TARG (POSition TARGet):

  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.

2.2) How do I calculate the ORIENT angle (for APT) from the ORIENTAT angle?

The ORIENTAT angle is the angle between the detector y-axis and North, measured counter-clockwise (from North through East, i.e., the common definition of “position angle"). APT requires users to enter a different angle in the section Visit Orientation Requirements, which is called the ORIENT angle and is a measure of the roll angle of HST (see Section 7.2.2 of the Phase II Proposal Instructions). The ORIENT angle can be computed from the ORIENTAT angle using the following equations.

The equation for WFC/IR is:
ORIENT = (ORIENTAT + 135.37)

For UVIS it is:
ORIENT = (ORIENTAT + 137.18)

For the case of the spectral dispersion axis, which is roughly along the +x detector direction (-x for UVIS) and therefore -90 degrees (+90 for UVIS) offset from ORIENTAT (again, with the north through east convention), these become:

For IR:
ORIENT = (PA_DISPERSION + 225.37)

For UVIS:
ORIENT = (PA_DISPERSION + 47.18)

A detailed description of the ORIENT angle is available in Chapter 7 of the Phase II Proposal Instructions manual.

2.3) What aperture should be selected for the grism direct images?

UVIS Channel:

Use the G280-REF aperture for the UVIS direct imaging. This places the target at the same location as in the dispersed images.

IR Channel:

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 the 1024x1024 (full frame), 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. (Note: The G102 and G141 grism spectra extend for 155 and 135 pixels, respectively. Subarrays smaller than 256x256 will not fit the complete spectrum.)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 (corresponding to the 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

Figure 2.

2.4) Which UVIS chip should I use for a single target?

The UVIS 2 chip has ~3% higher sensitivity between 2000 and 2500 Angstroms. For a single target we recommend using Chip 2.

2.5) Are there any guidelines for using parallel buffer dumps in APT?

Yes, there is an APT cheat sheet addressing issues, including those specific to WFC3 that should aid in using buffer dumps.

2.6) How do I visualize the dispersion direction of the grism in Aladin?

For the IR grism the dispersion direction is in the +x detector direction. When viewed with Aladin in APT with an ORIENT of 0, this ends up going from upper-right to lower-left (see Fig. 3 below). This is ~135 degrees east of north as indicated in Aladin. When viewing WFC3/IR footprints in APT/Aladin, keep in mind that the “death star” indicated with the small circle is at the bottom (y~55) of the detector, left of center (x~360), which can help one visualize the dispersion axis as indicated in the figure.

For the UVIS grism, the dispersion direction is in the -x detector direction. In terms of Fig. 3, it is roughly 180 degrees offset from the +x direction as indicated, or ~315 degrees east of North for ORIENT=0. Unfortunately there is no feature for UVIS in the APT Aladin footprint analogous to the IR death star.

APT_orient0.png
Figure 3. Illustration of the relationship between ORIENT, ORIENTAT and the dispersion direction for WFC3/IR (top left) and WFC3/UVIS (bottom right).

2.7) How do I simulate roll angles in aXesim?

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 an alrternative method for simulating different roll angles, see the LINEAR software library developped by Ryan & Casertano.

2.8) Is it possible to generate a noiseless simulated grism image with aXesim?

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)

General Data Analysis Questions

3.1) Is my data good and how can I identify common problems?

The images below illustrate good quality data from each of the three WFC3 grisms (UVIS/G280, IR/G102 and IR/G141). These observations are all from extragalactic programs (GO-11594, GO-14227 and GO-12177).

UVIS G280 good data. IR G102 good data. IR G141 good data.
Figure 4. Examples of nominal data with the WFC3 grisms UVIS/G280 (left), IR/G102 (center) and IR/G141 (right).

The most common artifacts include satellite trails, Earthshine scattered light and persistence, illustrated below. If you are concerned about the quality of your data, please contact your Program Coordinator, email the Help Desk and see the Hubble observation problem reporting (HOPR) policies.

Satellite. Earthshine. Persistence.
Figure 5. Examples of common WFC3/IR grims artifacts. Left: An image artifact due a satellite crossing the field of view during the exposure (GO-11600). Center: Elevated background on the blue edge of the image due to earthshine (GO-11600). Right: The diagonal streaks are due to persistence from dark earth flat observations done prior to this visit (GO-14227).

3.2) How do I identify and remove persistence from my data?

The WFC3 IR detector is susceptible to persistence which appears as afterglow in parts of the detector that experienced high fluence (total number of photo-electrons released) in earlier exposures. Persistence is not corrected for in calwf3 or aXe. Examples of persistence and suggestions on how to mitigate it are given in the WFC3 Data Handbook.

Creating the persistence model for a given dataset requires looking at the detector history across a number of different programs. Since this process is beyond the scope of calwf3, the persistence model data products are not available through the MAST interface. Instead, we provide a persistence model for each WFC3 IR dataset through a separate persistence search form which allows users to view and download the persistence model. Search for the dataset of interest and then follow the links under "Dataset" to view the model and the links under "Visit" to download the model. A full description of the data products is provided here. A detailed description of the current modeling algorithm can be found in ISR 2015-15.

Observers and archive users are encouraged to contact the help desk if the persistence subtraction substantially limits their ability to extract science from an image or set of images.

3.3) How does flat-fielding work for the grism data?

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.

An alternative approach is presented in Brammer et al. (2012, see the Appendix A and Figure 15), who show that for the G141 grism the wavelength dependence of the flat field across the grism band pass is ±1% outside the "waggon wheel" feature in the lower right corner of the detector. The simplified treatment suggested by these authors is to use the F140W imaging flat.

3.4) If I extract the spectra from the flt images on my own, how do I convert to physical units?

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. Angstroms/pixel).

The sensitivity files for the three grism settings, including different orders, can be found at the following links:

G280 (UVIS)
G102 (IR)
G141 (IR)

3.5) Is it possible to do any type of masking or CR rejection outside of aXe?

Yes. It is possible to use a program like DrizzlePac/Astrodrizzle on the grism images to find and mark CR hits, which will then be rejected during subsequent aXe processing. To do this, first run Astrodrizzle on the original *.flt.fits files for the grism 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 Astrodrizzle 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 Astrodrizzle, 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.

An alternative algorithm for cosmic ray rejection is L.A.Cosmic presented in van Dokkum (2001). L.A.Cosmic detects cosmic rays of arbitrary shapes and sizes, and distinguishes between undersampled point sources and cosmic rays and it does not require dithered images.

3.6) The grism observations are not dithered and aXe requires dithering for cosmic-ray (CR) rejection. Can I use another method to mark bad pixels?

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 aXe.

Another method for doing cosmic ray rejection on no-dithered images is L.A.Cosmic presented in van Dokkum (2001). L.A.Cosmic detects cosmic rays of arbitrary shapes and sizes, and distinguishes between undersampled point sources and cosmic rays.

General aXe Related Data Analysis Questions

4.1) aXe crashed! Where do I start?

First read the remainder of this section to see if any of the issues addressed here matches your problem.

Second, aXe is very particular about the directory structure and the environment variables. Commony users encounter error messages such as this from axedrizzle:

IOError: [Errno 2] No such file or directory:

Check the handbook section which covers the setup procedures and make sure you have followed the recommendations correctly. Print all environment variables to ensure the paths are correct (in a termical window: >echo $AXE_CONFIG_PATH for example).

As a result of IRAF legacy, some tasks might crash if the total length of your environment paths + file names are greater than 80 characters. In aXe v2.3 and above the axedrizzle task has been updated to quit with a useful error message if the path is longer than expected but users may consider using short absolute or relative path names for AXE_IMAGE_PATH, AXE_CONFIG_PATH, AXE_OUTPUT_PATH, and AXE_DRIZZLE_PATH.

If none of these resolve your issue, please contact the help desk. To ensure a quick resolution, please describe your issue in as much detail as possible: provide a screen grab or copy/paste of the entire command line input/output starting with the command which crashes, give us information about which dataset you are working with and send us the ouputs from checking the following environment variables: AXE_IMAGE_PATH, AXE_CONFIG_PATH, AXE_OUTPUT_PATH, and AXE_DRIZZLE_PATH.

4.2) Is aXe compatible with the newest 64-bit version of IRAF (v2.15.x)?

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 crashes.

4.3) 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.

A python script to accompish this is available here along with instructions

4.4) Do I have to use SExtractor for detecting objects in the direct image?

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:
NUMBER
X_IMAGE
Y_IMAGE
A_IMAGE
B_IMAGE
THETA_IMAGE
X_WORLD
Y_WORLD
A_WORLD
B_WORLD
THETA_WORLD
MAG_AUTO

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 does require the use of a SExtractor segmentation map. If users plan to use this method they need to generate a segmentation map.

4.5) How will aXe be affected if SExtractor cannot compute a valid magnitude for an object?

When SExtractor is not able to compute a valid magnitude for an object, it will set the value to > 90. For such objects, aXe (v2.3 and above) will print a warning message but aXeprep will 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. However, beware that if the magnitudes are incorrect this will affect the contamination estimates in subsequent steps.

In old versions of aXe (prior to v2.3), the aXeprep task will quit with an error if your input source catalog has any entries with magnitude > 90.

4.6) 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.

4.7) IOLPREP does not accept the SExtractor generated catalog file. What is the problem?

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.

4.8) How is the contamination model used?

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 4th 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 be sufficient for accurate de-blending of spectra.

4.9) I am confused about the 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 option to the contamination keyword:

cont_model=‘geometric’ or ‘gauss’ or ‘fluxcube’

  • geometric: This is the fastest method and least computationally intensive, however it does not actually account for the amount of contamination. Rather, it only calculates which pixels ARE contaminated. The information from the *.PET files can be used to determine which pixels suffer from contamination.

  • gauss: If the only imaging data you have for the sources comes from the single band reference direct image, then you shoud use the gauss option. This options creates a Gaussian model of the source luminosity distribution for each object using the A_IMAGE and B_IMAGE positions of the source, and the MAG_FNNNN values (in AB mags) in the Input Object List file (*_prep.cat).

    This option can also be used if multiple flux values are available in which case aXe will use the additional information to calculate the spectral slope of the object and account for it in the contamination model. To take advantage of this mode, for each filter add a column with the AB magnitude in the filter to the IOL file and the column to the header as MAG_FNNNN where _FNNNN is the pivot wavelength of the filter. Follow the header instuctions above. These additional flux values can come from sources other than WFC3 or HST imaging but users need to be careful about aperture mismatch and zeropoint offsets when combining ground-based and space-based photometry.

  • fluxcube: If you have several direct images of the field, then you can use the fluxcube option which provides the most 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:

    a) direct images must have the same pixel scale as grism images;

    b) the World Coordinate System (WCS) of the images must match.

    WFC3, ACS and WFPC2 images can be used, as long as you process them with Astrodrizzle to the same pixel resolution as your grism data. The fluxcube option requires several extra steps before aXecore is called:

  1. Apply the task Astrodrizzle to the imaging data to create *_drz files. The fcubeprep requires several drizzled direct images, and the segmentation map generated by SExtractor (from the direct image) which corresponds to the object catalog used for extraction. ALL drizzled images and segmentation maps (*_seg files) must to be registered to each other (i.e., have the same pixel scale, image size and WCS). If the images were not obtained in the same visit then you must align them using a reference image with Astrodrizzle in order to use them with fcubeprep (for more information see Chapter 7.5 in the Astrodrizzle 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 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

    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 grism image.

4.10) What values should I use for norm and gaincorr in the task axeprep?

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 applied.

4.11) Why is aXe generating divide by zero errors and crashing?

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.

4.12) Can aXedrizzle resample spectra with pixel sizes smaller than the native platescale (like Astrodrizzle 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:

DRZPFRAC 0.7
DRZPSCALE 0.5

Note that you must have version 2.2 or later of the aXe software for this to work properly. Previous versions had a bug when using non-standard DRZ values. For more information on the parameters in drizzle type help drizzle at the Pyraf prompt.

4.13) What parameters do I set for Vertical Extraction?

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" and "slitless_geom=no"

4.14) How do I specify the exact width of the aperture to use for spectral extraction?

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.

G280 (UVIS) aXe Data Analysis Questions

5.1) Are there any limitations for the G280 calibrations?

Not any more. The +1 and -1 orders in both CHIP1 and CHIP2 are fully calibrated over the entire field of view. Due to heavy self contaminations, higher orders are not calibrated. Previously, the G280 grism traces were only calibrated near the geometric centers of the chips, however this is no longer true. See above for recommendations on which chip to use.

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 Astrodrizzle 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 (*.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 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.

5.3) I am working on UVIS grism data (G280) and the task drzprep crashes and produces the error:

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

The 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 drzprep.

5.4) Will aXedrizzle work with the G280 (UVIS) grism?

Just like the drzprep task, 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 aXedrizzle.

Last Updated: January 2016