Hubble Space Telescope
WFC3 Grism FAQ Answers


		Phase 1 Proposal Preparation
		1.1) My targets are fairly 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 WFC3 Instrument Handbook (section 7.7.4) and the Phase II proposal instructions (section 14.3.6) for more info about the use and timing of IR sub-array readouts. 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. 1.2) Do I need a direct image for the UVIS Grism? The 0th order is separated from the first order spectrum, so in theory, one should be able to find the location of objects without a direct image. 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. 1.3) 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.4) Since the UVIS spectra are significantly curved, what is the wavelength range of the 1st order which is least likely to be affected 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. Figure 1: Closeup of the postive G280 spectral orders on the UVIS detector (Figure 8.2 from the WFC3 Instrument Handbook). 1.5) Are there recommended filters for Grism direct imaging? The following are the recommended filters for direct imaging: Grism Filter 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.


		Phase 2 Proposal Preparation
		2.1) Which direction will a POS TARG move my target? 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. 2.2) 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. 2.3) How do I “see” the dispersion direction of the Grism in Aladin? 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. 2.4) 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 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 2.5) Are there any guidelines for using 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) 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) 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. 3.2) 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/cm²/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: G280 (UVIS) G102 (IR) G141 (IR) 3.3) Is it possible to combine multiple extracted spectra of a source outside of aXe? 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. 3.4) Is it possible to do any type of masking or CR rejection outside of aXe? 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. 3.5) 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.


		General aXe Related Data Analysis Questions
		4.1) 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.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. 4.3) 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 uses the SExtractor segmentation map. 4.4) How will aXe be affected if SExtractor cannot compute a valid magnitude for an object? 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. 4.6) Why doesn’t IOLPREP seem to accept the SExtractor generated .cat file? 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.7) 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 [4] 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: cont_model=‘gauss’ or cont_model=‘fluxcube’ or cont_model=‘geometric’. 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 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. 4.9) 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.10) Why is aXe is 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.11) The task axedrizzle crashes with the error: “IOError: [Errno 2] No such file or directory:” 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 for: AXE_IMAGE_PATH AXE_CONFIG_PATH AXE_OUTPUT_PATH AXE_DRIZZLE_PATH 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: 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 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. 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? 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 (.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’m 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 and G280 grism data can not be processed with aXedrizzle.

Version 1.3 Sep 2011