Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/science/share/spec_cubes_kriss_020602.txt Дата изменения: Wed Feb 6 20:14:22 2002 Дата индексирования: Sat Dec 22 04:31:17 2007 Кодировка: Поисковые слова: http www.astronomy.ru forum index.php topic 4644.0.html

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