• ## CASA simulated imaging: now FTMachine is whining

A few days ago I apparently got my broken simulator working again. Today, in my first attempt to repeat those results, I... have broken it again.:

WARN        FTMachine::initMaps     No overlap in frequency between image channels and selected data found for this FTMachine
WARN        FTMachine::initMaps+     Check your data selection and image parameters if you end up with a blank image


This warning is not a simple warning, it means nothing is being done. My images are empty, pure noise (which, interestingly enough, is far from gaussian).

I have encountered these errors before <|filename|/separating_line_and_continuum.rst>, but unfortunately did not resolve the issue.

Turns out, the difference was the .ms file I used, continuum_7m12m_noflag.ms, which works, vs the useful one, w51_contvis_selfcal_3.ms, which doesn't.

Checking out their headers, the continuum image does overlap with the data but the selfcal version doesn't. Wonderful. Now I'll bet it's only populating one channel at a time when I invert too...

This leads me to try:

split(vis='w51_contvis_selfcal_3.ms', outputvis='simulation_continuum.ms', datacolumn='data', width=100)


then use (borrowed from this tool):

mymsmd = msmdtool()
mymsmd.open(vis)

reffreq = "{value}{unit}".format(**mymsmd.reffreq(spw)['m0'])


to get the frequency to write into the header each time.

At a glance, just changing the frequency of the FITS file to match the first SPW seems to work. However, I haven't yet examined whether the other SPWs are populated.

This assumption proved wrong. No, it simply doesn't work. The warnings went away, but the output images are empty. Also, the noise went up, which I don't understand.

Imaging just spw1 kind of worked, but resulted in an image with the wrong resolution by factors of many.

Trying to loop over all spws failed miserably, resulting in nothing being done by predict and no warning being given.

OK, finally, solution is to make sure CDELT is large enough to cover all SPWs.

Another important note: Jy/beam and Jy/pixel inputs into CASA result in identical images. In both cases, they are wrong images: they correspond to multiplying the input data by factors of at least 100. Therefore, my conclusion now is that I have to divide everything by some fact, which I sincerely hope is ppbeam, to correct the data.

It looked vaguely like the divide-by-ppbeam trick worked, but my tests kept coming up funny because the original images were scaled down. So I tried unscaling them. Somehow, without changing anything about the headers, I landed on another failed predict error:

2016-04-27 19:14:42 SEVERE  Simulator::createSkyEquation() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2200)        Caught exception: (/Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc : 2266) Failed AlwaysAssert spectralIndex>=0
2016-04-27 19:14:42 SEVERE  Simulator::predict() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2118)  Failed to create SkyEquation


Spectral Index? I encountered this previously, but didn't record any solution. After checking the header, it appears that my files are now missing axes 3 and 4. I didn't make any changes that should cause this; the axes are just not being added on importfits despite being forcibly added in the command.

The problem is unfortunately not in the FITS part, but again in the CASA part. Re-importing the FITS file to .image without forcing defaultaxes again just broke it.

• ## More CASA simulation & debugging

(this post written from snowy-ish ALMA; just cloudy at the OSF though)

(tl; dr version: sm.setvp doesn't work if you have TELESCOP="ALMA" in your header)

I'm trying to repeat an experiment very similar to previous simulation work in order to quantify my completeness and largest angular scales by injecting synthetic signal into the real UV data.

However, as you might expect, it doesn't work as it did last time, even when I (afaict) copy and paste the code directly.

Here's the new error:

2016-04-25 02:57:21 SEVERE  Simulator::createSkyEquation() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2200)        Caught exception: Transformations to/from frame "Undefined" are not possible.
2016-04-25 02:57:21 SEVERE  Simulator::predict() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2118)  Failed to create SkyEquation
Result of predict: False


It's strange because there is nothing obviously undefined.

I'm comparing 2 FITS files that should behave identically. The good header lacks these keywords that the bad header has:

['PV2_1',
'PV2_2',
'OBSERVER',
'DATE-OBS',
'OBSRA',
'OBSDEC',
'OBSGEO-X',
'OBSGEO-Y',
'OBSGEO-Z']


while the good header has these and the bad lacks them:

['PC03_01',
'PC04_01',
'PC03_02',
'PC04_02',
'PC01_03',
'PC02_03',
'PC03_03',
'PC04_03',
'PC01_04',
'PC02_04',
'PC03_04',
'PC04_04',
'CREATOR',
'INSTRUME',
'BAND',
'PROPOSAL',
'PRTITLE',
'OBSID001',
'OBSID002',
'HISTORY']


The only significant difference is the PC values, unless CASA is doing something with the observatory location information.

The only difference in common keywords is numerical, which seems very unlikely to cause this issue.

I cannot discern any useful difference between these two CASA .image headers:

2016-04-25 03:08:55 INFO imhead     ##########################################
2016-04-25 03:08:55 INFO imhead     ##### Begin Task: imhead             #####
2016-04-25 03:08:55 INFO imhead     imhead(imagename="../perseus_synth/perseus_250_to_w51.image",mode="summary",hdkey="",hdvalue="",verbose=True)
2016-04-25 03:08:55 INFO ImageAnalysis
2016-04-25 03:08:55 INFO ImageAnalysis      Image name       : perseus_250_to_w51.image
2016-04-25 03:08:55 INFO ImageAnalysis      Object name      : perseus 04
2016-04-25 03:08:55 INFO ImageAnalysis      Image type       : PagedImage
2016-04-25 03:08:55 INFO ImageAnalysis      Image quantity   : Intensity
2016-04-25 03:08:55 INFO ImageAnalysis      Pixel mask(s)    : mask0
2016-04-25 03:08:55 INFO ImageAnalysis      Region(s)        : None
2016-04-25 03:08:55 INFO ImageAnalysis      Image units      : Jy/pixel
2016-04-25 03:08:55 INFO ImageAnalysis      Restoring Beam   : 0.465804 arcsec, 0.465804 arcsec, 0 deg
2016-04-25 03:08:55 INFO ImageAnalysis
2016-04-25 03:08:55 INFO ImageAnalysis      Direction reference : J2000
2016-04-25 03:08:55 INFO ImageAnalysis      Spectral  reference : Undefined
2016-04-25 03:08:55 INFO ImageAnalysis      Velocity  type      : RADIO
2016-04-25 03:08:55 INFO ImageAnalysis      Rest frequency      : 2.33947e+11 Hz
2016-04-25 03:08:55 INFO ImageAnalysis      Telescope           : Herschel
2016-04-25 03:08:55 INFO ImageAnalysis      Observer            : UNKNOWN
2016-04-25 03:08:55 INFO ImageAnalysis      Date observation    : UNKNOWN
2016-04-25 03:08:55 INFO ImageAnalysis
2016-04-25 03:08:55 INFO ImageAnalysis      Axis Coord Type      Name             Proj Shape Tile   Coord value at pixel    Coord incr Units
2016-04-25 03:08:55 INFO ImageAnalysis      ------------------------------------------------------------------------------------------------
2016-04-25 03:08:55 INFO ImageAnalysis      0    0     Direction Right Ascension   TAN  2370  158  19:23:41.765  1099.00 -1.552680e-01 arcsec
2016-04-25 03:08:55 INFO ImageAnalysis      1    0     Direction Declination       TAN  2500  250 +14.30.45.850  1552.00  1.552680e-01 arcsec
2016-04-25 03:08:55 INFO ImageAnalysis      2    2     Spectral  Frequency                 1    1   2.33947e+11     0.00  1.000000e+09 Hz
2016-04-25 03:08:55 INFO ImageAnalysis                           Velocity                                     0     0.00 -1.281456e+03 km/s
2016-04-25 03:08:55 INFO ImageAnalysis      3    1     Stokes    Stokes                    1    1             I
2016-04-25 03:08:55 INFO imhead     ##### End Task: imhead               #####
2016-04-25 03:08:55 INFO imhead     ##########################################
2016-04-25 03:09:07 INFO imhead
2016-04-25 03:09:07 INFO imhead     ##########################################
2016-04-25 03:09:07 INFO imhead     ##### Begin Task: imhead             #####
2016-04-25 03:09:07 INFO imhead     imhead(imagename="../simulations/simimage_firsttest.image",mode="summary",hdkey="",hdvalue="",verbose=False)
2016-04-25 03:09:07 INFO ImageAnalysis
2016-04-25 03:09:07 INFO ImageAnalysis      Image name       : simimage_firsttest.image
2016-04-25 03:09:07 INFO ImageAnalysis      Object name      :
2016-04-25 03:09:07 INFO ImageAnalysis      Image type       : PagedImage
2016-04-25 03:09:07 INFO ImageAnalysis      Image quantity   : Intensity
2016-04-25 03:09:07 INFO ImageAnalysis      Pixel mask(s)    : None
2016-04-25 03:09:07 INFO ImageAnalysis      Region(s)        : None
2016-04-25 03:09:07 INFO ImageAnalysis      Image units      : Jy/beam
2016-04-25 03:09:07 INFO ImageAnalysis      Restoring Beam   : 0.21023 arcsec, 0.192666 arcsec, 79.8538 deg
2016-04-25 03:09:07 INFO ImageAnalysis
2016-04-25 03:09:07 INFO ImageAnalysis      Direction reference : J2000
2016-04-25 03:09:07 INFO ImageAnalysis      Spectral  reference : Undefined
2016-04-25 03:09:07 INFO ImageAnalysis      Velocity  type      : RADIO
2016-04-25 03:09:07 INFO ImageAnalysis      Rest frequency      : 2.33947e+11 Hz
2016-04-25 03:09:07 INFO ImageAnalysis      Pointing center     :  19:23:41.629000  +14.30.42.380000
2016-04-25 03:09:07 INFO ImageAnalysis      Telescope           : ALMA
2016-04-25 03:09:07 INFO ImageAnalysis      Observer            : keflavich
2016-04-25 03:09:07 INFO ImageAnalysis      Date observation    : 2015/04/23/09:47:44
2016-04-25 03:09:07 INFO ImageAnalysis      Telescope position: [2.22514e+06m, -5.44031e+06m, -2.48103e+06m] (ITRF)
2016-04-25 03:09:07 INFO ImageAnalysis
2016-04-25 03:09:07 INFO ImageAnalysis      Axis Coord Type      Name             Proj Shape Tile   Coord value at pixel    Coord incr Units
2016-04-25 03:09:07 INFO ImageAnalysis      ------------------------------------------------------------------------------------------------
2016-04-25 03:09:07 INFO ImageAnalysis      0    0     Direction Right Ascension   TAN  3072  192  19:23:41.629  1536.00 -5.000000e-02 arcsec
2016-04-25 03:09:07 INFO ImageAnalysis      1    0     Direction Declination       TAN  3072  192 +14.30.42.380  1536.00  5.000000e-02 arcsec
2016-04-25 03:09:07 INFO ImageAnalysis      2    1     Stokes    Stokes                    1    1             I
2016-04-25 03:09:07 INFO ImageAnalysis      3    2     Spectral  Frequency                 1    1   2.33947e+11     0.00  1.000000e+09 Hz
2016-04-25 03:09:07 INFO ImageAnalysis                           Velocity                                     0     0.00 -1.281456e+03 km/s
2016-04-25 03:09:07 INFO imhead     ##### End Task: imhead               #####
2016-04-25 03:09:07 INFO imhead     ##########################################


if anything, the ALMA file includes extra data. Removing this data has no effect.

The only really substantial difference left is the order of the axes, which is not what I put in for the ALMA data: it puts Stokes as 2 instead of 3 despite the fact that CTYPE4='STOKES' and CTYPE3='FREQ'.

By doing a round trip FITS->image->FITS->image, I was able to fix the order, but that is not the underlying problem, apparently.

Could the missing pixel mask be at fault? It doesn't jive at all with the error message, so I doubt it. OBSDATE is not the problem.

Turns out, the error is that ALMA is the telescope. I added the header entry:

ffile[0].header['TELESCOP'] = 'NotReal'


and it Just Worked. It is approaching the end of my shift, so I think it is now acceptable to say "what kind of !#$@#$!@% up #@@% is that?!".

• ## Which one is real?

I've "successfully" combined 7m and 12m data, and I've also "successfully" processed 12m data. In both cases, I've self-calibrated the long-baseline 12m data.

The question now is: why are these images so different? There are features in the 12m-only data that are a factor of ~2 brighter than in the 12m+7m data. That should not happen.

This image shows the problem. 7m+12m left, 12m-only right:

Note the sharp features on the left and the small tail (filament) toward the top right that appear in the 12m but not in the 7m+12m data.

Which features are real? How do we decide?

I really want to believe the 12m-only data, but I am very worried that it is artificially enhanced by sidelobes from the e8 filament:

There is a ~20-sigma feature between e8 and e2 along the e8 filament axis, but it is completely absent in the 7m+12m data. That leads me to believe that it is not real, but at such high significance that is very worrisome. I'm also concerned by the loss of the compact source at the bottom of the e8 filament and to the left: these seem unlikely to be affected by the filament.

• ## CLEAN has extreme sensitivity to the threshold

CLEAN diverges sometimes. The point at which divergence begins is very difficult to identify and unfortunately it looks like the images get mostly better as you slowly approach the toxic threshold:

The precise clean command used, with only threshold changing, is:

2016-03-10 07:49:28     INFO    tclean::::      tclean(vis="w51_contvis_selfcal_4.ms",selectdata=True,field="",spw="",timerange="",
2016-03-10 07:49:28     INFO    tclean::::+             uvrange="",antenna="",scan="",observation="",intent="",
2016-03-10 07:49:28     INFO    tclean::::+             datacolumn="corrected",imagename="selfcal_allspw_selfcal_4ampphase_mfs_tclean_deeper_4mJy",imsize=[3072, 3072],cell="0.05arcsec",phasecenter="J2000 19:23:41.629000 +14.30.42.38000",
2016-03-10 07:49:28     INFO    tclean::::+             stokes="I",projection="SIN",startmodel="",specmode="mfs",reffreq="",
2016-03-10 07:49:28     INFO    tclean::::+             nchan=-1,start="",width="",outframe="LSRK",veltype="radio",
2016-03-10 07:49:28     INFO    tclean::::+             restfreq=[],interpolation="linear",gridder="mosaic",facets=1,wprojplanes=1,
2016-03-10 07:49:28     INFO    tclean::::+             aterm=True,psterm=False,wbawp=True,conjbeams=True,cfcache="",
2016-03-10 07:49:28     INFO    tclean::::+             computepastep=360.0,rotatepastep=360.0,pblimit=0.4,normtype="flatnoise",deconvolver="clark",
2016-03-10 07:49:28     INFO    tclean::::+             scales=[],nterms=2,restoringbeam=[],outlierfile="",weighting="briggs",
2016-03-10 07:49:28     INFO    tclean::::+             robust=-2.0,npixels=0,uvtaper=[],niter=100000,gain=0.1,
2016-03-10 07:49:28     INFO    tclean::::+             threshold="4mJy",cycleniter=-1,cyclefactor=1.0,minpsffraction=0.05,maxpsffraction=0.8,
2016-03-10 07:49:28     INFO    tclean::::+             interactive=False,mask="",overwrite=True,savemodel="modelcolumn",calcres=True,
2016-03-10 07:49:28     INFO    tclean::::+             calcpsf=True,parallel=False)


It looks like CLEAN needs a different type of threshold to finish on, perhaps something requiring each subsequent component to be some value less than the previous component. If each component is forced to be less than the previous one, the clean can never diverge, though clean would stop unexpectedly if subtracting a component increased the amplitude of some other part of the map (i.e., if the next brightest source is sitting in a negative bowl). Still, this might be a rarer occurrence than the divergence that I see all the time, which may be related to gridding (given the sharp grid pattern seen in panel 4 of the linked image).

• ## Simulated Observations of Perseus in W51

The W51 and Sgr B2 ALMA mosaics contain ~50 and ~150 pointlike sources, respectively. However, they have pretty miserable high-noise regions such that determining completeness is a serious challenge.

To determine completeness in a means comparable to other observations, I have therefore been using the Gould's Belt Survey Perseus data as an input to do synthetic observations.

It turns out this is technically challenging because CASA does some strange things when importing files.

I finally got a version working.

Important details when reading in a FITS file:

• The header must be fully populated with a 4-dimensional WCS. If stokes or frequency are missing, CASA will choke with uninformative errors such as:

2016-02-26 11:25:24 SEVERE Simulator::createSkyEquation() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2200) Caught exception: (/Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc : 2266) Failed AlwaysAssert spectralIndex>=0 2016-02-26 11:25:24 SEVERE Simulator::predict() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2118) Failed to create SkyEquation

and

2016-02-26 11:27:36 SEVERE Simulator::predict() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2118) Caught exception: (/Users/rpmbuild/gradle/workdir/casasources/release-4_5/casacore/coordinates/Coordinates/CoordinateSystem.cc : 793) Failed AlwaysAssert which < nCoordinates() && coordinates_p[which]->type() == Coordinate::STOKES

• Flux units should be in Jy/beam. Other flux units may be acceptable (e.g., MJy/sr, Jy/pixel), but their behavior is not entirely predictable. I did not get out the expected values when I used MJy/sr as input, but I did not pursue further why this happened. Using Jy/beam, and ensuring that the units were correctly set to Jy/beam in the file (by scaling them in the FITS image before importing), I got the expected results.

• CASA apparently does not read beam information from headers. You need to include the beam information when doing importfits, e.g.:

beam=["{0}deg".format(hdr['BMAJ']),

"{0}deg".format(hdr['BMIN']), "{0}deg".format(hdr['BPA'])]

• CASA will happily read a FITS file into a .image that cannot be used by other casa routines. You will not get an exception until you try a later step.

Once the FITS image is read into a CASA .image, if it has the CASA-expected units and dimensions, you can use sm.predict to fourier transform the data and sample it onto the UV grid in your .ms file:

sm.openfromms("file.ms")
sm.setvp() # "set voltage pattern": not clear if this is needed
success = sm.predict("myfile.image")
sm.done()
sm.close()


This (seems to) populate the data column, not the model column as I had originally expected. Therefore, be warned! DO NOT DO THIS TO YOUR ORIGINAL DATA! It will probably overwrite it.

Once your .ms file is populated, you can clean it as normal. Some examples:

• ## CASA Simulation

More frustration with CASA:

• If you try to load a FITS image into a CASA .image, beware that it is likely to have incorrect units. Round-tripping between .image and .fits doesn't work well, because CASA always assumes that CDELT is in radians even when it is explicitly set to be degrees.

• EDIT: OK, this isn't true in all cases, but if you use imhead to put a keyword value, it will assume radians by default. That can be overcome by explicitly setting the units:

imhead(perseus_casa_image, mode='put', hdkey='CDELT1', hdvalue={'value':hdr['CDELT1'], 'unit':'deg'})

I was able to produce this awkward behavior without imhead as well, though I cannot repeat that now.

The simulator gives this error message if I try to load an image:

sm.setvp() sm.predict(perseus_casa_image)

2016-02-25 09:26:34 SEVERE Simulator::predict() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Simulator.cc, line 2118) Caught exception: TiledShape: #elements in shape and tileShape differ

My best guess is that CASA doesn't understand how to handle 2D images with 3D headers. However, the sensible workaround of expanding the image to 3D does not work.

Re-importing after exporting gets yet another different image. After re-importing an image that was exported to FITS, I get a new error:

Failed AlwaysAssert spectralIndex>=0 2016-02-25 09:37:35

which is rather strange since the spectral index is a physical quantity.

There is also the lovely message:

2016-02-25 09:55:27 INFO importfits No usable restoring beam information found.

for a header that contains these lines:

BMAJ = 1.293900184840E-04 BMIN = 1.293900184840E-04 BPA = 0.000000000000E+00

The image might finally be right, but now I can't find any way to convert it to a model. If I try to ft the model, I get:

2016-02-25 10:54:54 SEVERE ft::imager::ft() (file /Users/rpmbuild/gradle/workdir/casasources/release-4_5/code/synthesis/MeasurementEquations/Imager.cc, line 4488) Exception: (/Users/rpmbuild/gradle/workdir/casasources/release-4_5/casacore/coordinates/Coordinates/CoordinateSystem.cc : 777) Failed AlwaysAssert which < nCoordinates() && coordinates_p[which]->type() == Coordinate::SPECTRAL

which probably means that CASA doesn't know how to turn a single-band continuum image into a model for a multi-frequency .ms (which is all .ms's, including continuum, in the ALMA world).

• ## Retrieving and Selecting Data in CASA

I learned a few important things at the 7m+12m workshop in Garching:

1. clean treats input models in Jy/beam and Jy/pixel qualitatively (not just quantitatively) differently. Jy/pixel images are taken to be model images exactly, where Jy/beam are... somehow interpreted differently, maybe as clean component assemblies. I don't know the details, but this is a major caution.

2. The tbtool is not very good for extracting data for plotting. The flags are not guaranteed to be in a sane shape, which will lead to crashes if you try tb.getcolumn('FLAG'). ms.msselect, however, allows you access to most of the normal selection routines used in clean, split, etc. It is tricky, though, because ms.select does not allow you access to the same selection. Also, while spw-based selection normally allows you to select channels, in ms.msselect it does not: instead you must use ms.selectchannel. See this example.

Details about the selection are at this URL, but the documentation is incomplete and, in places, incorrect:

http://www.aoc.nrao.edu/~sbhatnag/misc/msselection/FrequencySelection.html

(for example, chanspec is not valid in msselect, or at least it doesn't do anything)

• ## A tclean vs clean comparison

Comparing tclean to clean with the following parameters:

clean(vis=vis0, imagename=myimagebase, field="", spw='',
mode='mfs', outframe='LSRK', interpolation='linear',
imagermode='mosaic', multiscale=multiscale, interactive=False,
niter=1000, threshold='100mJy', imsize=imsize, minpb=0.5, cell=cell,
phasecenter=phasecenter, weighting='briggs', usescratch=True,
pbcor=True, robust=-2.0)

tclean(vis=vis0, imagename=myimagebase, field="", spw='',
outframe='LSRK', interpolation='linear', gridder='mosaic',
scales=multiscale, interactive=False, niter=1000,
threshold='100mJy', imsize=imsize, mask='auto-pb', specmode='mfs',
cell=cell, phasecenter=phasecenter, weighting='briggs', robust=-2.0)


Note the very bad cleaning instability creeping in in the clean image:

• ## CASA Selfcal: Good & Awful

Self-calibration is necessary for some images to get a decent dynamic range or to see anything at all in the images. So, I did some tests using self-cal on the central field of Sgr B2 (source) and it worked great:

That image is actually from self-calibrating the whole field, which also worked great. Except, it deleted all the flux outside of the bright regions:

This is awful. It is just deleting flux! I had previously thought that the applyonly option would only apply solutions that it actually found, but that appears not to bt true. Instead, it seems that even phase solutions with no signal are being applied, which effectively removes everything from the image. I could have understood if this was happening to amplitude self-calibration, but I can't understand how it is happening with phase self-cal.

• ## CASA imaging of huge cube

Imaging full cubes, i.e. every channel and every pixel, from ALMA data proved too much for the first few machines I tried it on, so I then tried splitting the cubes into chunks (source).

For the most part, this works well, but there are some serious problems:

Note the range from 233.8-234 GHz. It has a continuum level way above the rest. This is utter nonsense, and turns out to be due to some imaging error. The first image below shows a "good" chunk of the cube, the second image shows a "bad" chunk.

It is clear that the second image was restore using a too-large beam, and this is verified by examining the header:

In [8]: badcube.beam
Out[8]: Beam: BMAJ=1.15963029861 arcsec BMIN=0.96223282814 arcsec BPA=-71.0310058594 deg

In [9]: goodcube.beam
Out[9]: Beam: BMAJ=0.408393889665 arcsec BMIN=0.229679107666 arcsec BPA=45.966835022 deg


I don't yet know what is causing this error. When I try re-doing the clean with tclean, I get the following message, which is a hint:

2016-01-25 09:13:04     WARN    task_tclean::SIImageStore::getPSFGaussian (file
/var/rpmbuild/BUILD/casa-prerelease/casa-prerelease-4.5.0/code/synthesis/ImagerObjects/SIImageStore.cc,
line 1262)      PSF is blank for[C139:P0] [C140:P0] [C141:P0] [C142:P0]
[C143:P0] [C144:P0] [C145:P0] [C146:P0] [C147:P0] [C148:P0] [C149:P0] [C150:P0]
[C151:P0] [C152:P0] [C153:P0] [C154:P0] [C155:P0] [C156:P0] [C157:P0] [C158:P0]
[C159:P0] [C160:P0] [C161:P0] [C162:P0] [C163:P0] [C164:P0] [C165:P0] [C166:P0]
[C167:P0] [C168:P0] [C169:P0] [C170:P0] [C171:P0] [C172:P0] [C173:P0] [C174:P0]
[C175:P0] [C176:P0] [C177:P0] [C178:P0] [C179:P0] [C180:P0] [C181:P0] [C182:P0]
[C183:P0] [C184:P0] [C185:P0] [C186:P0]


Apparently tclean solves this problem! Instead of using a single beam for all channels, it creates a CASAMBM table in the FITS output and uses different beams at each channel. There must be genuinely bad data (probably an atmospheric absorption line) at the specified frequencies. At least now, that will come up more naturally, rather than spiking the data.

« Page 2 / 52 »