This is an old revision of the document!
Q: Why does my SPAM pipeline run fail?
A: Although in general the SPAM pipeline is able to process many different data sets, there will be cases in which it fails. The output of the main pipeline (process_target()) is captured in a log file, located in the datfil directory. This will often provide guidance on the nature of the problem, but is a bit bulky. In your SPAM session, you can get a summary of the log file through
summarize_spam_log( './datfil/spam_<your_target_name>_*.log' )
Look for sudden increases in the noise, or decreases in the number of visibilities or the total cleaned flux. Something will have likely gone wrong between those two steps.
Q: SPAM crashes with a message about “too many open files”. What do I do?
A: Typical Linux installs have a limit on the number of files (or file descriptors) that a user can have open at any given time. The default is usually set to 1024 to prevent runaway programs from doing harm. As a user you can check that number: in (ba)sh, type
or in (t)csh, type
Often it is possible as a user to increase the limit on file descriptors. In (ba)sh, type
ulimit -n 4096
or in (t)csh, type
limit descriptors 4096
If this operation is not permitted, go talk to your sysadmin.
UPDATE: The latest ParselTongue distributed with SPAM has an improvement in place to reduce the occurence of this error.
Q: Can I take the calibrated visibilities (.CAL.UVFITS) into CASA for imaging?
A: Yes you can. One limitation is that CASA from version 4.2 onwards doesn't allow stokes I visibilities to be imported. To overcome this, you can re-label the visibilities as being RR, and then image the RR visibilities in CASA. Converting the calibrated visibilities from stokes I to RR can be done in SPAM as follows:
uv = get_aips_file( 1, 'CALIBRATED', 'UVDATA', -1, 'UV' ) read_fits_uv( './fits/<target_visibilities>.CAL.UVFITS', uv ) convert_stokes_I_to_RR( uv ) write_fits_uv( uv, './fits/<target_visibilities>.RR.UVFITS' ) uv.zap()
Next, start CASA and run the importgmrt() task to convert the UVFITS data to a measurement set:
importgmrt( fitsfile = '<target_visibilities>.RR.UVFITS', vis = '<target_visibilities>.RR.ms' )
Then run the clean() task with at least the following options:
clean( vis = '<target_visibilities>.RR.ms', imagename = '<target>', gridmode = 'widefield', wprojplanes = <some number, e.g. 128>, stokes = 'RR', weighting = 'briggs', usescratch = True ... )
Q: Why doesn't the SPAM pipeline work (anymore), with AIPS generating NaNs in certain tasks?
A: Updates of the Linux operating system in 2017 has triggered floating point problems when running AIPS tasks on a new line of Intel Xeon E5-xxx CPUs. This is likely caused by an outdated Intel compiler used to build the AIPS binary install. A GNU compiled version of AIPS 31DEC13 fixes the problem and is available here. It may run a bit slower than the Intel compiled version.
Q: Is there a way to bypass the problem of SPAM finding no / too few peeled sources?
A: The SPAM pipeline needs to peel a sufficient number of sources to perform its direction-dependent calibration and modeling for ionospheric effects. There are several common cases in which SPAM cannot find enough peeled sources, mostly because of poor quality of observational data or because of dynamic-range limitations in the image. The user can force the pipeline to continue using the (direction-independent) self-calibration, but should be aware that the final pipeline results may be compromised. For this, the allow_selfcal_skip option needs to be enabled:
process_target( target_uvfits_file_name, allow_selfcal_skip = True )
Q: Why does my SPAM pipeline run crash when the screen session in which I run SPAM is interrupted?
A: As the SPAM pipeline can take several hours to days to run, it is useful to execute it in a screen session when working remotely. However, some users found that the SPAM pipeline crashed during a disconnect from the screen session with the error “Fatal IO error 11 (Resource temporarily unavailable) on X server localhost:1.0.”, or something similar. This is likely due to the fact that the screen is started in an environment with the X server available that becomes unavailable after the disconnection, causing the crash of SPAM. A solution might be to use a “fake” X server, such as xvfb, in the screen session. Another solution is to run SPAM remotely via a VNC session. Note that checking the progress of the pipeline can also be done by checking the spam*.log in the datfil subdirectory.