• ## What does feather do?

This is an examination of the 'feather' task in CASA.

First we have to track down what code is actually called.

On mac, this is:

• /Applications/CASA.app/Contents/Resources/python/feather_cli.py -> feather_cli
• Imager.cc

Within the imager, setvp is used to do something with the primary beam. As far as I can tell, this function spews a lot of text into the logger, sets local variables, sets one larger-scope variable BeamSquint::, then does destroySkyEquation();. In short, I don't know what this does. Probably my reading of the C code is incorrect and these variables are not local, in which case it is just setting a bunch of default beam parameters.

Then, Imager.cc calls Feather.cc.

Feather sets parameters based on the effective dish diameter. It uses 1.22*(speed of light)/frequency/dish_diameter, so it is retrieving the FWHM assuming a Gaussian beam by default.

A lovely aside: Imager.cc passes the local variable lowPassFilterSD to Feather.cc, which is read in to the input boolean parameter doHiPassFilterOnSD. That seems like a potential place for confusion.

If doHiPassFilterOnSD is set or the effective beam diameter is set as a parameter, the single dish image is deconvolved with its beam using the GaussianDeconvolver. This is actually disabled by default, though.

The low resolution image is regridded to match the high resolution image.

The applyFeather command seems to do the actual work. It starts with calcCWeightImage, which sets the "weight" to one minus the peak-normalized fourier transform of the low-resolution (single-dish) beam Feather.cc line 427, with the result stored in the variable cwImage_p. applyFeather then just multiplies the high-resolution image by this weight.

Back in the saveFeatheredImage task, the single-dish data are fourier transformed, then a scaling factor, the ratio between the low and high beam areas, is computed. Finally, the single-dish (scaled) and interferometer fourier-transformed images are added.

Is the single-dish image weighted by the beam at all? The single-dish image will be convolved with a kernel only if doHighPassFilterOnSD is set or if the effective dish diameter is set. If the beam is the same size as the original beam, nothing will happen. In setEffectiveDishDiam the low-resolution image is convolved with the *deconvolved* beam.

The most important note in this post is that the single-dish image is not weighted unless doHighPassFilterOnSD is set, and even then nothing will be done if the single-dish beam size passed as a parameter is the same as the beam size specified in the header. That means only the interferometer image is weighted. Maybe that is the correct behavior? By weighting by (1-convolved beam), which means setting the total flux in the interferometer image to zero, the process is guaranteed to be flux conserving.

• ## CASA coordinate defaults

A brief public service announcement: CASA coordinate strings follow a convention of their own making that I at least find thoroughly counterintuitive. If you specify a sexagesimal coordinate, e.g. 05:12:15.3 -5:10:20.5 or something similar, CASA interprets that as 5 hours, -5 hours. The declination is interpreted as being in hours. Those are units no one has ever used. The CASA version requires the second half of the sexagesimal string to be decimal separated:

2016-05-19 00:45:13     WARN    SynthesisParams::stringToMDirection (file /var/rpmbuild/BUILD/casa-prerelease/casa-prerelease-4.6.0/code/synthesis/ImagerObjects/SynthesisUtilMethods.cc, line 786)     You provided the Declination/Latitude value "-28:23:29.22" which is understood to be in units of hours.
2016-05-19 00:45:13     WARN    SynthesisParams::stringToMDirection (file /var/rpmbuild/BUILD/casa-prerelease/casa-prerelease-4.6.0/code/synthesis/ImagerObjects/SynthesisUtilMethods.cc, line 786)+    If you meant degrees, please replace ":" by ".".


This has broken my scripts more than a handful of times now, since copying & pasting coordinates from any other program inevitably has the "wrong" units.

• ## CASA tclean adds negative components

I'm trying to examine some of my 7m+12m combined data and have run into yet another mysterious behavior of CASA. tclean is adding negative components in regions with exclusively positive emission.

In this image, the left is the clean image, which doesn't make any sense; it looks like it should be a residual image but it is not. 2nd image is the clean components (negative!!), 3rd is the residual, 4th is the dirty map.

One tricky thing for this particular image is that the emission is real, BUT it is also directly on top of a major sidelobe of the brightest source in the region. Nonetheless, I cannot imagine any way to explain the negative component. I don't really understand when a negative component is added, but presumably it ought to happen when the residual has a negative value but also the highest amplitude in the map; this obviously never happens here since the residual in fact has one of the highest positive amplitudes in the map.

The imaging parameters seem not to affect this problem. I attempted reducing the gain to 0.05 to no avail. Changing from natural to robust weighting actually removed most of the negative components.

## Failed combination of 7m and 12m data

The above was a tangent. The real reason I was working on this data set was to combine the 7m and 12m spectral data. The problem I keep seeing is very large, smooth blobs that are spatially distinct from the more compact emission. It's as if someone took the two independent cubes (12m and 7m) and just added them together; it looks like flux is not being conserved.

The UV plots, especially weight vs uvdist, look fine. The 7m antenna are downweighted relative to the 7m antennae by a factor ~2.

One of the bigger problems is that I have a vague - possibly not justified - sense that there is a velocity offset of ~1 km/s between the 7m and 12m data. If this is the case, there's no wonder the combination isn't working. However, it's nearly inconceivable.

## Followup Feb 2017

That vague fear turned out to be entirely justified. It turned out that the 7m and 12m array data sets were not in a common frame, and they were therefore offset by something like the Earth's change in velocity between the observation dates. The solution was to cvel the data sets to the LSRK frame prior to concatenating them. While I know I made these changes, I unfortunately can't find the specific commit where I made them.

• ## 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...

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']


['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 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      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: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


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::::+             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::::+             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:

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)

« Page 2 / 52 »