marti-vidal-i / polconvert Goto Github PK

ev0303 is a EU-VGOS experiment where Onsala provided multi-file data. Although PC has successfully obtained cross-polarization gain solution for multi-file data in previous versions of the code, after the latest update that introduces differential parallactic angle phase correction between RR and LL it fails to estimate when multi-file data is present.

Hi Ivan,
It is probably better to remove the *.so files from the repository. Git doesn't really handle binary files very efficiently so if you keep committing new versions of those, the repository will grow in size unnecessarily.
You can remove them by doing:

$ git rm *.so
$ git commit
$ git push

You can tell git to ignore these files in future commits by creating a .gitignore file in the repository that contains:
*.so

I can create a pull request for you if that helps.

Thanks,
Mark

Hi Ivan,

Suma Murthy is hitting an out-of-bounds array access in DoGFF() when trying to PolConvert some EVN data. This happens at:

There is some guesswork involved, but I think time[n][1] is Nchan[i]-1 here because we hit:

This results in an array index of the order of Nchan[i]*Nchan[i] which is clearly larger than intended. So I think there is something wrong in the logic around L1522. The reason Suma hits this here may very well be because this data set has 16K channels. It may very well be that you don't hit this with data sets with less channels. But it would still do the wrong thing.

Amplitude scaling corrections based on auto-correlation bandpass normalisation may be important for getting correct amplitudes. This should naturally be done in the H,V polarisation basis, i.e. before converting to circular. Hence, it would be good to to this in polconvert. Similar tool is ACCOR in AIPS (http://www.aips.nrao.edu/cgi-bin/ZXHLP2.PL?ACCOR).

When (likely) some selection contains an empty subset of data (e.g. a given baseline/subband with), PolConvert just freezes without further action.

For example, in the following example PolConvert freeze as the following due to the lack of data from a single baseline in a particular IF that unable it to obtain estimates.

Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #9, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #10, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #11, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #12, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #13, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #14, channels 62 to 62   Clearing previous allocation objects
 Apply rates and estimate cross-gains for IF #15, channels 0 to 0   

The only way to stop the run is by externally killing the entire CASA process.

Could some internal checks be implemented for the cases when a subset of the baselines do not contain data from all IFs, or a single station is completely out, and seamlessly ignore them in the process?