search

caracal-pipeline / caracal

Containerized Automated Radio Astronomy Calibration (CARACal) pipeline
GNU General Public License v2.0
28 stars 6 forks source link

Cubical transfer of gain solutions introduces 0's in corrected visibilities. #627

Closed paoloserra closed 10 months ago

paoloserra commented 4 years ago

Following the calibration run:

Running: gocubical --sol-jones G --g-clip-high 2.0 --weight-column WEIGHT --out-overwrite 1 --dist-ncpu 8 --data-time-chunk 128 --madmax-threshold 0,10 --g-time-int 120 --data-ms /home/pserra/msdir/jw00_mk64_4k-target_crosscalavg.ms --out-casa-gaintables 1 --model-list MODEL_DATA --data-column DATA --g-solvable 1 --g-clip-low 0.5 --model-ddes auto --dist-max-chunks 0 --madmax-enable 0 --dist-nworker 0 --bbc-save-to /home/pserra/output/continuum/selfcal_products/bbc-gains-2-jw00_mk64_4k-target_crosscalavg.parmdb --madmax-estimate corr --g-save-to /home/pserra/output/continuum/selfcal_products/g-gains-2-jw00_mk64_4k-target_crosscalavg.parmdb --out-plots 1 --madmax-plot 0 --out-name /home/pserra/output/continuum/selfcal_products/kh_jw00_mk64_4k-target_crosscalavg_2_cubical --montblanc-dtype float --g-type phase-diag --sol-term-iters 5,0 --g-freq-int 0 --out-mode sc

I transfer and apply the gains to the fine channel dataset with:

Running: gocubical --sol-jones G --montblanc-dtype float --dist-nworker 0 --bbc-save-to file --weight-column WEIGHT --out-mode ac --sol-term-iters 5,0 --out-plots 1 --out-overwrite 1 --data-ms /home/pserra/msdir/jw00_mk64_4k-target_crosscal.ms --g-xfer-from /home/pserra/output/continuum/selfcal_products/g-gains-2-jw00_mk64_4k-target_crosscalavg.parmdb --data-column DATA --data-time-chunk 128 --out-name /home/pserra/output/continuum/selfcal_products/jw00_mk64_4k-jw00_mk64_4k-target_crosscal.ms_2_cubical --dist-ncpu 8 --out-casa-gaintables 0 --model-ddes auto --dist-max-chunks 0

All this is using the standard MeerKATHI settings.

The resulting CORRECTED_DATA is padded with zeros both in time and frequency while DATA was not (see attached images). I don't know why. Any idea? Thanks!

data corrected

PeterKamphuis commented 4 years ago

Yeah I'm a bit reluctant to apply the Cubical flags from an averaged set as well. Maybe we can standardly do the transfer with xfer-from but start checking the Cubical flags and raise high level warnings in the reporting if they become a large fraction, possibly related to the solution intervals, compared to the initial flags?

PeterKamphuis commented 4 years ago

@o-smirnov I noticed as well that with xfer-from when the first or last solution is flagged it looks like it applies a 0 solution. At least it often sets the visibilities to 0 at the beginning and end of an observing run. As far as I can figure out this happens when in the original calibration the chunk is fully flagged so no solution is found. Is there a way in cubical to have it apply the nearest solution in these cases? And do we want to? Because the last time chunk might still not be 'complete', i.e. it could be smaller than a chunk in time or even a solution interval. For this situation it might actuallly be beneficial to have the visibilities removed. Although I'd rather see them flagged than set to 0 in amplitude.

o-smirnov commented 4 years ago

@PeterKamphuis that is definitely unintended behaviour and should be raised as a separate issue. xfer-from is meant to extrapolate in these cases (and does, in the tests I've made).

We could also consider an option to flag rather than extrapolate.

Either way, setting (unflagged) visibilities to zero is clearly a very naughty thing to do.

PeterKamphuis commented 4 years ago

@o-smirnov Ok I'll spend some more time trying to pin this down exactly and test it in a standalone cubical. But yeah I definitely get 0's in my corrected column.

PeterKamphuis commented 4 years ago

See https://github.com/ratt-ru/CubiCal/issues/336

PeterKamphuis commented 4 years ago

This is fixed in a Cubical branch now but I have no idea wether the fix has migrated all the way into stimela?

o-smirnov commented 4 years ago

Good point! I have forgotten about this. The Cubical branch has to be merged and a release needs to be made, then it can go into Stimela... @SpheMakh looks like we'll need another release.

KshitijT commented 4 years ago

Good point! I have forgotten about this. The Cubical branch has to be merged and a release needs to be made, then it can go into Stimela... @SpheMakh looks like we'll need another release.

Can the stimela release be called "Caracal" ? :)

gigjozsa commented 4 years ago

@SpheMakh @o-smirnov has this been done or does this one need to be merged: https://github.com/ratt-ru/Stimela/tree/update-cubical-150

PeterKamphuis commented 4 years ago

@o-smirnov If we roll Cubical back to 1.4.7 for the XX,YY solution does this become an issue again or is the solve before that?

PeterKamphuis commented 4 years ago

Ah, no we are not rolling back it is solved. Sorry, monday mornings. I think we can close this no?