- Jaime Pineda, firstname.lastname@example.org, casapy-stable-32.0.14917-001-64b, Scientific Linux 5.5, 64 bit, 3 May 2011
- Dirk Petry, email@example.com, casapy-stable-32.0.14927-001-64b, RHEL 5.5 64 bit, 29 April 2011
- Anita Richards, firstname.lastname@example.org, casapy-test-32.0.14927-001-64b, Linux SL 5, 64 bit, 4 May 2011
- Alessandra Rossetti, email@example.com, casapy-stable-32.0.14927-001-64b , SL5.3, 64 bit, 4 May 2011
Jaime Pineda, firstname.lastname@example.org, casapy-stable-32.0.14917-001-64b, Scientific Linux 5.5, 64 bit, 3 May 2011
1) I loaded a single dish cube into the viewer, but it will not display the data if the keyword BLANK is set as float (-1.00E+00, I checked with different values) when it is expecting an integer. Viewer gives a warning, "WARN Keyword value has wrong data type," but it still will not show the cube with the following message: "RecordInterface::asInt - Invalid data type." The viewer should still display the data and send a warning message.
JIRA ticket CAS-3133 (still need to get the source of the SD data from the reporter)
2) imperfect ellipse masks for cleaning: When creating a mask to clean using the ellipse option, extra pixels are selected creating an horizontal line. See attached image for an example.
This was found in a recent test version of casa, not in a candidate for release 3.2.
This feature will be available in CASA 3.3, it is not in release 3.2
Dirk Petry, email@example.com, casapy-stable-32.0.14927-001-64b, RHEL 5.5 64 bit, 29 April 2011
1) flagmanager gives cryptic error message when encountering an already existing output file: When flagmanager, e.g. as part of importasdm or importuvfits is called and the *.flagversions file already exists, it fails making it look as if the entire import had failed. It should clearly state that it only encountered an already existing flagversions file. The existence of this file should be tested for before
the actual import starts in order to save time for the user.
JIRA ticket CAS-3128
2) fixvis does not properly deal with variable reference PHASE_DIR column in FIELD table. Only FIELD tables which have the same reference for all fields can be processed.
JIRA ticket CAS-3129
3) flagged and non-existant items appear in caltable plots
This was found by Wouter Flemmings already some time ago. I reproduced it with the stable 3.2 release candidate.
The script "reduce.py" (attached to the ticket filed for this issue, see below)
applied to the data in ftp://ftp.eso.org/pub/general/dpetry/r_scl.tgz
results in two problems:
a) Even though autocorrelations were flagged, they appear when plotting
the caltable RScl_Band3.phaseref.bl
b) Even though antenna DV07 is actually no longer in the data after 5:58 UTC,
a solution for it is plotted when plotting the caltable
Both tables are generated by the script.
JIRA ticket CAS-3152
Anita Richards, firstname.lastname@example.org, casapy-test-32.0.14927-001-64b, Linux SL 5, 64 bit, 4 May 2011
1) CVEL seems OK
Tested cvel on BRI0952-0115, (ALMA data, see BRI0952-011ScriptandReport
comparing interpolation modes as below.
vis = 'BRI0952-0115.ms.contsub'
field = 'BRI0952-0115'
spw = '0:44~89'
nchan = 15
restfreq = '1900536.9MHz'
outframe = 'LSRK'
outputvis = 'BRI0952-0115_3fft.cvel'
interpolation = 'fftshift'
outputvis = 'BRI0952-0115_3lin.cvel'
interpolation = 'linear'
0 15 LSRK 349461.217 46871.9191 703078.787 349461.217 XX YY
which is almost right but why is chan width not exactly 46875.0 = 3.0 * 15625 kHz? (CVEL has always produced an anomalous chan width whatever settings/data I have used.)
this is a feature: the channel width changes due to the ref frame transform
Both linear and fftshift seem to give identical spectra (although it is laborious to be sure, since we can't yet overplot in plotms).
I attempted imaging the .cvel MS produced above
vis = 'BRI0952-0115_3fft.cvel'
field = 'BRI0952-0115'
imagename = 'BRI0952-0115_3fft.clean'
restfreq = '1900536.9MHz'
mode = 'channel'
mask=[124, 126,132, 137]
interpolation = 'nearest'
Both linear and fft give identical spectral profiles from the image cube when on the signal.
Minor observation: If you have to use interpolation = 'nearest' for mode='channel', this should be the default for this.
Already noted as necessary improvement (ticket number?)
If restfreq is not set, I get
*** Error *** index out of bounds
- this is new (and not very helpful) - one might not want to specify a rest freq if there were multiple lines present, if you were not requesting velocity output.
was fixed in stable r14958, see ALMA CSV-914
Instead of explicit mask, I tried saving a box using Box in File (for all channels) and then using mask = 'BR.rgn.box' but
2011-05-04 08:44:45 SEVERE Exception Reported: LCBox::LCBox - blc [124, 126, 0, 4] must be <= trc [132, 137, 0, 0]
*** Error *** LCBox::LCBox - blc [124, 126, 0, 4] must be <= trc [132, 137, 0, 0]
JIRA ticket CAS-3132
3) Previous clean method/data does not work, and cannot image if one polarization is flagged
Tried exactly as per ScriptandReport#Imaging
vis='BRI0952-0115.ms.contsub' #this is the parent data set used for the above CVEL test
field = '1058+015'
imagename = '1058+015_1.clean'
psfmode='hogbom' # larger area for sidelobe deconvolution
imagermode='csclean' # better dynamic range with sparse uv coverage
**** Error **** PSFZero SkyEquation:: PSF calculation resulted in a PSF with its peak being 0 or less! :
Please check that the required data exists and is not flagged.
although it works OK in an old version of CASA.
I get the same error message if I take one if the successfully imaged CVEL output data sets, flag XX and then try to run clean as under 2)
already a JIRA issue (ticket number?)
On the uvconsub data, trying to see which of the inputs from the original BRI0952-011 imaging now cause problems, if I omit outframe = 'LSRK', and use nchan = -1, it is OK. If I use nchan = 45 then only one channel is imaged.
I tried repeating Subtracting_the_continuum
, first using the same settings i.e. fitorder=0
If it is possible to use different fitorders, it would be useful to be able to specify the outname since it is more likely people will want to try different inputs on the same MS.
JIRA ticket (improvement) CAS-3130
fitorder=1 gave error
2011-05-04 11:17:20 SEVERE Calibrater::solve Caught exception: The output to input row map is unreliable
2011-05-04 11:17:20 SEVERE Exception Reported: Error in Calibrater::solve.
- is this because it is not yet implemented? There used to be a warning only to use fitorder=0 but that no longer appears.
JIRA ticket CAS-3135
The MS with fitorder=0 seems OK, images like the old one.
Alessandra Rossetti, email@example.com, casapy-stable-32.0.14927-001-64b , SL5.3, 64 bit, 4 May 2011
1) Interactive tasks.
We have found no problems using plotms, imview, and msview.
Minor comment: In the viewer's tool "shape manager", to create a new
region it would be useful to have also "pixel" as position units.
2) Check scanintents.
Scan intents seem not to work properly.
On dataset SgrA
*, using listobs, target appears as "observed_target" in
some scans, while in others it appears as "calibrate_phase".
On dataset NGC3256, scan 1, relative to the primary calibrator,
has intent "pointing", while the first scan of phase calibrator
results as "bandpass calibrator".
In this case, running flagdata with intent "*pointing*" causes the
flagging of the whole primary calibrator.
there is already a JIRA ticket (CAS-2751) about listobs which Sandra Castro is working on, filed CAS-3234 concerning flagdata
3)AIPS/CASA imfit comparison.
Using default options in IMFIT, both in AIPS and CASA,
the results obtained on the same image using the same box
are slightly different, and reported in the attached file.
IMFIT in CASA gets a very large error in the estimate
of the position angle for the image component (deconvolved from beam).
JIRA ticket CAS-3131