Grism Frequently Asked Questions

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

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.

The following are the recommended filters for direct imaging:

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.

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.

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.

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.

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

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

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

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.

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

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 ARTDATApackage 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)

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

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.

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.

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.

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

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.

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.

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.

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.

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.

Python code to accomplish this is included in astroconda and documented here: https://wfc3tools.readthedocs.io/en/stable/wfc3tools/embedsub.html

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.

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.

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 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 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 aXeprocessing. Users are cautioned that contamination models are unlikely to be 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 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 *.fltinput grism image.

The aXeprep task applies several different operations to the*.flt.fits file in order to put the data into the units expected by aXetasks. 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.

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

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"

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.

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.

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

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.

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.