This document evolved directly from an introduction to SSW concepts developed for CDAW4 and supplemented by cut and paste tutorials presented at a software workshop at MEDOC at the Institute d'Astrophysique Spatiale, Feburary 8-10th. Many thanks to Jean-Claude Vial and Isabelle Scholl for hosting the workshop which served to introduce attendees to processing techniques for unfamiliar instruments and demonstrate some coordinated analysis possibilities available under SolarSoft. While the focus of this document is on the simple imaging instruments EIT, SXT, TRACE, and MDI, many of the "Post Level 1" techniques are equally applicable to additional ground based observatory data and complicated instruments, such as SUMER, CDS and HXT through the use of existing SSW interface routines (index2map, mk_sumer_map, mk_cds_map ) .
An obvious caveat is that to access, process, and analyze the data for instrument XXX using these techniques, the local site must include the SSW branch for that instrument.
IDL> efiles=eit_files('25-may-1998','9-jun-1998',wave=171,/full)
IDL> mfiles=mdi_files('30-may-1998 12:35','30-may-1998 14:50', ftimes=ftimes)
IDL> sfiles=sxt_files('1-jun-1998' [,/sfd, /spr, /sfr] )
IDL> tfiles=trace_files('1-jun-1998 15:30','1-jun-1998 22:00' )
In the case of Yohkoh, TRACE, EIT, (and highly recommended for others), the file names include the UT time of the images (or time of the first image in a 3D file). This permits direct interconversion between file lists and times and many SSW utilities exploit this ( file2time, time2file, sel_filetimes, etc.) which allows data selection, filtering, and cross referencing by observation time prior to any file I/O.
For data sets which do not include the UT time, the FTIMES output keyword contains the SSW time vector which can be used in downline dbase access software (MDI).
The SSW examples and tutorials included in document
illustrate some fundamental SSW access, processing routines and general
coordinated analysis techniques. The data finding routines ,
like xxx_files functions are sensitive to local site configuration and
data avaialbility but all of the downline software is site independent. You can generally
subsitute a locally generated vector of filenames (for example, output of
IDL findfile function) for the output of the xxx_files
routines if the xxx_files functions are not setup at your site.
Data read routines
Many read routines for SSW imaging instruments incorporate output
parameters in the form of index, data, where index is a
vector of IDL structures and data is the corresponding
image data (2D or 3D). In the case of FITS data sets,
each FITS header is mapped into one element of the index
vector - in this context, searching for FITS index parameters
is a vector operation which may apply to one or many hundreds of headers
at once to permit processing and analysis of image data as 3D.
There is some additional dicussion of file formats and FITS<->index
interconversions in
the SolarSoft suggested standards for pointing and time.
A common technique is to read in multiple headers (into index vector) and then search them for desired attributes (such as wavelength, data quality, etc). and then read only the subset of filtered data data. In effect, this permits any vector of files to act as a mini-catalog which always maps to the data at hand. This bypasses one problem of working at sites which have incomplete or mismatches between the catalog and data for instrument XXX ie, works even if someone is working with an arbitrary set of data files in an unauthorized location ($HOME for example). The fact that the index records within SSW describe the image times and solar pointing parameters with standard definitions permits cross-instrument use of many SSW utilities for time series, alignment , overlay, solar feature tracking and extraction, etc.
IDL> mreadfits,2DFITS_files, index, data
; generic multiple 2D FITS->index, data (3D)
IDL> read_eit, eitfiles, eitindex [,eitdata] [,outsize=NXY]
IDL> rd_mdi, mdifiles, mdiindex [,mdidata]
IDL> rd_xda,sxtfiles, ss, sxtindex [,sxtdata]
IDL> read_trace,tfiles, ss, tindex [,tdata] [,outsize=NXY ]
Note that the ss (SubScript) parameter is used for data sets which do
not have a 1:1 mapping between files and images (TRACE and SXT for example)
The ss vector represents the relative image numbers desired
from the filelist vector. For those familiar with the IDL
where
statment, it is usually the output of a where command which
matches a list of one or more parameters of interest. For example
IDL> ss=where(tindex.wave_len eq '171' and tindex.naxis1 eq 1024)
are the pointers to all of the images in your specific trace file list
which match those criteria. Several instruments provide utility widgets
which give you a graphical way of selecting the parameters and generating
the desired ss vector - in reality, these are just forming the
complex where command(s) internally and returning the result.
By convention, an SS value of -1 implies
all images. It is also worth noting the the ss concept
also applies to the multi 2D readers (eit, mdi, ground based) - in those
cases, the filelists may be subscripted with the subscripts (ss)
of the index vector which match the image parameters of interest.
Caution: the ability to
pass a vector of file names and to reference an unlimited number
of images in these calls is a powerful tool for treating image data
as a 3D data set; but it is important to realize that when reading the
data, the number of images implied by the file list and
ss must be reasonable for your application and available
system resources. A common technique is to read all the headers,
apply some parameter filters (wave, size , fov, etc), and only read
the data for the filtered subset.
Additional details, options, and hints about dealing
with large, 3Dimensional image sets
For SXT...
IDL> rd_xda,sfiles, -1, sindex ; read all index records
IDL> ss=sswhere(sindex) ; select parameters of interest
IDL> rd_xda,sfiles, ss, tindex , tdata ; read subset of index,data
For TRACE...
IDL> read_trace,tfiles, -1, tindex ; read all index records
IDL> ss=trace_sswhere(tindex) ; select parameters of interest
IDL> read_trace,tfiles, ss, tindex , tdata; read subset of index,data
NOTE - the above TRACE example is shown for reference and will work for any
vector of local filenames; However, the following catalog interface is
faster for sites which have all of the TRACE data
online, such as LMSAL and GSFC ... This is particularily useful
when the time range of interest is large (spanning many TRACE files).
IDL> trace_cat,time0,time1,catalog ;read catalog for time range
IDL> ss=trace_sswhere(catalog) ; select parameters of interest
IDL> trace_cat2data,catalog(ss),index,data ; map the catalog matches to the data
WWW interface to trace_cat.pro and TRACE data request interface
Calling Sequences
IDL> trace_prep, index, data, outindex, outdata [,OPTIONS] ; dark / flat field / normalization /wave2point...
IDL> index2map, index, data, outmap [,/sub]
; convert a index,data to a map object
IDL> ssw_track_fov, index, data, outindex, outdata,/interactive ; track/extract regions from full disk data
representative
output run on AR 8227
IDL> cimg=ssw_fov_context(index,data [,OPTIONS]) ;
find closest full disk context image and overlay a reduced FOV (cds, trace,
sxt PFI)
IDL> closess=tim2dset(index0,index1,delta_sec=dts) ;
match two time vectors (ex: 'index' vectors from 2 different instruments)
IDL> cadencess=grid_data(index,[sec=sec , min=min,
hour=hour],delta=dts) ; sub sample index at quasi fixed cadence
Data access, processing, and coordinated analysis tutorials