GGTAU (Part 1)

                                                                                                                                                                                 
Testing - GG Tau regression script

Working in CASA daily.  In the NAUG meeting Joe said that a new stable
would be released on Friday but there was no note on Friday that I saw
that the stable was released.  Maybe it will be out on Monday.
Continue to work in daily.

first: print out the aips++ script that I figured out earlier so I
       know what should happen.  This casa script follows the aips++
       script.


DSS - 24feb07
-----------------------------------------------------------------------
Summary of issues:

- Summary on flagging issues: It is very difficult and frustrating to
  work around bugs in the viewer, flagxy and flagdata.  These bugs
  have to be fixed before the test or non-experts will likely not be
  able to flag their data or they will manage to flag their data but
  be totally unhappy about the state of the package.  Bugs identified
  below.  

  NOTE: the flagdata fieldid bug means that the regression script is
        not working to flag data in fieldids 1,2,3.  Would this ever
        be noticed?  


- flagxy/plotxy cannot plot all channels in an spwid
  restore()
  flagxy(vis='ggtau_07feb97.ms', xaxis='channel', yaxis='amp', 
       datacolumn='data', field='0415',  
       correlations='XX', 
       nchan=60, start=1,
       spwid=[2], plotsymbol = ',', multicolor=true)
  # only one channel is being displayed.  inp flagxy says:
  # nchan = '60'     #  Number of channels to select (mode=channel) 
  # start = ' 1'     #  Start channel, 0-relative 
  # width = ' 1'     #  Channel width (value>1 indicates averaging) 
    ==> 60 channels should be displayed.  What goes? 
  # I tried this a second time and 5 channels are displayed but at
    wierd increments (0, 0.2, 0.5, 0.75, 2.7 channels) 
  # I tried this a 3rd time and now I get 16 channels displayed. 

restore()
flagxy(vis='ggtau_07feb97.ms', xaxis='channel', yaxis='amp', 
       datacolumn='data', field='0415',  
       correlations='XX', 
       nchan=50, start=10,
       spwid=[2], plotsymbol = ',', multicolor=true)
 # darn, only 3 channels displayed and channel axis is messed up.  
 # 2nd try: 1st 16 channels displayed again.  
  This is a strange bug.  

- The viewer is not working on its source selection.  I try to flag a
  few channels in just one source but it flags them in all sources.
  Details below

  viewer 
  tb.clearlocks()

  spw2 - 4 channels (31-34) have gibbs ringing in 0415
         2 channels (31-32) have gibbs ringing in 0528 

  There is a problem with the selection and flagging of data.  I
  select field 0, spwid 2, flag 4 gibbs channels, But channels are
  flagged for all fields no matter what I do.  Looks like I cannot use
  the viewer to flag the gibbs channels.  Unflag everything and exit.

- flagdata warnings are scary and unnecessary.  Please remove: 
  note: received many warnings when flagdata was run on one source and
  one spwid: 
  Sat Feb 24 18:51:13 2007      WARN autoflag::run():
  Unable to process this chunk with any active method.
  # these appear to be for spwids that do not "match in this chunk",
    e.g. other spwids not selected.  
    This is not a good message.  If the data is not selected, then
    don't give a warning that it can't be flagged.  Only give warnings 
    when data is selected and can't be flagged.  Else, just give 
    positive feedback that the flagging is complete and worked as
    expected. 

- flagdata fieldid selection is not working: 
  flagdata('ggtau_07feb97.ms',fieldid=[0,1,3],spwid=2,chans=[31,32])
  # command line says: 
   fldlist is  ['0415']
   Selected fields are:  ['0415+379']
   # fieldid selection is not working.  I didn't notice this at
   # first because of all the WARN messages that flew by.  
   # After much testing, I found that fieldid was not changing from
   # default (0), I can use field to select the name to work around
   # this problem.  

- Still getting table lock problems each time I bring up the viewer.  

- flagdata('ggtau_07feb97.ms',field='crl',spwid=2,chans=[31,32])
  # command line says: 
    fldlist is  ['crl']
    Selected fields are:  []
    # Apparently it couldn't find source 'crl' maybe it is case 
      sensitive.  So it went out and flagged all sources.  Not a good
      default.  If it can't find the source name then it should tell 
      the user that the name is not found and not do anything.  Good
      thing I wanted these channels flagged in all sources... 

- I forgot, plotcal can't handle gspline solutions, I tried: 
  plotcal(tablein='ggtau.3mm.ph.gcal0',multiplot=false)
  # Exception Reported: Cube: ndim of other array > 3
  # *** Error *** Cube: ndim of other array > 3
    # I guess plot cal still can't plot gspline solutions.  This
      error message doesn't help the user figure out why the error.  
      I recommending making this a different error (e.g. 
      SEVERE: can't plot GSLPINE solutions with plotcal

- After generating GSPLINE solutions, I want to evaluate the
  solutions.  But there appears to be no way to do this.  No psfile of
  the solution is generated like AIPS++ did so there is NO feedback on
  whether this is a good solution.  This is not a good situation to be
  in.  The user should always be able to have at least something that
  lets evaluate whether a solution is good.  I tried using the table
  browser: 

  browsetable 'ggtau.3mm.ph.gcal0'
   # this doesn't help much. Everything is in sub-tables that I have
     to click on.  After clicking many times on many columns, I
     finally found non-zero values in the Poly_coeff_phase column.  I
     tried to use the plot function to plot this versus anything but I
     kept getting invalid messages saying this was 4D.  So I now know
     that numbers were generated but I have no way of evaluating them.

- The following is either a mistake in the script or a problem with
  the naming of a keyword input or a problem with the documentation: 
  gaincal('ggtau_07feb97.ms', 'ggtau.3mm.amp.gcal', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	gaintype='GSPLINE', calmode='a', splinetime=20000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=2500., 
	pointtable='ggtau.3mm.ph.gcal')
 # this is wierd, a pointing calibration solution table is specified.  
   According to in-line help, this should be called a gaintable

   The logger says: 
    The following calibration terms are arranged for apply:
      BPOLY: table=ggtau.3mm.bpoly select=  calWt=false
      GSPLINE: table=ggtau.3mm.ph.gcal select=  calWt=false
    GSPLINE: table=ggtau.3mm.amp.gcal  append=false 
	     t=1.79769e+308 refant=0 phaseonly=false

  So it sort of looks like it used the pointing table for this gspline
  application.  Is this a mistake in the script?  Or is this
  pointtable the only thing that can handle GSPLINE solutions?  If the
  latter, then this should be explained in the inline help.

  another possible issue with the script: 
  correct('ggtau_07feb97.ms', msselect='DATA_DESC_ID==2',
        gaincurve=False, opacity=False, gaintable='ggtau.3mm.ph.gcal',
	bptable='ggtau.3mm.bpoly', pointtable='ggtau.3mm.amp.gcal')

  # The pointing calibration solution table is specified again and now
    the gaintable is the phase-only solutions.  According to the script
    (and this is how aips++ did things), the phase solutions were
    pre-applied to the amp solutions and "carried forward to the output
    solution table".  Thus, you should only have to apply
    gaintable='ggtau.3mm.amp.gcal' and forget about the pointtable
    specification.  Again, is this an error in the script? 

    When I run this it says that both tables are applied to the
    source.  Did I just apply the phase solutions twice?  

  However, I made images with and without the pointing table: 
   # there is a very definite difference in the striping between the
     images.  So there is a phase shift introduced between the two
     ways of calibrating.  But, actually, the one that used the
     pointtable looks better.  So maybe the script is correct but the
     documentation in the in-line help and the script is wrong.
     Besides, I think that application of a pointing table should not
     be used to apply gain solutions.


- the restore function doesn't set *everything* back to its default
  value: 
  restore
  gaincal('ggtau_07feb97.ms', 'ggtau.3mm.amp.gcal2', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	gaintype='GSPLINE', calmode='a', splinetime=20000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=2500., 
	gaintable='ggtau.3mm.ph.gcal')
  # logger says:
    The following calibration terms are arranged for apply:
     BPOLY: table=ggtau.3mm.bpoly select=  calWt=false
     GSPLINE: table=ggtau.3mm.ph.gcal select=  calWt=false
     GSPLINE: table=ggtau.3mm.amp.gcal select=  calWt=false

   # this doesn't look good, how does it even know about the
     ggtau.3mm.amp.gcal table?  I did a restore first.  But the
     pointtable specification is still in there.  This is wrong. 
  restore
  inp gaincal
   # nope, the pointtable was not removed.
  default('gaincal')
   # OK. Now the pointtable is reset to nothing.  So it looks like the
     restore function doesn't actually set *everything* back to
     default.  

- The viewer crashes:
  I brought in both source images, blinked between them (worked
  nicely) then tried to deregister the 1st one I brought in and the
  viewer crashed.  This error is repeatable.


-----------------------------------------------------------------------
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Actual detailed test notes:

alias casadaily 'source /home/ballista/casa/daily/casainit.csh; casapy'
casadaily

Regression scripts:  https://safe.nrao.edu/wiki/bin/view/Software/LegacyCASA

NOTE: refant = NAME now, not ID #
      ==> previous scripts will get the wrong antenna because they
      specified ID #.  

Useful commands to work around problems:
------------------------------------------
tb.clearlocks()
mp.clearplot
restore()

#

copied ggtau_regression.py from the test web site.  

casadaily


import os
pathname=os.environ.get('AIPSPATH')
pathname
  Out[3]: '/home/ballista/casa/daily'
datapath=pathname+'/data/regression/ATST1/GGTAU/07feb97-g067.ms'

!cp -r /home/ballista/casa/daily/data/regression/ATST1/GGTAU/07feb97-g067.ms .
!mv 07feb97-g067.ms ggtau_07feb97.ms

Just in case, set the model_data column to unity and corrected_data to
data:

clearcal('ggtau_07feb97.ms')
listobs('ggtau_07feb97.ms', verbose=true)
 # in 0.summary.ggtau.txt
 # annotated the summary to hand out to the testers.  

# FLAG bad data.  According to script: 
flagdata('ggtau_07feb97.ms',fieldid=[0,1,3],spwid=2,chans=[31,32])
# flag channels 33,34 which are low for source 0415+379 (fieldid=0)
flagdata('ggtau_07feb97.ms',fieldid=[0],spwid=2,chans=[33,34])
# flag channels 34-37 for CRL 618 (fieldid=3) and baseline 1-3,2-4
flagdata('ggtau_07feb97.ms',fieldid=[3],baseline=[0,2],chans=[34,37])
flagdata('ggtau_07feb97.ms',fieldid=[3],baseline=[1,3],chans=[34,37])

But, of course, the user will not know this ahead of time so use
viewer or plot/flagxy to find the bad data and flag it. 

restore()
flagxy(vis='ggtau_07feb97.ms', xaxis='time', yaxis='amp', datacolumn='data', 
       field='0415',  
       correlations='XX', 
       spwid=[2], plotsymbol = ',', multicolor=true)
 # wow, time labels are at an angle so you can read them.  cute.  
restore()
flagxy(vis='ggtau_07feb97.ms', xaxis='channel', yaxis='amp', 
       datacolumn='data', field='0415',  
       correlations='XX', 
       nchan=60, start=1,
       spwid=[2], plotsymbol = ',', multicolor=true)
 # only one channel is being displayed.  inp flagxy says:
 # nchan = '60'     #  Number of channels to select (mode=channel) 
 # start = ' 1'     #  Start channel, 0-relative 
 # width = ' 1'     #  Channel width (value>1 indicates averaging) 
   ==> 60 channels should be displayed.  What goes? 
 # I tried this a second time and 5 channels are displayed but at
   wierd increments (0, 0.2, 0.5, 0.75, 2.7 channels) 
 # I tried this a 3rd time and now I get 16 channels displayed. 

restore()
flagxy(vis='ggtau_07feb97.ms', xaxis='channel', yaxis='amp', 
       datacolumn='data', field='0415',  
       correlations='XX', 
       nchan=60, start=0,
       spwid=[2], plotsymbol = ',', multicolor=true)
 # now 16 channels are being displayed, but not all 60 selected. 
   There must be a bug in nchan/start for flagxy, plotxy behaves
   similarily (16 channels displayed) 

restore()
flagxy(vis='ggtau_07feb97.ms', xaxis='channel', yaxis='amp', 
       datacolumn='data', field='0415',  
       correlations='XX', 
       nchan=50, start=10,
       spwid=[2], plotsymbol = ',', multicolor=true)
 # darn, only 3 channels displayed and channel axis is messed up.  
 # 2nd try: 1st 16 channels displayed again.  
   I won't be able to use flagxy to flag the gibbs channels... 

viewer - lock file bug again...
tb.clearlocks()

spw2 - 4 channels (31-34) have gibbs ringing in 0415
       2 channels (31-32) have gibbs ringing in 0528 

There is a problem with the selection and flagging of data.
I select field 0, spwid 2, flag 4 gibbs channels, But channels are
flagged for all fields no matter what I do.  Looks like I cannot use
the viewer to flag the gibbs channels.  Unflag everything and exit.  

Revert to the regression script and see if flagdata works.  

flagdata('ggtau_07feb97.ms',fieldid=[0,1,3],spwid=2,chans=[31,32])
 # dach: command line says: 
   fldlist is  ['0415']
   Selected fields are:  ['0415+379']
   Dach, fieldid selection is not working.  I didn't notice this at
   first because of all the WARN messages that flew by.  

flagdata('ggtau_07feb97.ms',fieldid=[0],spwid=2,chans=[33,34])

# note: received many warnings: 
  Sat Feb 24 18:51:13 2007      WARN autoflag::run():
  Unable to process this chunk with any active method.
  # these appear to be for spwids that do not "match in this chunk",
    e.g. other spwids not selected.  
    This is not a good message.  If the data is not selected, then
    don't give a warning that it can't be flagged.  Only give warnings 
    when data is selected and can't be flagged.  Else, just give 
    positive feedback that the flagging is complete and worked as
    expected. 

viewer
tb.clearlocks()

Humm, field 0 was flagged OK but fields 1 and 3 were not. 
flagdata is not working...  Try one field at a time. 


flagdata('ggtau_07feb97.ms',fieldid=[1],spwid=2,chans=[31,32])
 # still doesn't work, only fieldid 0 is selected: 
   fldlist is  ['0415']
   Selected fields are:  ['0415+379']

flagdata('ggtau_07feb97.ms',field='0528',spwid=2,chans=[31,32])
 # finally.  
   fldlist is  ['0528']
   Selected fields are:  ['0528+134']
   # OK, the proper field was selected using field name but now I'm
   really worried.  The 3rd chunk (I think this is spwid 2) got the
   WARN message that it could not be processed. Some chunk in the
   middle of the spwids got flagged.  Use viewer to see what
   happened. 

viewer
tb.clearlocks()
 # getting table lock problems each time I bring up the viewer.  

 # OK, viewer says correct data was flagged.  

flagdata('ggtau_07feb97.ms',fieldid=[3],spwid=2,chans=[31,32])
 # command line says: 
   fldlist is  ['0528']
   Selected fields are:  ['0528+134']
   # Second source was flagged instead of the 4th... 
   # I think fieldid is not being used, I forgot to do the
     restore again and it used the field set before.  


flagdata('ggtau_07feb97.ms',field='crl',spwid=2,chans=[31,32])
 # command line says: 
   fldlist is  ['crl']
   Selected fields are:  []
   # Oh man, apparently it couldn't find source 'crl' maybe it is case 
     sensitive.  So it went out and flagged all sources.  Not a good
     default.  If it can't find the source name then it should tell 
     the user that the name is not found and not do anything.  Good
     thing I wanted these channels flagged in all sources... 

In any event, I finally got the Gibbs channels correctly flagged.
This is very difficult and frustrating working around bugs in the
viewer, flagxy and flagdata.  These bugs have to be fixed before the
test or non-experts will likely not be able to flag their data or they
will manage to flag their data but be totally unhappy about the state
of the package.  

# I'm tired of dealing with the bugs here - just trust the script to
  flag the rest (using names rather than fieldids.

# flag channels 34-37 for CRL 618 (fieldid=3) and baseline 1-3,2-4

restore()
flagdata('ggtau_07feb97.ms',field='CRL618',baseline=[0,2],chans=[34,37])
 # fldlist is  ['CRL618']
 # Selected fields are:  ['CRL618  ']

restore()
flagdata('ggtau_07feb97.ms',field='CRL618',baseline=[1,3],chans=[34,37])
 # fldlist is  ['CRL618']
 # Selected fields are:  ['CRL618  ']

viewer
tb.clearlocks()

OK, appropriate data is flagged.  Move on.  

#######################################################################
# 3 mm Continuum calibration
# setjy
setjy('ggtau_07feb97.ms',fieldid=3,spwid=2,fluxdensity=[1.55,0.,0.,0.])
 # CRL618    spwid=  2  [I=1.55, Q=0, U=0, V=0] Jy, (user-specified)

# preliminary time-dependent phase solutions to improve coherent
  average for bandpass solution: 
restore
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.ph.gcal0', 'channel', 
        nchan=30, start=14, step=1, 
	msselect='FIELD_ID==1 && DATA_DESC_ID==2', gaintype='GSPLINE',
	calmode='p', splinetime=10000., refant='1', phasewrap=260, 
	gaincurve=False, opacity=False, preavg=120)
 # all values set as in app script.  
 # field and spwid are 0 indexed, refant is now a name so it was index
   1 in app but name 1 here.   So OK.  
 # one missing parameter: npointaver=10, but this is the default so OK
   to not mention it. 
plotcal(tablein='ggtau.3mm.ph.gcal0',multiplot=false)
 # Exception Reported: Cube: ndim of other array > 3
 # *** Error *** Cube: ndim of other array > 3
 # I guess plot cal still can't plot gspline solutions.  This
   error message doesn't help the user figure out why the error.  
   I recommending making this a different error (e.g. 
   SEVERE: can't plot GSLPINE solutions with plotcal

# unfortunately, no psfile of the solution is generated either like
  AIPS++ did so there is NO feedback on whether this is a good
  solution.   This is not a good situation to be in.  The user should
  always be able to have at least something that lets evaluate whether
  a solution is good.  

browsetable 'ggtau.3mm.ph.gcal0'
 # this doesn't help, Everything is in sub-tables that I have to click
   on.  After clicking many times on many columns, I finally found
   non-zero values in the Poly_coeff_phase column.   I tried to use
   the plot function to plot this versus anything but I kept getting
   invalid messages saying this was 4D.  So I now know that numbers
   were generated but I have no way of evaluating them. 
 
# derive bandpass calibration for 3mm LSB
restore
bandpass('ggtau_07feb97.ms', 'ggtau.3mm.bpoly', 'channel', nchan=60,
         start=3, step=1, msselect='FIELD_ID==1 && DATA_DESC_ID==2',
	 bandtype='BPOLY', degamp=6, degphase=12, bpnorm=False,
	 maskcenter=4, maskedge=0, refant='1', 
	 gaintable='ggtau.3mm.ph.gcal0', gaincurve=False,
	 opacity=False) 
 # all as in app script.
restore
plotcal(tablein='ggtau.3mm.bpoly',multiplot=false, yaxis='amp')
 # very nice plot, cute colors.  
restore
plotcal(tablein='ggtau.3mm.bpoly',multiplot=false, yaxis='phase')


# derive new and better phase solutions for 3mm LSB
restore
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.ph.gcal', 'channel', 
        nchan=60, start=2, step=1, 
        msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2', 
	gaintype='GSPLINE', calmode='p', splinetime=10000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=0.)
 # all as in app script.


# Apply all solutions derived so far, determine calibrator's flux
  densities by solving for T and using fluxscale 
restore
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.temp', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	solint=600., refant='1', gaintype='T', opacity=False,
        gaincurve=False, gaintable='ggtau.3mm.ph.gcal',
	bptable='ggtau.3mm.bpoly') 

plotcal(tablein='ggtau.3mm.temp',multiplot=false, yaxis='amp')
plotcal(tablein='ggtau.3mm.temp',multiplot=false, yaxis='phase')
 # there is an amplitude drop out on one of the gain solutions (3rd
   from the end) on a light blue antenna but I can't tell what the
   problem is.  I sure would like a locate function on plotcal...
   Phase look OK.  Proceed.  


# fluxscale
fluxscale('ggtau_07feb97.ms', 'ggtau.3mm.temp', 'ggtau.3mm.flux', 
	  reference=['CRL618'], transfer=['0415+379','0528+134'])
 # Exception Reported: Reference field name matching error
 # *** Error *** Reference field name matching error
 # well, I wondered why there were spaces in the CRL618 field.  
   CASA should truncate spaces at the end here.  

fluxscale('ggtau_07feb97.ms', 'ggtau.3mm.temp', 'ggtau.3mm.flux', 
	  reference=['CRL618  '], transfer=['0415+379','0528+134'])
 # Flux 0415+379 SpW=2 is: 5.85069 +/- 0.0273231 (SNR = 214.13, nAnt= 5)
 # Flux 0528+134 SpW=2 is: 2.61256 +/- 0.0116824 (SNR = 223.632, nAnt= 5)
 # OK, close to what the script reports. 

# manually set the flux density: 
restore
setjy('ggtau_07feb97.ms', fieldid=0,spwid=2,fluxdensity=[5.849,0.,0.,0.])
setjy('ggtau_07feb97.ms', fieldid=1,spwid=2,fluxdensity=[2.634,0.,0.,0.])

## Amplitude calibration of 3mm LSB:
##  phase solutions will be pre-applied as well as carried forward 
##   to the output solution table.
restore
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.amp.gcal', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	gaintype='GSPLINE', calmode='a', splinetime=20000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=2500., 
	pointtable='ggtau.3mm.ph.gcal')
 # this is wierd, a pointing calibration solution table is specified.  
   According to in-line help, this should be called a gaintable

   The logger says: 
    The following calibration terms are arranged for apply:
      BPOLY: table=ggtau.3mm.bpoly select=  calWt=false
      GSPLINE: table=ggtau.3mm.ph.gcal select=  calWt=false
    GSPLINE: table=ggtau.3mm.amp.gcal  append=false 
	     t=1.79769e+308 refant=0 phaseonly=false

  So it sort of looks like it used the pointing table for this gspline
  application.  Is this a mistake in the script?  Or is this
  pointtable the only thing that can handle GSPLINE solutions?  If the
  latter, then this should be explained in the inline help.


## Correct the target source and all other 3mm LSB data: 
##  note that only the 60 central channels will be calibrated
##  since the BPOLY solution is only defined for these
restore
correct('ggtau_07feb97.ms', msselect='DATA_DESC_ID==2',
        gaincurve=False, opacity=False, gaintable='ggtau.3mm.ph.gcal',
	bptable='ggtau.3mm.bpoly', pointtable='ggtau.3mm.amp.gcal')

 # The pointing calibration solution table is specified again and now
   the gaintable is the phase-only solutions.  According to the script
   (and this is how aips++ did things), the phase solutions were
   pre-applied to the amp solutions and "carried forward to the output
   solution table".  Thus, you should only have to apply
   gaintable='ggtau.3mm.amp.gcal' and forget about the pointtable
   specification.  Again, is this an error in the script? 

   When I run this it says that both tables are applied to the
   source.  Did I just apply the phase solutions twice?  I have no
   clue.  Proceed blindly...

# script splits out the model data column for the calibrators so it
  can't image them.  Here split out the corrected data column.  
# Split calibrator data - CRL618
split('ggtau_07feb97.ms', 'ggtau.cal618.split.ms',
      fieldid=3, spwid=2, nchan=64, start=0, step=1, datacolumn='corrected')

# Split calibrator data - 0415
split('ggtau_07feb97.ms', 'ggtau.cal0415.split.ms',
      fieldid=0, spwid=2, nchan=64, start=0, step=1, datacolumn='corrected')

# Split calibrator data - 0528
split('ggtau_07feb97.ms', 'ggtau.cal0528.split.ms',
      fieldid=1, spwid=2, nchan=64, start=0, step=1, datacolumn='corrected')

# Split calibrated target data
split('ggtau_07feb97.ms', 'ggtau.3mm.split.ms', 
      fieldid=2, spwid=2, nchan=60, start=2, step=1, datacolumn='corrected')

# I forgot the restore but it looks like the field ID and output table
  names were properly selected.  

# Image target source in 3mm continuum emission
restore
clean('ggtau.3mm.split.ms', imagename='ggtau.3mm',
      alg='clark', niter=100, gain=0.1, nchan=1, start=2, width=58,
      spwid=0, fieldid=0, stokes='I', 
      weighting='briggs', rmode='norm', robust=0.5, 
      cell=[0.2,0.2], imsize=[256,256])
 # beam: 1.86733 by 0.979356 (arcsec) at pa 15.9891 (deg)
viewer
 # looks bad but it should, a ring with no deconvolution region and
   very little uv data. 

restore
clean('ggtau.cal618.split.ms', imagename='cal618.3mm',
      alg='clark', niter=100, gain=0.1, nchan=1, start=2, width=58,
      spwid=0, fieldid=0, stokes='I', 
      weighting='briggs', rmode='norm', robust=0.5, 
      cell=[0.2,0.2], imsize=[256,256])
 #  SEVERE :  Exception Reported: 
    Peak of psf is outside the inner quarter of defined image
    *** Error ***  
    Peak of psf is outside the inner quarter of defined image

  Residual image shows a major stripe of dots running from the lower
  left to upper right corner.  This is major wrong.  No actual image
  was generated.  

-----------------------

Try recalibrating the data with out the pointtable specified:

restore
setjy('ggtau_07feb97.ms',fieldid=3,spwid=2,fluxdensity=[1.55,0.,0.,0.])
restore
setjy('ggtau_07feb97.ms', fieldid=0,spwid=2,fluxdensity=[5.849,0.,0.,0.])
restore
setjy('ggtau_07feb97.ms', fieldid=1,spwid=2,fluxdensity=[2.634,0.,0.,0.])
restore
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.amp.gcal2', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	gaintype='GSPLINE', calmode='a', splinetime=20000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=2500., 
	gaintable='ggtau.3mm.ph.gcal')
 # logger says:
   The following calibration terms are arranged for apply:
.   BPOLY: table=ggtau.3mm.bpoly select=  calWt=false
.   GSPLINE: table=ggtau.3mm.ph.gcal select=  calWt=false
.   GSPLINE: table=ggtau.3mm.amp.gcal select=  calWt=false

  # this doesn't look good, how does it even know about the
    ggtau.3mm.amp.gcal table?  I did a restore first.  But the
    pointtable specification is still in there.  This is wrong. 
restore
inp gaincal
 # nope, the pointtable was not removed.  DACH. 
default('gaincal')
 # OK. Now the pointtable is reset to nothing.  So it looks like the
    restore function doesn't actually set *everything* back to
    default.  

#### DO	NOT USE THE RESTORE FUNCTION AGAIN UNTIL THIS BUG IS FIXED.  I
     DON'T KNOW WHAT ELSE IT DOESN'T RESET.  MAYBE THIS IS THE CAUSE
     OF SOME PREVIOUS PROBLEMS???  

# Re-derive the gaincal table:
dell -r ggtau.3mm.amp.gcal2

default('gaincal')
gaincal('ggtau_07feb97.ms', 'ggtau.3mm.amp.gcal2', 'channel',
        nchan=60, start=2, step=1,
	msselect='FIELD_ID IN [0,1,3] && DATA_DESC_ID==2',
	gaintype='GSPLINE', calmode='a', splinetime=20000.,
	refant='1', phasewrap=260, gaincurve=False, opacity=False,
	bptable='ggtau.3mm.bpoly', preavg=2500., 
	gaintable='ggtau.3mm.ph.gcal')
 # OK, this looked like it did the right thing.  

restore
inp correct
default('correct')
inp correct
correct('ggtau_07feb97.ms', msselect='DATA_DESC_ID==2',
        gaincurve=False, opacity=False, gaintable='ggtau.3mm.amp.gcal2',
	bptable='ggtau.3mm.bpoly')

# Split calibrator data - CRL618
default('split')
split('ggtau_07feb97.ms', 'ggtau.cal618-2.split.ms',
      fieldid=3, spwid=2, nchan=64, start=0, step=1, datacolumn='corrected')
default('clean')
clean('ggtau.cal618-2.split.ms', imagename='cal618-2.3mm',
      alg='clark', niter=100, gain=0.1, nchan=1, start=2, width=58,
      spwid=0, fieldid=0, stokes='I', 
      weighting='briggs', rmode='norm', robust=0.5, 
      cell=[0.2,0.2], imsize=[256,256])
 #  SEVERE : Exception Reported: 
    Peak of psf is outside the inner quarter of defined image

# try just imaging one channel: 
default('clean')
clean('ggtau.cal618-2.split.ms', imagename='cal618-2.2.3mm',
      alg='clark', niter=100, gain=0.1, nchan=1, start=10, width=1,
      spwid=0, fieldid=0, stokes='I', 
      weighting='briggs', rmode='norm', robust=0.5, 
      cell=[0.2,0.2], imsize=[256,256])
 # same error.

viewer
 # residual image is slightly different in where the stripe is
   centered, so there was, in fact, a phase shift applied.  But I don't
   know why I'm still getting this error.  

# Split calibrated target data
split('ggtau_07feb97.ms', 'ggtau.3mm-2.split.ms', 
      fieldid=2, spwid=2, nchan=60, start=2, step=1, datacolumn='corrected')

restore
clean('ggtau.3mm-2.split.ms', imagename='ggtau.3mm-2',
      alg='clark', niter=100, gain=0.1, nchan=1, start=2, width=58,
      spwid=0, fieldid=0, stokes='I', 
      weighting='briggs', rmode='norm', robust=0.5, 
      cell=[0.2,0.2], imsize=[256,256])
 # beam: 1.86733 by 0.979356 (arcsec) at pa 15.9891 (deg)
viewer

 # there is a very definite difference in the striping between the
   images.  Actually, the one that used the pointtable looks better.
   So maybe the script is correct but the documentation in the in-line
   help and the script is wrong.  Besides, I think that application of
   a pointing table should not be used to apply gain solutions.

I brought in both source images, blinked between them (worked nicely)
then tried to deregister the 1st one I brought in and the viewer
crashed.  This error is repeatable. 


I have no idea how to proceed.  Why is the calibrator not imaging
properly while the source looks like it did?  I don't understand the
pointtable bit and why the source image looks better when it is used
to apply gain solutions.  



#######################################################################