Callibs inconsistency

[rstofi]

I am trying to run selfcal on multiple target fields, and performing the cross-calibration separately. I am unsure if I have a version issue (I use schema version 1.1 in all my runs) or if this is a preparation issue.

I ran a full caracal pipeline successfully on an MS that includes a calibration field and multiple target fields. Each target field was imaged separately. Under the "output" directory, I have a caltables/ directory, in which I have the calibration tables (K, B, G) from the primary calibration and I have a callibs/ sub-directory. In the callibs/ sub-directory, I have a callib_*.json and callib_*.txt file specifying which caltables to apply to the target fields. This works just well.

However, when I want to do selfcal+imaging on an MS that only contains target fields, I need to set up the caltables/ directory manually. As input, I use the results of a run, in which I only solved for the calibrators. In that output, I don't have a callibs/ directory under the caltables/ directory. Instead, I have a callibs-*.yml file. Given this setup, I've tried the following setups:

1. I prepared the calltables/ directory by making a callibs/ sub-directory and inside crafted a callibs-*.json file pointing to the right calibration tables. When running the selfcal-only caracal job with such a setup, I got the following error (I don't have the callibs-*.yml or callibs-*.txt):

/idia/projects/hi_im/OTF/results/1630519596_results/paper_imaging/by_hand_selfcal_and_imaging/output/caltables/callib-imaging_and_selfcal-paper_target_scans_only_otf_format_1630519596-1gc1.yml
doesn't exist [OSError]

3. I prepared the caltables/ directory without the callibs/ sub-directory, and re-named the callibs*.yml appropriately so the salfcal-only caracal run finds and uses it. This worked as a charm on a single target field.

4. I repeated approach 2. but in the selfcal caracal run, I provided more than one target field. This is where things started to get weird. After processing some fields, caracal died. See the log file attached.

runjob_5962415_stderr.log

I am not sure if this is expected, or if this is a data preparation thing. I know this is not the intended way to use caracal, but I would appreciate it if you could help me with this. Thanks!

[KshitijT]

@rstofi, looks like a whole lot of data is flagged? Crystalball is crashing because number of sources is 0 (thanks @sjperkins ) and there are no sources because the last imaging round is not deconvolving anything; the same data is able to make the initial images though? Could you confirm the flagging for the dataset and the initial images ?

[rstofi]

I checked the flagging of each target field and they have enough SNR to be imaged. I also imaged the field where the code failed separately with approach 3., and everything worked well, I got a nice image. The selfcal worker parameters were the same. I also got all target field images from the run of approach 1...

[paoloserra]

Hi @rstofi

Today, while cleaning up old issues, we got to this one. Apologies for not following up on it.

Indeed, this was quite a non-standard usage of CARACal, but I'm wondering whether you ever managed to make it work.

Also note that we found a problem with the way the cal libs were set up in case of multiple targets. See https://github.com/caracal-pipeline/caracal/issues/1454 . This got fixed, and I wonder whether the updated cal lib format would be a better template for your case.

Just to clarify -- the reason you were doing all this is that you had a multi-target MS with no calibrators, and wanted to apply the cross-cal solution obtained from a different MS?

[rstofi]

Hi,

I never solved it, but I set up symlinks to the original caltables/ directory, which is a good enough workaround. I haven't had the time to check it with an updated version of caracal. But since, I have a working solution, we can close the ticket (maybe re-open it if we run into the same issue, but with the latest version of caracal).