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. - 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://wikio.nrao.edu/bin/view/Software/CASA 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. #######################################################################