18/05/2023 Meeting notes #29
Comments
|
When I try to copy the Model of the Sun after rephasing it returns this error I don't understand why because I think rephasing the MS is not supposed to change the columns row number (please correct me if I'm wrong) After rephasing the array of the concat MS is not the same as the original MS, and because when I add the columns in the original MS it uses its data description (DATA) with a different number of column rows it fails ( but this is not expected because I am rephasing back to the original phase centre). The curious thing is that before when I was only rephrasing the CORRECTED_DATA and keeping the other columns it was running without any problem... |
|
Well clearly the number of rows is different: You are right -- knowing how the software works, rephasing can't change the number of rows. However, when you split and re-concatenate, there's plenty more opportunities for something to go wrong there. Remind me, why do you need to make a concatenated MS, anyway? Maybe I just forget the reason... seems like a lot of extra disk space to me, so it'd better be a good reason. You could copy the Sun model over from the per-scan, rephased data sets directly, without concatenating:
|
To be able to compare images before and after the Sun subtraction, in this way, we have the contaminated data that allows me to restart if something goes wrong and the final corrected data without the Sun.
From what I understand (please correct me if not correct), this will be done after the prediction step following the order:
|
|
For the option of using the scan numbers as input for other steps to avoid the glob command... I have defined the scan_numbers step in the recipe this way scan_numbers:
info: 'Extract a list of unique scan numbers from a MS file. The scans output parameter is a list of strings representing the unique scan numbers.'
cab:
command: |
from casacore.tables import table
import numpy
scans=[]
maintab = table(ms,ack=False)
scan_no = list(numpy.unique(maintab.getcol('SCAN_NUMBER')))
for scan in scan_no:
scans.append(str(scan))
maintab.close()
print(scans)
flavour: python-code
inputs:
ms:
dtype: MS
outputs:
scans:
dtype: List[str]
params:
ms: '{recipe.ms}'and I use it as input for the split_ms_by_scan step. For it to work the two steps have to run in sequence, i.e. if I run only the split step separately the scan_numbers.scans are not recognized. In this case, is okay because they are steps that follow each other, but when I try to use the scan numbers from another step it is not recognized. This is one of the cases where it happens make_mask:
info: 'Creating a fits mask with breizorro'
params:
image_list: =steps.sort_images.sorted_images #=GLOB("{recipe.dir_out}/{recipe.perscan_dir_out}/{recipe.sun_images_dir}/*-MFS-image*.fits")
region_dir: "{recipe.dir_out}/{recipe.regions_dir_out}"
recipe:
inputs:
region_dir:
dtype: Directory
image_list:
dtype: List[File]
for_loop:
var: image
over: image_list
steps:
make_mask:
cab: breizorro
params:
restored_image: =recipe.image
threshold: 9999999999999999999999999999999
merge: ="{recipe.region_dir}" + "/" + "scan_{root.steps.split_ms_by_scan.scan}_sun_region.reg"
mask: ="{root.dir_out}" + "/" + "{root.masks_dir_out}" + "/" + STRIPEXT(BASENAME(recipe.image)) + "_mask.fits" |
The discussion of the meeting primarily focused on the issue of the Sun being subtracted while not rephased to the centre of the field, leading to unexpected results.
It was identified that the problem occurred because the MODEL_DATA_SUN was not rephased back to the original Measurement Set (MS) after subtraction.
To address this issue, the solution is to ensure that the MODEL_DATA_SUN is properly rephased to match the original MS.
Additionally, there was a recommendation to name the scans with their actual scan numbers (e.g., 3, 5, 7) instead of index numbers (0, 1, 2) to avoid confusion and improve clarity in the data and avoid the GLOB function problem.
Hopefully, the peeling step with the quartical will yield better results by implementing these suggestions.
The text was updated successfully, but these errors were encountered: