Follow Us
|
CalFUSE FAQ
How can I make CalFUSE run faster?
CalFUSE requires two things of your machine: memory and I/O. To help the program run more quickly, turn off other memory-intensive applications, especially IDL. If your computer has a fiber-optically-coupled disk, take advantage of its increased speed by moving your data and calibration files there.
Trouble Compiling CalFUSE
Q: I just tried to do a "make install" of CalFUSE. It got as far as trying to compile slalib, but then crashed because it seemed to be trying to use fort77 instead of f77 to do the compiling. What's up?
A: We've seen this problem before. Typing "make -e install" instead of "make install" should do the trick.
900-Level Exposures
Q: What do exposure numbers like 915 mean? e.g., B09001019151attagfraw.fit
A: The bright earth. When the earth passed between the spacecraft and the target, we sometimes left the detector high voltage on to get a downward-looking airglow spectrum. The resulting raw data files received exposure numbers beginning with 901. Early in the mission, we used to take such data frequently. However, because the repeated airglow exposures were drawing charge out of the detectors for no good gain, the practice was largely stopped, and only performed occasionally for the rest of the mission.
Caveat: Bright-earth exposures may not end when the target reappeared from behind the earth. If the spacecraft was within ten minutes of local noon or the pointing was predicted to be unstable, target acquisition likely to failed, so the airglow exposure continued until the situation improved. If the target was still in the aperture, the spacecraft continued to observe it and the resulting airglow exposure included a target spectrum. To find out, check the count-rate plots for the airglow exposures. CalFUSE rejects data obtained during earth occultation, so the extracted spectra contain only target data. The observation-level (*all*) spectra do not, however, include contributions from 900-level exposures.
Modified Julian Date
Q: CalFUSE converts wavelengths to a heliocentric reference frame. Does it convert the exposure start and stop times (EXPSTART and EXPEND) to a heliocentric frame as well?
A: No. CALFUSE does not convert the exposure start and stop times to a heliocentric frame of reference. The header keywords EXPSTART and EXPEND are genuine geocentric modified Julian dates, i.e., Julian dates with 2400000.5 subtracted.
Local Standard of Rest
Q: What is the difference between dynamical LSR and standard solar LSR?
A: The component of the sun's motion in the direction of the target, assuming the standard solar motion of 20 km s-1 towards RA 18h, Dec +30o (1900), is written to the header keyword V_LSRSTD. In V_LSRDYN, we provide the sun's velocity toward the target assuming the dynamical solar motion of of 16.6 km s-1 towards l = 53, b = +25. V_LSRDYN and V_LSRSTD are provided for informational purposes only. They are not used by the calibration software.
Reference for FUSE Flux Calibration
Q: What value I should quote for the accuracy of the FUSE flux calibration? Can you give me an appropriate reference?
A: The accuracy of the FUSE flux calibration is about 10%, but the exact value depends on the kind of science you are trying to do. For details, see "CalFUSE Version 3: A Data-Reduction Pipeline for the Far Ultraviolet Spectroscopic Explorer" (Dixon et al. 2007).
Low Count Rates
Q: Why do my emission-line stars show systematically lower C III 977 Å fluxes through the FUSE MDRS aperture than when observed with HUT or ORFEUS?
A: Poor alignment of the SiC channels is most likely at fault: if the star drifts out of the slit during an observation, you will measure lower fluxes. If your spectra have emission lines in the 1000-1100 Å region, then you may be able to scale the SiC spectra to match the flux observed with the LiF 1A channel. If your data were obtained in time-tag mode, then you might be able to exclude times when the star was out of the aperture. If your data were taken in histogram mode, you could use the count-rate plots to estimate the fraction of the exposure when the star was out of the aperture and scale the line fluxes accordingly.
Burst Rejection
Q: The burst-rejection routine often throws out the last few seconds of my data, even when the count-rate plots show no increase in the flux. What's up?
A: This may not be an error. If the observation ended as the spacecraft moved into the SAA or the target approached the earth limb, the resulting rise in the background count rate may be interpreted as a mild burst. (Because the count-rate plots are logarithmic, small changes in the count rate may be hard to see.) In any event, it is easy to stop this behavior by tinkering with the keywords that control the burst-rejection algorithm. Details may be found in The CalFUSE Pipeline Reference Guide.
Jitter Screening
Q: I've just installed CalFUSE v3.2 and am running cf_jitter to produce new jitter files. What does this message mean?
cf_jitter-3.3: Housekeeping file format is out of date.
A: We've added two header keywords to the housekeeping files that allow cf_jitter to compute the "reference quaternions" (that is, the desired spacecraft orientation) directly from the target's RA and DEC. Most of the time, the reference quaternions are inferred from the pointing arrays in the housekeeping file. This message tells you that your housekeeping files lack these new keywords. It may be safely ignored.
Q: I've just installed CalFUSE v3.2 and am seeing a new warning message in my trailer files. What does it mean? Should I worry about it?
cf_satellite_jitter-1.31: APER_COR = SKIPPED. Omitting photon shift.
A: The two components of the jitter correction are now performed by two separate subroutines. The first, cf_screen_jitter (header keyword APER_COR), flags times when the target is out of the aperture. The second, cf_satellite_jitter (header keyword JITR_COR), corrects the coordinates of individual photons for spacecraft drift. The two programs talk to each other through the file-header keyword APER_COR. If cf_screen_jitter runs to completion, it sets APER_COR to COMPLETE. Later, cf_satellite_jitter checks this keyword. If its value is anything but COMPLETE, the program exits with the above message. Why cf_screen_jitter was unable to do its work is a separate question, which you can answer by examining the trailer file for this exposure.
Q: The jitter-screening routine does not always flag times when my star is out of the aperture. Do you have any tools that do a better job?
A: We've written a little IDL script that attempts to identify times when a bright target is out of the aperture. It uses the count-rate array in the timeline table of the intermediate data file (IDF) to construct a count-rate histogram, then rejects times when the count rate is more than 3 sigma below the mean. For such times, the jitter bit is set in both the timeline table and the photon list. You can download the tool from the FUSE IDL Tools web page.
Q: I was planning to use PHALOW and PHAHIGH of 4 and 16 for LiF 1A to improve the background in my time-tagged data. What values do you recommend?
A: We no longer recommend the use of narrow pulse-height ranges to reduce the detector background in FUSE data. Careful analysis has shown that limits more stringent that the default values (roughly 2-24, depending on the detector) can result in significant flux losses across small regions of the detectors, resulting in apparent absorption features that simply aren't real.
Q: Why does CalFUSE do such a bad job of subtracting the background from SiC 1 spectra of external galaxies? Here's an example.
A: Because your target is a galaxy, the file-header keyword SRC_TYPE is set to EC, for "extended continuum" source. In such cases, CalFUSE employs an extraction window that is considerably larger (in the Y dimension) than that used for point-source targets. On side 1, the SiC LWRS spectrum falls near the lower edge of the detector, where the background rises steeply and is difficult to model. The extended-source aperture extends into this region of enhanced background, which the pipeline is unable to subtract properly.
If the emitting region is more point-like than extended, then the solution is simple: change the keyword SRC_TYPE from EC to PC and re-extract the spectrum. You don't even need to re-run the rest of the pipeline. The smaller extraction window no longer includes the offending background region, and the resulting spectrum is better behaved. Be sure to combine the IDF and BPM files from the individual exposures before running cf_extract_spectra. This increases the signal on unilluminated regions of the detector and enables the software to perform a multi-component fit to the background.
Q: Some recent data sets show strong background contamination at short wavelengths. What's going on?
A: What you are seeing is scattered Lyman continuum emission from the sun. Since the failure of the third reaction wheel in December 2004, we have experimented with the use of off-nominal roll angles to improve spacecraft stability. Sometimes, these roll angles place the spacecraft in a configuration that allows scattered sunlight to contaminate one of the SiC channels. We have no way to model or subtract this emission.
Q: CalFUSE gives warnings about the detector voltage changing during an exposure, but the data look OK to me. Is this something that I should be worried about?
A: If the header keywords indicate that the detector voltage was high, low, or changed during an exposure, CalFUSE writes a warning message to the trailer file. If a valid housekeeping file is available for the exposure, this warning may be safely ignored, because the pipeline uses housekeeping information to populate the high-voltage array in the timeline table and properly excludes time intervals when the voltage was low. If the housekeeping file is not present, each entry of the high-voltage array is set to the "HV bias maximum setting" reported in the IDF header. In this case, the pipeline has no information about time-dependent changes in the detector high voltage, and warnings about voltage-level changes should be investigated by the user.
Optimal Extraction
Q: Does your optimal-extraction algorithm emphasize the fixed-pattern noise in FUSE spectra?
A: It shouldn't. Fixed-pattern noise is a problem only for high signal-to-noise data sets, which generally come from bright targets. The weighting scheme used by the optimal-extraction algorithm is essentially Fxy/(Fxy+Bxy) - where F is flux and B is background - normalized to conserve flux. Each column in the image is considered separately. So if the signal is much brighter than the background, we weight the pixels along a given column uniformly. This weighting should smooth out the fixed-pattern noise, rather than enhance it. For more information on the optimal-extraction algorithm, see (Dixon et al. 2007).
Count-Rate Plots
Q: IDL is installed on my machine, but CalFUSE does not produce the detector-image and count-rate plots. What's wrong?
A: If IDL is installed on your machine, then the IDL routines should run. My guess is that they are crashing, but you don't know it, because all of the output from IDL is sent to /dev/null. All that I can suggest is that you look at these error messages and see if you can figure out the problem. You can do this in one of two ways. In the directory calfuse/v3.2/bin are two Pearl scripts, idlplot_spex.pl and idlplot_rate.pl, which create the detector-image and count-rate plots, respectively. You could modify them to write their output to a file, rather than /dev/null. Another option is to run the programs interactively:
> idl > .run calfuse/v3.2/idl/cf_plot_extract3 > cf_plot_extract3, 'E54201050252bttagf'
The other routine is called cf_plot_rate3.
Q: When I run CalFUSE, I don't get any count-rate or detector-image plots. The perl scripts generate a batch file for IDL to execute, but the call to IDL just hangs. I'm running the bash shell on a Mac.
A: These plots are generated by a couple of perl scripts, idl_obsplot.pl and idlplot_rate.pl, that live in the calfuse/v3.2/bin directory. The scripts construct batch files containing the commands needed to generate the plots, then feed them to IDL. If IDL isn't reading the files properly, try changing the line
system("idl $batch_filename > /dev/null");
to
system("idl < $batch_filename > /dev/null");
in both scripts.
Combining Data from Multiple Exposures
Q: Is it better to combine multiple IDFs and extract a single spectrum or to extract the spectra separately and cross-correlate them?
A: The standard advice is that, for bright targets, you want to optimize spectral resolution, so should extract and cross-correlate the individual spectra. For faint targets, you want the best possible background subtraction, so should combine the individual IDFs into a single file. There's an implicit trade-off between spectral resolution and background fidelity, but the presumption is that resolution is less important for faint targets. For complete instructions, see the FUSE Tools in C web page.
If you want to have your cake and eat it, too, you can shift the photons in the individual IDFs before combining them. For example, you could extract the individual spectra, determine the appropriate shifts for each, apply them to the IDFs, then run idf_combine. John Grimes has written a tool to shift spectra within an IDF. See the FUSE IDL Tools web page.
Q: What's the easiest way to extract night-only spectra from FUSE data?
A: Broadly speaking, there are two ways to exclude day-time photons from your data: either modify the screening files before running the pipeline or modify the IDFs afterward. If you are starting with raw files, simply change the keyword DAYNIGHT from BOTH to NIGHT in the scrn*.fit files (in the parmfiles directory), then run the pipeline as usual. Photons obtained during orbital day will be flagged as bad and excluded from the extracted spectrum.
If you already have IDFs, you can use the IDL tool cf_edit to filter the data interactively. Another option is the C program idf_screen, which runs faster and (if you like) in batch mode. It is described on the FUSE Tools in C web page.
FUSE and IDL
Q: How can I read the CalFUSE output files into IDL?
A: CalFUSE output files are in FITS format with the data stored as binary table extensions. The extracted spectral files (*fcal.fit) employ the standard binary table format, listing wavelength, flux, error, etc. for each wavelength bin. The intermediate data files (*idf.fit) have a different format, listing all of the photon arrival times, then the X coordinates, then the Y coordinates. Formally, the table has only one row, and each element is an array. Both file formats can be read using the MDRFITS command from the IDL Astronomy User's Library. Note that extensions 1 and 3 of the IDF must be read using the /fscale keyword.
idl> a=mrdfits('P99901010011attagfidf.fit',1,/fscale)
idl> b=mrdfits('P99901010011alif4ttagfcal.fit',1)
Elements of individual arrays in the IDFs are addressed using the syntax
idl> print, a.time[3:30]
while, for the extracted spectral files, the syntax is
idl> print, b[3:30].wave
FUSE and IRAF
Q: How can I read CalFUSE output files in IRAF?
A: CalFUSE extracted spectral files (*fcal.fit) must be converted first into STSDAS tables, then into image files that IRAF can read. The program mkmultispec writes wavelength information to the file header. First we load the appropriate packages:
sts tables fitsio hst_calib ctools
... then perform the conversion:
cl> strfits A15101010141alif4ttagfcal.fit * input cl> tabim input.tab flux flux 1 cl> mkmultispec flux input.tab[wave] ""
The result is a file called flux.imh containing a single array of flux values. Additional arrays (error bars, raw counts, etc.) can be extracted in the same way.
FITS File-Header Keywords
Q: Is there an easy way to modify FITS header keywords?
A: If CalFUSE is installed on your computer, you have access to a nifty little program called modhead, which enables you to read or modify header keywords interactively. Here are a couple of examples:
> modhead scrn1a015.fit DAYNIGHT DAYNIGHT= 'BOTH ' / Use only DAY, NIGHT or BOTH > modhead scrn1a015.fit DAYNIGHT NIGHT DAYNIGHT= 'BOTH ' / Use only DAY, NIGHT or BOTH Keyword has been changed to: DAYNIGHT= 'NIGHT ' / Use only DAY, NIGHT or BOTH
The program can handle both numerical and string arguments, but is confused by multiple-word strings.
Another convenient tool is the
IRAF task
hedit, found in the images.imutil package.
If you want to modify many FITS files at once,
you can take advantage of IRAF's scripting capabilities to
run hedit multiple times. For more information, see the
hedit help page.
 |
|
|
|
|
|
|
|
|
|