Creating 3D Data Cubes ====================== Description: Combine dithered long-slit spectroscopic observations to produce 3D data cubes, i.e., spatial maps or images (2D) with a third dimension that is a function of wavelength. Scientific Case: By making dithered observations perpendicular to the slit with STIS, one can obtain a spectral map of a 2D spatial region. Several GO programs have used this technique to map the regions around galactic nuclei and to map planets in the solar system. The natural data product for such an observation is a data cube with two spatial dimensions and a third dimension in wavelength. These data would then be equivalent to data obtained with an integral field spectrograph (IFS) or a scanned Fabry-Perot imager. Unique STScI capabilities: The instrument groups at STScI have the specific knowledge of the instruments and the associated pointing data (WCS information and jitter files) that would be needed to perform this task routinely. Drawbacks: Combining spectral images has the same (if not more) problems with alignment and registration that affect combining images. One often must tweak parameters manually in an iterative process to achieve an optimum result. ---------------------- Assumptions The paucity of spatial information in an FOS or STIS spectral data set that could be used to empirically align and combine separate observations makes it essential that the data headers contain accurate spatial information. This could be either accurate WCS information (another SHARE task listed at higher priority), or accurate relative spatial information as given by POS TARG or Pattern_Type keywords in the data header. The implementation plan described below assumes that the data headers contain accurate spatial information in one of these two categories. Required Decisions 1. Confirm community interest before implementing this capability. We listed this at low priority among the SHARE tasks. Before investing substantial resources, we should be satisfied that this would benefit a signficant number of users. (First step: see how many STIS observations have employed the Pattern_Type=STIS-PERP-TO-SLIT.) 2. Explore ST/ECF interest in carrying out some fractoin of the owrk described here. Min and Max Goals Minimum Goal: Produce data cubes for STIS observations that were intended to produce a spatial map of some area of the sky. Usually such observations would have used the Pattern_Type=STIS-PERP-TO-SLIT; other candidates would be exposures with a POS TARG that has a non-zero X coordinate offset. To implement this minimum goal, only accurate *relative* spatial information need be present in the data headers. Accurate absolute WCS solutions are not required. Maximum Goal: Produce data cubes for arbitrary combinations of observations which lie in close spatial proximity, even if obtained with different instruments at different times. (Example: FOS and FOC observations of the nucleus of M87 were obtained in several repeated visits over several years.) Implementation Plan If accurate spatial information can be found in the data headers, then implementing this task is actually not too difficult. Steps include: 1. Confirm community interest and the size of the benefit. This would include - database search to see how many observations use Pattern_Type=PERP-TO-SLIT or POS TARG |X|>0.0,Y - presentation to/approval by the STUC, or confirmation via a survey 2. Identify suitable data sets. Determine if this can be done automatically using the current archive catalog, or whether special catalogs of qualifying data sets would need to be created. 3. Develop prototype software to test algorithms and procedures. To evaluate success, compare the output to published results, and/or consult with the PI of the original observation used for the test. 4. Proceed with full implementation: - Develop requirements document. Include algorithmic description and prototype software. - Programming team develops required software and interfaces. - Archive team develops data set selection method - Test - Document (external, for user support; internal, for maintenance). - Deploy Required Resources - For Min Goals 1. Would require about 0.5 FTE-week for a scientist, plus 0.5 FTE-week for a DA 2. Would require about 1 FTE-week for a scientist, plus 1 FTE-week for a DA 3. Would require about 1 FTE-month for a scientist, 1 FTE-month ofa DA, and 1 FTE-month of a programmer (could be a scientist, DA, or s/w engineer) 4. Requirements document: 1 FTE-month for a scientist Programming: 1 FTE month for a programmer Archive work: 1 FTE month Interfaces: 1 FTE month Testing: 1 FTE month divided among a scientist and DA Document: external, 1 FTE month for a scientist internal, 1 FTE month for a programmer Install and deploy: 1 FTE month Total: 12 FTE-months - For Max Goals This would start with the same baseline as above, but probably take an extra 3-4 FTE-months in the development and implementation phase to figure out how best to combine incommensurate data sets. Time Scales (for min and max goals) - For Min Goals Steps 1 & 2 could be done concurrently. Timescale here possbily constrained by STUC schedule. Allow 3 months. Given typical multitasking in groups, step 3 would require 3-6 months. Again, allowing for multitasking and software test/install schedules, step 4 would probably require min 6, max 12 months. Total: 12-18 months - For Max Goals Add ~ 6 months on to the above for the added complexity. Total: 18-24 months