Mission/category:

Frequently Asked Questions

Data Requests

Why do I get 2 IUESIPS MELO files for some low dispersion images but only 1 NEWSIPS MXLO file?
In IUESIPS, the extracted data for large and small aperture data from a given image were archived as two separate files (e.g. MELO1 and MELO2). In NEWSIPS, the extracted data for both apertures were archived in the same FITS file (e.g. MXLO).
Can I request IUE data in ASCII format?
ASCII versions of the mxlo and mxhi files are available. From the search results page click on the object name to display the preview image. The ASCII versions can be downloaded by clicking on the line "Download a gzipped ASCII file of the large/small aperture preview spectrum." This line is found at the bottom of the preview page. If the image contains an exposure for both apertures, there will be a line and file for each aperture.
Why are some IUE NEWSIPS data not available? The IUESIPS version is available from the archive.
There are various reasons why certain images may not be available. Some images are have problems that can't be handled by the NEWSIPS software but are glossed over by IUESIPS. Some images were misplaced during the processing and archiving process; we are chasing them down now. If you are interested in a particular image that doesn't seem to be available, please contact us and we will find out and make it available to you if possible.

Reading Files

How do I read NEWSIPS files into IRAF?
The iuetools package will allow users to read NEWSIPS files. Currently the package requires IRAF (V2.11 or later), TABLES (V2.0 or later) and STSDAS (V2.0 or later). Here is more information.
How do I read NEWSIPS files into IDL?
IDL programs are available to read in the NEWSIPS files. Use READMX to read either MXLO or MXHI files, and READSI to read either SILO or SIHI files. See the IUEDAC User's Guide for more information.
Why are my RDAF-format IUESIPS files unreadable after I transferred them from NDADS to my unix workstation?
RDAF format files from NSSDC use the VAX VMS floating point data format and must be converted to IEEE format before being copied to a unix workstation. See our helpful hints about file copying from NDADS for more information. (Note however that IUE files are no longer available from NDADS.)
Can I use SAOimage to look at NEWSIPS files?
Yes, it will handle the RI, LI, and SI files but not the VD and MX files. Use the options -fits to tell SAOimage that the files are FITS and -upperleft to display the images in the usual orientation, e.g. saoimage -fits -upperleft SWP12345.RILO. Adding the options -min and -max to scale the dynamic range of the grayscale display is also a good idea.

NEWSIPS Processing

What is the wavelength scale used for NEWSIPS? Is it heliocentric?
Yes, the wavelengths have been corrected for both the Earth's motion around the Sun and the IUE spacecraft's motion around the Earth, computed as of the start of the exposure. A more up-to-date platinum-neon line library was used to create the wavelength calibration, resulting in some small systematic changes in the wavelength scale compared to IUESIPS. Some other small differences compared to IUESIPS are described in the NEWSIPS Manual Appendix III.
I have a NEWSIPS image which may not have been processed correctly (wrong dispersion, wrong exposure time). How can I get a correct version?
Please let us know; we certainly would like to correct any errors. We have a limited capability to reprocess images through NEWSIPS if there was an error in the processing. Send email to archive@stsci.edu.
The wavelengths for the Mg II h and k lines are very different, by almost an Angstrom, between my IUESIPS and NEWSIPS high-dispersion data. Is this an error?
The IUESIPS data follows the old convention of giving wavelengths in air for wavelengths greater than 2000 Å and in vacuum for wavelengths shorter than 2000 Å. The NEWSIPS data follow the new convention, also used by HST, of giving all ultraviolet wavelengths in vacuum. The difference is pretty large. For instance, Mg II h is 2802.695 in air but 2803.52 in vacuum, Mg II k is 2795.53 in air but 2796.35 in vacuum, and Mg I is 2851.65 in air but 2852.49 in vacuum.
The wavelengths for my high-resolution NEWSIPS spectra seem to be off by almost an Ansgtrom. What happened?
The NEWSIPS data follow the new convention of using ultraviolet wavelengths in vacuum. Most IUE data users are accustomed to using wavelengths in air for wavelengths longward of 2000 Å, i.e. all LWP and LWR data. (See also the answer to question about Mg II line wavelengths above.)

ASCII Logs

Are there ASCII files containing the IUE Merged Log?
Yes, there are ASCII files with the IUE Merged Observing log. There are several subsets of the observing log available also.

Data Analysis

When analyzing data, which of the data quality flags should I use to throw out pixels?
Almost certainly all of the nonzero flags. One can imagine situations (the only spectrum in the archives of your source) where you would want to "look" at a spectral feature which was uncalibrated, on the edge of the camera field, or whose fluxes were extrapolated beyond the highest ITF-calibration level - but even in this regime one would probably not want to try to conduct a quantitative analysis of the feature.
Users should also be aware that no attempt was made in NEWSIPS to eliminate cosmic rays from the high-dispersion images, and the attempts made for low dispersion probably err on the conservative side. The reason for this was a concern that a provision for cosmic rays would lead NEWSIPS inadvertently to remove actual emission lines. Users should especially be cautious about the influence of oblique, diffuse cosmic rays, which can subtlely affect the background surface by 150 pixels or more from the centroid of the "hit" region and be responsible for less than optimal fits to the background surface. We suggest that the SIHI or SILO images be first visually screened before the extracted spectra are analyzed.
When coadding like spectra, should I weight the constituent spectra by exposure time or the square root of exposure time?
Probably neither. An analysis of the noise properties of the IUE cameras for IUESIPS (e.g. as given by Ayres, PASP, 102, 1420, 1990 and PASP, 105, 538, 1993), but probably also applicable to NEWSIPS, suggests that the signal to noise gain is an increasing function of exposure time, but which is slower than either the limits of Exp_time or sqrt(Exp_time). Of course, the actual situation is even more complicated. For example, for integration longer than the "optimal" exposure time, illuminated pixels saturate and are useless. In this regime the quality of the data quickly degrades; saturated pixels can never be used for any purpose.
For the coaddition of data, we recommend weighting individual spectra by reciprocal of the means of their noise fluctuations. (But in computing such a mean consider only those pixels with zero-value quality flags!) The "sigma" vector is computed by NEWSIPS as an estimate of these fluctuations as a by-product of the flux extraction process. For the extracted MXHI data the estimate for each wavelength pixel is based on predicted fluctuations of extraction slit pixels from the noise model for the same region of the camera. The units of the sigma vector in high dispersion are in "FNs" (Flux Numbers), the same as the net flux vector. For MXLO data the sigma vector is derived from the noise model, but it depends also upon the relative illuminations of pixels along the extraction slit. In this case the result is also scaled to units of absolute flux.
Whew! Is there a simpler way of estimating noise?
Yes. The time-honored way is to find a stretch of continuum in the extracted spectra which contains no spectral features and is free of pixels of with negative data-quality flag values and then compute the rms formally from its noise fluctuations.
Since "clean" continuum is not always easy to find, let's consider an empirical procedure which works well even for a spectrum containing features. As long as the flux errors are primarily gaussian- distributed, we can make use of the fact that randomly drawn samples will differ from one another, on average, by exactly one standard deviation. In the computing language IDL, an estimate of the rms may be computed conveniently by a few steps. Defining "f" as a spectral flux array taken from pixels near the blaze maximum (so the noise will be approximately uniform along the spectrum) and containing only zero-valued quality flags, we compute the mean point to point fluctuation of two pixels separated by a short distance n:
The distribution of noise fluctuations among these pixels can be obtained from the computation:
rmsdist = abs( f - shift( f , n) ) .
The median of this distribution is computed by sorting the distribution rmsdist and finding the middle element of the sorted rmsdist array, which by definition is half the number of elements in the distribution. Thus:
ntot = n_elements(rmsdist), so ntot2 , = ntot/2 ,
Now we compute the sorted index distribution and take the value of rmsdist we need:
isort = sort(rmsdist) ,
medrms = rmsdist( isort(ntot2) ) . medrms is the our noise estimate using the median average.
The mean of the distribution can likewise easily be determined from:
meanrms = total( rmsdist )/ntot .
This value will be biased on the high side if there are outlying fluctuations in the spectrum. In practice the pixel separation distance n should be at least a spectral resolution element (3 or more).