Overview

This article describes the calibration and imaging of a single-pointing 6-cm EVLA wideband continuum dataset of the galaxy NGC2967 (UGC5180) which was the location of the supernova candidate SN2010FZ. No supernova was detected in this observation, but the galactic continuum emission from this face-on spiral is nicely imaged. The data were taken in with 1024 MHz of bandwidth in each of two widely spaced basebands (each comprised of 8 128-MHz spectral windows), spanning 4.5 to 7.5 GHz. We will use wideband imaging techniques in this tutorial.

This is a more advanced tutorial, and if you are a relative novice (and particularly for EVLA continuum calibration and imaging), it is strongly recommended that you start with the EVLA Continuum Tutorial 3C391 (at least read it through) before tackling this dataset. We will not include basic information on CASA processing in this tutorial.

In this tutorial we will be invoking the tasks as function calls. You can cut and paste these to your casapy session. We also recommend that you copy all the commands you use, with any relevant commentary, to a text file. This is good practice when tackling large datasets. If you wish, you can use the Script Extractor to create a file with the tutorial commands, which can subsequently be edited as desired.

Occasionally we will be setting Python variables (e.g. as lists for flags) outside the function call so make sure you
set those before running the task command. Note that when you call a CASA task as a function the task parameters you
do not set in the function call (assuming there is at least one) will be set to their defaults, and will not use values
you set in previous calls or outside the call. See Getting_Started_in_CASA#Task_Execution for more
on calling tasks and setting parameters in the scripting interface.

NOTE: If you find that the figures on the right margin of the browser window overlap the text too much and make reading difficult,
go ahead and widen the browser window.

Obtaining the Data

The data for this tutorial were taken with the EVLA under program AS1015 as the scheduling block (SB) AS1015_sb1658169_1.55388.89474846065, and was run on 2010-07-11 from 21:28 to 22:28 UT (size 37.74GB).

If you are brave enough, you can also get the data straight from the EVLA archive. Go to the NRAO Science Data Archive, and search for project **AS1015**. Then select the AS1015_sb1658169_1.55388.89474846065 dataset and choose to apply the online flags (check box "Apply flags generated during observing") and time-averaging of 10 seconds. (The data were taken in D-configuration [max baselines 1km], so one can safely average to 3s or even 10s to reduce dataset size.) Also select the tar option. This will create a file equivalent to what is used at the workshop. (Note that these data will not become public, and will therefore not be downloadable, until 25 Aug 2012.)

Your first step will be to unzip and untar the file in a terminal, before you start CASA:

tar-xzvf SN2010FZ_10s.ms.tar.gz

Starting CASA

To start CASA, type:

casapy

This will run a script to initialize CASA, setting paths appropriately. It will also start writing to a file called ipython.log, which will contain a record of all the text you enter at the CASA prompt.

A logger window will also appear; note that you can rescale this window or change the font size as desired (the latter is under "View"). The messages which are printed to the logger are also saved to a file called casalog.py, and any previous version of casalog.py which may have been present is moved to a backup version with a date stamp. Note that this does not happen for any previous versions of ipython.log, so if you wish to save one, be sure to rename it before restarting CASA.

This task displays a lot of information about the MS. We can see that the observation was performed with the EVLA, for a total integration of 3359 seconds (1 hour). The number of data records (1570726) is equal to the number of baselines (N_antenna * [N_antenna - 1] / 2) X the number of integrations (observing time / time-average binning) X the number of spectral windows. For this observation, this is roughly 351 baselines (27X26/2) X 360 integrations (3600s total/10s avg) X 16 spectral windows = 2021760. Note that this is high by ~30%; this is because the archive already flagged bad data, and there are some scans which only have two (rather than 16) spectral windows present. Extra exercise: examine the MS using browsetable to see what a data record looks like (equivalent to a row, as displayed by this task).

The most useful parts of the listobs output are the scan, field, and spectral window listings.

From the spectral window information, we can see that there were a total of 18 (0 through 17) spectral windows in this dataset. The first two of these (0 and 1) were only used to help set up the correlator.

Looking at the scan listing, we can see that the first four scans which are present used only these spectral windows. These are referred to as "dummy scans". We will not be using these, since they often contain bad data.

The C-band data of interest is contained in scans 6-44 and spectral windows 2 to 17. Careful examination shows that scan 8 is missing but from the time ranges that the data has been merged into scan 7. This sort of correlator back-end data-capture issue was occasionally seen during 2010. Hopefully, it will not affect our data, but we should keep an eye out for problems with scan 7.

The field listing shows three sources:

J0925+0019 (also referred to by its field ID, 0), which will serve as a calibrator for the visibility phases,

SN2010FZ (1), our science target field, and

3C286 (2), which will serve as a calibrator for the visibility amplitudes, i.e., it is assumed to have a precisely known flux density; as well as the spectral bandpass.

Flagging the MS

The online flags, which are a record of known bad data produced by the EVLA online system, have already been applied by the archive as it generated the MS. However, it's good to have a sense of what was deleted in this process. A record of the flags is also stored in a separate table in the MS, called FLAG_CMD. (In fact, the information for this table is actually a subdirectory within the MS; you can see this by listing the contents of SN2010FZ_10s.ms.)

online flags plotted from flagcmd

You can examine the commands stored in the FLAG_CMD table using flagcmd.

Note that we are only plotting the first 285 rows -- this is because the last few are from flagging zeros in the data (caused by correlator errors) and data which have been flagged due to antenna shadowing.

This will bring up a matplotlib plotter. You can have it plot to a PNG file instead:

The flags as plotted in the figure to the above right look normal.
They are color-coded by REASON, and you see OFF_SOURCE flags between scans, and the occasional SUBREFLECTOR flag also between scans (most likely after band changes when the subreflector rotates to
pick up the new feed on the ring, some are slower than others). What you watch for here are long blocks of unexpected flags like FOCUS, which might be false alarms and cause you to flag too much data. In that case, look at the data itself in plotms (see below for examples) to decide whether or not to apply all flags.

plotants plotter

To plot up the antenna positions in the array:

# In CASA
plotants('SN2010FZ_10s.ms')

NOTE: if after this point (or any other) you get "table locks", which may occur erroneously and are sometimes triggered by plotting tasks, use clearstat to clear them:

# In CASA
clearstat

Now we examine the MS looking for bad data to flag. We will use plotms to bring up an interactive GUI that will display 2-D Y vs.X style line plots. NOTE: We do not recommend using the editing/flagging features of plotms. It is very easy to mess up your data this way. Also, to improve speed we will be restricting the scope of plotting so most box/flag operations would not get rid of all the bad data.

We will instead use plotms to identify bad data and then use flagcmd to flag it. This will also allow full scripting of the flagging, which is ultimately the best way to keep track of what's been deleted. Given the large dataset sizes now being generated, reproducibility is extremely important. Imaging spending a day flagging your data, then a disk error corrupts the MS. It's imperative that you have an automated way to regenerate your work. This is also why we encourage you to keep a running file with all the commands you use on a dataset.

WARNING: The Flag button on the plotms GUI is close to other buttons you will be using, in particular the one that gets rid of boxes you have drawn. Be careful and don't hit the Flag button by mistake!

As we found above, the useful spectral windows are 2-17. To get an idea of the data layout, plot a single baseline (ea01&ea02) and channel (31, for all spectral windows) versus time:

Here, we can see the alternating phase calibration and science target scans, as well as the (brighter) flux calibrator at the end of the observation. Feel free to play with ways to view, or color the data: for example, go to the "Display" left-hand tab, and choose "Colorize by: Field". You can also change the size of the plotted points, if they are too small to see easily, by setting "Unflagged Points Symbol" to "Custom" and increasing the number of pixels under "Style".

plotms ant2 vs ea01

Look for bad antennas by picking the last field and plotting baselines versus antenna ea01:

You should be able to see that antenna 11 (= ea13) is bad (very low amplitude, it has no C-band receiver!) and that some of the spectral windows on 15 and 23 (ea17, ea25) are also on the low side. Boxing with the Mark Regions tool and using the Locate tool will show in the logger that spw 10-17 are suspect for these antennas. (Note: you may also leave these in for now if you like; if this were truly a first pass through the data it is unlikely that they would be caught. Since this is a tutorial, and there is limited time for a second pass through the data, it's probably best to trust us and delete them now.)

plotms ea02 vs frequency

Now look at the bandpass for ea02 - it is in the inner core and a prospective reference antenna. Exclude ea13 using negation (represented by "!") in the selection:

There is clearly less data for spw 11, and use of Locate shows spw 11 data only for ea02,ea03,04,08,09,11,12. We will later delete this incomplete spw. Note also the very strong RFI spike at 6614 MHz (spw 10 ch 63) with clear ringing contaminating both spw 10 and 11. There is also a tremendous roll-off in spw 10. We will drop these spectral window when we process the data.

plotms ea02&ea20 iteration phase vs frequency

We can also step through the baselines to our antenna using iteraxis - use the Next Iteration button to step through:

You see the slopes due to residual delays. Mostly a turn or less over a 128MHz subband, but there are some outliers.
Step through to ea20. You see that there is a very large delay in RR (via locate) for
the first baseband (spw 0~7). We will delete this (will also delete LL so there are no orphan polarization products, which would be ignored by clean in the imaging stage).
Note ea17 and ea25 baselines drop close to zero in the middle of upper baseband (e.g. plot 'ea17&ea25') so we will delete these.

To carry out flagging, we again use flagcmd in the mode where it takes a list of command strings:

For now we will not flag these spectral windows, but note the bad channels, which we will mask out when creating continuum calibration tables and images.

Finally, split off the good scans and spw, this will allow us to work on the data without having to start completely over (if we mess something up badly) as well as letting us do simpler data selections. Note that we do not include spw 10, because of the bad RFI, or spw 11, because of the many missing antennas.

Prepare the MS for calibration by adding the "scratch columns" which will contain the model (MODEL_DATA) and the calibrated data (CORRECTED_DATA). This is done by clearcal, which will create the columns if they don't already exist, and initialize their values to be equal to those of the raw data (DATA).

# In CASA
clearcal('SN2010FZ_flagged10s.ms')

Setting the flux density scale

It is now time to begin calibrating the data. The general data reduction strategy is to derive a series of scaling factors or corrections from the calibrators, which are then collectively applied to the science data.
For much more discussion of the philosophy, strategy, and implementation of calibration of synthesis data within CASA, see Synthesis Calibration in the CASA Cookbook and User Reference Manual .

Before calibrating, we insert a model for flux calibration source 3C286 into the MS (in the MODEL_DATA column we just created). In order to do this, we first have to locate the model image on our system with setjy, which we will also use to set the flux density scale. The setjy task (in release 3.3. and later) has an option to list possible model images it knows about:

# In CASA
setjy(vis='SN2010FZ_flagged10s.ms', listmodimages=True)

which sends output to your terminal (but not the logger). For example, on an NRAO workstation:

The relevant image for our purposes is 3C286_C.im, in the directory /usr/lib64/casapy/release/data/nrao/VLA/CalModels. Your system may show a different location (for example /home/casa/data/nrao/VLA/CalModels/, or /Applications/CASA.app/Contents/data/nrao/VLA/CalModels on a Mac). Since it knows about this image, we only have to give the image name and not the entire path. Otherwise, you will need to give it the entire path. We now run the task using this model:

scalebychan=True: will fill the model with per-channel values; otherwise, setjy would use a single value per spectral window.

Inspecting the logger report shows that 3C286 is about 7.7 Jy at lower end of the band to 5.7 Jy at the upper end.

Calibrating delays and bandpass

First, we do a phase-only calibration solution on a narrow range of channels in each spw on the bandpass/flux calibrator 3c286 to flatten them before solving for the bandpass. Note where we saw RFI in the higher spw and avoid those channels. The range 23~28 should work. Pick a refant near center - ea02 is a reasonable bet:

Step through the antenna-based solutions. They look good (and fairly flat over the scans).
NOTE: If you want to make single-page multipanel plots (like those shown to the right), particularly for a
hardcopy (where it only shows the first page), you can do:

We can now solve for the residual antenna-based delays that we saw in phase vs. frequency.
This uses the new gaintype='K' option in gaincal. Note that this currently does not do a "global fringe-fitting" solution for delays,
but instead does a baseline-based delay solution to all baselines to the refant, treating these
as antenna-based delays. In most cases with high-enough S/N to get baseline-based delay solutions
this will suffice. We avoid the beginning of spw 0 due to the extreme roll-off (with loss of S/N) at the
starting edge.

We pre-apply our initial phase table, and produce a new K-type caltable for input to bandpass calibration.
We can plot the delays, in nanoseconds, as a function of antenna index (you will get one for each subband and polarization):

WARNING: You must set solnorm=False here or later on you will find some offsets
between spw due to how amplitude scaling adjusts weights internally during solving.

You will see in the terminal some reports of solutions failing below our default S/N>3 cutoff:

32 of 50 solutions flagged due to SNR < 3 in spw=0 (chan=1) at 2010/07/11/22:26:05.4
44 of 50 solutions flagged due to SNR < 3 in spw=0 (chan=0) at 2010/07/11/22:26:05.4

These are in the first two edge channels of the first spw where the response is low, and not unexpected.
In the logger you will also see reports of reference antennas jumping in those channels, which can be
be safely ignored (we will drop those channels later anyway).

This is the first amplitude-scaling calibration that we do, and thus we have turned on the application
of gain-elevation curves (setting gaincurve=True). If we were at higher frequency we would set
the opacity here also. We will set these in every amplitude solve and application from now
on.

In the bandpass phase you no longer see the residual antenna delays (just residual spw phase offsets from
the delay solution registration) but there are some band edge effects.
Note that some antennas have a little strange bandpasses at upper end of lower baseband in spw 5,6,7
(e.g. ea14,ea16,ea17,ea25).
To plot amp and phase for a single antenna versus frequency (see plots at right):

Because our flux density calibrator 3C286 is bright enough, we were able to use this as the bandpass calibrator.
Since setjy put the correct spectrum for 3C286 into the MODEL_DATA column, our bandpass will reflect the
true bandpass of the instrument. However, if for your observation you were unable to use a source of known spectrum
as the bandpass calibrator, then you would need to follow this bandpass with a second one on a source of known spectrum
in order to take out the spurious bandpass slope introduced by the (unknown) intrinsic spectral shape of your calibrator.

Running bandpass with bandtype='BPOLY' and degamp=1 should suffice to take out a slope, albeit on a per-antenna basis rather than over the entire array. This should work as long as you have enough S/N on your flux calibrator to solve for two polynomial orders (might be hard if you are using very narrow bands at high frequency).

Final phase and amplitude calibration

plotcal G1 phase ant 0~15

plotcal G1 phase ant 16~26

Now calibrate phases using the full bandwidth. First the flux calibrator again, with a per-integration solution time:

NOTE: If there were significant phase variations then you would also do short-timescale phase solutions on
the gain calibrator (field 0), as we did for 3C286, that you would apply only to that calibrator in order to get the amplitude solutions correct. You would still apply the per-scan phases to the target. Because we have good phase stability we will only do per-scan phase solutions on J0925+0019 and use that in both the amplitude solutions and to correct the target phases.

Now solve for amplitudes on a per scan interval. Do these separately using gainfield so phases don't get
transferred across fields. Note that gaincal uses linear interpolation of the previously determined phases by default. Pre-apply the gaincurve as well:

You may see slightly different numbers on your machine. Note that "N" here is the number of antennas x the number of polarizations used for the calculations; in this case, the number of polarizations is 2 (RR and LL).

As it so happens, the derived flux for J0925+0019 is about 1 Jy (you can plot up the raw amplitudes for fields 0,2 and convince yourself this is indeed true and not a bug). The spectrum rises a bit to peak in spw 5 then falls again.

The gains on 3C286 are about 1 (the bandpass solution on 3C286 has absorbed the calibration from counts to Jy) but
fluxscale has adjusted the per-spw scale on J0925+0019 to get its correct spectrum rather than the assumed 1 Jy
flat spectrum.

Applying the Calibration and Final Editing

Next we actually apply all our accumulated calibration tables. We apply these to the
calibration fields individually using the appropriate gainfields and interpolation for each:

For 3C286 (field 2) we did short-timescale phase solutions and a single scan amplitude, so use "linear" and "nearest" interpolation respectively.

For the nearby gain calibrator (field 0) we did only scan-based phase and amplitude solutions so we use "nearest" interpolation

For the target source we use field 0 to calibrate field 1, so use "linear" interpolation. This takes a few minutes.

See figure above right. There is clearly discrepant data visible spw 5 and 6, in particular for baseline ea17&ea25 (use the Mark Regions tool on some of it and then use the Locate tool), which gives a really strange response. You can plot just this baseline to be sure:

Note the characteristic "bowtie" pattern of the phases about the sub-band centers.
Here we can see the effect of the EVLA "delay clunking", where the delay steps through discrete values such that
the phase goes from -11deg to +11deg across the sub-band as the delay changes due to geometry. This is D-configuration so the delays change slowly, it will change faster in wider configurations. As of Q3 2011 we have not enabled the corrections for this in the EVLA system so you will always have this remaining delay error in your data. In principle, you could solve for delays on short timescales and take this out; in practice, this in not possible for your weaker science target source (where it would matter most for results).

Now let's plot the corrected data amplitude for the phase calibrator (field 0):

The last two sub-bands spw 12-13 give reasonable values, with only a tiny offset from spw 8-11.
There are also strange amplitude excursions, particularly in the low end of the first baseband. These must be coming
from one or more scans. You can iterate over scan to see the strange amplitudes (mostly from scan 7):

Also, there is something odd with the amplitudes for spw 5-6, perhaps due to the problem with baseline ea17&ea25 (which we flagged, but didn't recalibrate afterward). This is troubling enough that we will quickly go through a second round of calibration.

A Quick Recalibration

We now go back and recalibrate the data. We may as well flag scan 7 first, as well:

Now split off the data for calibrators and target, to avoid later issues that can corrupt the MSs. We don't keep spw 12-15, since they weren't included in the last round of calibration, and we don't plan to image them.

Imaging

This is EVLA D-configuration data at C-band. To determine the best parameters for imaging, it helps to start with the relevant information in the Observational Status Summary:

Synthesized beam should be 12" at 6 GHz with primary beam field of view of 7.5 arcmin (450")

Our data spans 4.5-7.5 GHz: this is a relatively large fractional bandwidth, resulting in substantial variation of the field of view over the entire frequency range. FOV = 45 arcmin / Frequency (GHz), giving 10 arcmin at 4.5 GHz, and 6 arcmin at 7.5 GHz. Likewise, the synthesized beam ranges from 16" at 4.5 GHz to 9.6" at 7.5 GHz. We want to subsample the synthesized beam by a factor of 3-4, so will use a cellsize of 3". To cover the full FOV (keeping it at the inner part of the image) at the lowest frequencies, we will want an image size of >400 pixels, or >20 arcmin.

We will also use the Briggs robust (with robust=0.5) weighting, which is a compromise between uniform and natural weighting,
and will give reasonable resolution but will allow us to still see larger scale structure.

Due to the numerology of FFTW's (which clean uses under the hood for FFTs) optimal sizes,
imsize should be composite number with two and only two prime factors chosen from
2, 3, and 5. Taking into account the x1.2 padding that clean uses internally to the imsize
you give it (and 1.2 = 2*3/5), we choose 640 or 1280 as our imsize (640 = 2^7*5). Other
reasonable sets would be 405, 1215, etc. (405 = 3^4*5) or 432, 648, 1296 (these are 2^n*3^m*5).
In practice, if you give it non-optimal values for imsize, you may find that the transforms
take a bit longer, which is noticeable if you are doing interactive clean.

WARNING: By default, a single-field nterms=1 clean does NOT use Cotton-Schwab (CS) clean to break
into major cycles going back to data residuals, it just does cleaning in a bunch of minor
cycles in the image plane. This can give much poorer imaging quality in cases with poor
uv coverage (snapshots) or in the case of complex emission structure (like ours) -- clean tends to
diverge in this case. You should explicitly set imagermode='csclean' in your
call to clean. Also, in our case the psf is very good using mfs, so by default it will not
take many major cycle breaks. We use the cyclefactor parameter to control this, which
sets the break threshold to be cyclefactor times the max psf sidelobe level (outside the main
peak). We start at cyclefactor=1.5 in a single spw, and ratchet it up to 4.5 when we
clean all the spw. This seems to work ok. Rule of thumb is if it is gobbling up many hundreds of
clean iterations in the minor cycles early on, increase cyclefactor. Conversely, if your psf is poor
but you source structure is simple, you can reduce cyclefactor (e.g. below 1) to stop it from taking
lots of extra major cycles.

Cleaning a single spectral window

Let us start by interactively cleaning one of the lower baseband spw (spw 5 in this example).
NOTE: this first time will take a few minutes at start to create scratch columns
in the MS in case we want to do self-calibration later.

Note that interrupting clean by Ctrl+C may corrupt your visibilities -- you may be better off choosing to let clean finish. We are currently implementing a command that will nicely exit to prevent this from happening, but for the moment try to avoid Ctrl+C.

Sure enough, there is a bright source near the lower left (see middle panel at right).
Box it, clean it a bit, and look again. There is a second source in the mid-left (track
it down by its sidelobes). Box this one, clean it a bit, and when satisfied stop.

You can use the CASA viewer to display the images that clean creates. If you need more guidance
on using the viewer, see the CASA Viewer Demo video. For now, just bring up your restored image directly:

# In CASA
viewer('imgSN2010FZ10s_spw5_clean1280.image')

The restored image is shown in the bottom panel to the right. I have chosen the Grayscale1 instead of default color
map as I prefer grayscale to false color for assessing image quality. Also, you can change the scaling of the image using the "scaling power cycles" slider under "basic settings".

For this run, the rms is 11.3 uJy (and there is clearly some structure left in the residual). To the right is a zoom-in on the center of the restored image.

Cleaning the lower baseband using two MFS Taylor terms

The mfs nterms=2 option creates two "Taylor Term" images - an average intensity image (with suffix .image.tt0)
and a spectral slope image (with suffix .image.tt1) which is intensity x alpha (where alpha is spectral index).
For convenience there is a spectral index image (with suffix .image.alpha). These Taylor expansions are with respect to the "Reference Frequency" of the image (by default the center frequency of the spw selected, but can be specified using the reffreq parameter in clean). The convention for spectral index alpha is that

Let's try using multi-frequency synthesis with nterms=2 on the lower baseband.
The dirty beam will have lower sidelobes so we turn up cyclefactor for csclean a bit. Note: if you're feeling a bit lazy, and trust your previous set of clean boxes, you can also set mask='imgSN2010FZ10s_spw0to7_clean1280.mask' to use these as a starting point:

For this run, the rms is 10.5 uJy (somewhat better-looking than the nterms=1).
The top screenshot to the right shows an intermediate but early stage of cleaning where we are looking at
the central emission and cleaning it out slowly.

and then use the Open Data panel to load the spectral index image imgSN2010FZ10s_spw0to7_mfs2_clean1280.image.alpha
which can then be blinked (optionally plotted side-by-side using the Panel Display Options panel to set 2 panels in the x direction).

Cleaning using both basebands combined

For the ultimate image, use the "clean" part of the upper baseband in addition
to the lower (use spw 0-11). We will use mfs with nterms=2 (if you try nterms=1
on this wide bandwidth you will get much poorer residuals). Because of the added
work and extra data involved, this will take much longer than our other runs of
clean. Therefore, we will get a head start by doing a non-interactive clean using
the mask left from the previous clean (spw 0-7). We will insert a clean threshold
to limit runaway cleaning too far beneath the noise level.

This will take a while, especially if there are other processes running on your machine (with nothing else running, expect ~30-40 minutes).

You might find a few more sources revealed in the outer parts of the image, and also more
emission around the galaxy disk in the center. Try drawing new boxes, perhaps extend the box
in the center, and do ~100-1000 more iterations. At the end, what is left should be dominated
by the error patterns from mis-calibration. Only self-calibration will get rid of
these. Stop cleaning for now. See the figure to the right for the interactive display panel
showing final residuals and mask (changing the colormap to Greyscale 1).

(listing columns truncated) and we estimate about 37 minutes on target. We had about 25 antennas on average, and our spw selection picked out 610 channels (2 MHz each) for a total of 1220 MHz bandwidth. If we plug this
into the
EVLA exposure calculator, at 5 GHz, we find that we expect a rms thermal noise level of 8.7 uJy, and at 7 GHz, 7.0 uJy. So, our values are within the expected range (a bit higher than theoretical, but that's expected).

final image

Look at this in the viewer:

# In CASA
viewer('imgSN2010FZ10s_spw0to11_mfs2_clean1280.image.tt0')

Zoom in on the center (see figure to the right).

final tt1 image with box

In the previous section we demonstrated how to process and display the spectral index image. You can do
the same for this final image. Here, we will do some rough analysis on the spectral index to determine
an intensity-weighted mean spectral index over the core region.
The .image.tt1 from our mfs is an intensity times alpha image. See the figure to the right.
Let's gate the Taylor-term images on intensity:

We can identify a box containing the central emission (see figure of tt1 in viewer) and note the corners.
(We could also use the region tools from the viewer, but that is for another exercise.)
Let us compute the intensity-weighted spectral index over this box by averaging
these masked images using imstat and computing the ratio:

The emission in this source is on the steep side. At this point we do not know how reliable this is or
what we expect (though our calibrators come out with correct spectral indexes if we image them the
same way). But this illustrates a way to extract spectral information from our wideband mfs images.

Comparing with the Optical/Infrared

As a final comparison, we turn to the Sloan Digital Sky Survey (SDSS) and a cutout image of our galaxy:

from their RC3
album (courtesy D.Hogg, M.Blanton, SDSS collaboration - see #Credits). This looks like a nice nearby
face-on spiral galaxy. How does our 6cm continuum emission line up with the optical?

Here is the EVLA 6cm image side by side with a i-band image from the Sloan Digital Sky Survey (SDSS) registered to our image:

We can also plot one as a raster and the other overlaid as contours. You can load the SDSS image
from the viewer Load Data panel and fiddle with contours. Once you know contour levels, you can
also use the imview task to load a raster and contour image:

This is shown in the figure below. Is the compact 6cm emission in upper left associated with a
spiral arm?

SDSS i-band raster plus EVLA 6cm contours

What to do next: some exercises for the user

Here are a number of things you can try after completing this tutorial:

Use self-calibration to improve the data and re-clean to make a better image. See this tutorial for more information on self-calibration.

Use multi-scale clean by adding non-zero scales to the multiscale parameter.

Image the calibrators. What sort of dynamic range can you get on them? Is self-calibration needed (and if so what dynamic range do you get when you use it)?

Try the testautoflag task (in 3.3.0 and later) to automatically flag RFI from the upper sideband. There is more information on running testautoflag in this tutorial.

Credits

The EVLA data was taken by A. Soderberg et al. as part of project AS1015. See
NRAO eNews 3.8 (1-Sep-2010) for more on this result.

The Expanded Very Large Array (EVLA) is a partnership of the United States, Canada, and Mexico. The EVLA is funded in the United States by the National Science Foundation, in Canada by the National Research Council, and in Mexico by the Comisión Nacional de Investigación Científica y Tecnológica (CONICyT).

The National Radio Astronomy Observatory is a facility of the National Science Foundation operated under cooperative agreement by Associated Universities, Inc.

Funding for the SDSS and SDSS-II has been provided by the Alfred P. Sloan Foundation, the Participating Institutions, the National Science Foundation, the U.S. Department of Energy, the National Aeronautics and Space Administration, the Japanese Monbukagakusho, the Max Planck Society, and the Higher Education Funding Council for England. The SDSS Web Site is [1].

The SDSS is managed by the Astrophysical Research Consortium for the Participating Institutions. The Participating Institutions are the American Museum of Natural History, Astrophysical Institute Potsdam, University of Basel, University of Cambridge, Case Western Reserve University, University of Chicago, Drexel University, Fermilab, the Institute for Advanced Study, the Japan Participation Group, Johns Hopkins University, the Joint Institute for Nuclear Astrophysics, the Kavli Institute for Particle Astrophysics and Cosmology, the Korean Scientist Group, the Chinese Academy of Sciences (LAMOST), Los Alamos National Laboratory, the Max-Planck-Institute for Astronomy (MPIA), the Max-Planck-Institute for Astrophysics (MPA), New Mexico State University, Ohio State University, University of Pittsburgh, University of Portsmouth, Princeton University, the United States Naval Observatory, and the University of Washington.