This site requires javascript to be enabled to fuction correctly


Why are the fluxes in my CASA 5.1 simulated mosaic image incorrect, and how can I fix it?
Posted by Brian Mason, Last modified by Sarah Wood on 11 April 2018 05:33 PM
We have recently identified a bug in the CASA 5.1 releases which seriously affects mosaic imaging of simulated data.   The simulated visibilities themselves are not adversely affected, nor is imaging a single field of a simulated mosaic in non-mosaic mode (gridder='standard' in TCLEAN) adversely affected. Specifically, images of simulated data made with gridder='mosaic' in TCLEAN will be affected. The manifestation of the issue is that the apparent brightness of sources in the image can be wrong in a position-dependent way across a mosaic by factors of a few or more. Mosaic imaging of real VLA or ALMA data is not affected by this issue. 

This issue will be fixed in the upcoming CASA 5.3 release. In the meantime, two workarounds are as follows:
  1. Imaging can be done in a previous version of CASA (e.g. 4.7.2). This is the most straightforward solution, but it comes with the disadvantage that recent CASA improvements --- for instance, in automasking functionality--- will not be available.
  2. The CASA 5.1.* releases can be used if a specific environment variable is set prior to starting CASA. This environment variable, called VI1, controls internal logic within CASA that enables or disables recently added functionality; this new functionality is the source of the problem. 

In order to use a 5.1 CASA version (the second workaround) the user should type
export VI1=1
prior to starting CASA (if using BASH). If the shell is a CSH variant, the user should instead type
setenv VI1 1
The value of VI1 does not matter, it only matters that the variable is defined at the time CASA starts up.  To undefine VI1 the user can type
unset VI1
in either BASH or CSH. If you're not sure what shell you're using you can find out by typing "echo $0".

Detailed Information: the mosaic imaging bug is only triggered in the CASA 5.1.* releases, when the recently added internal VI2 framework is used, and when the cadence of updates in the pointing table identically matches the integration time of the data. For real ALMA data the cadence of pointing information (48 ms) is considerably higher than the shortest available integration times (~1 second), so the bug is not triggered.  Similarly the pointing information for the VLA antennas is updated much more quickly than the shortest integration times for visibilities. Measurement Sets created by simobserve(), however, do trigger it because the simulated pointing table and visibility integration times are exactly synchronized.
(1 vote(s))
Helpful
Not helpful

Comments (0)