Execution Block ID uid://A001/X15a0/X192 Sgr_A_st_ao_03_7M [brick]

[ashleythomasbarnes]

Sgr_A_st_ao_03_7M uid://A001/X15a0/X192

• [x] Observations completed?
• [x] Delivered?
• [x] Downloaded? (specify where)
  • [x] hipergator
  • [x] hipergator pipeline run
  • Pipeline Run 20220223T160940
  • Pipeline Run 20220224T050301
  • Pipeline Run 20220223T130554
  • Pipeline Run 20220223T132843
• [x] Weblog unpacked
• [x] Weblog Quality Assessment?
  • Lines within SPW?
    • [x] HCO+ - Notes:
    • [x] HNCO - Notes:
• [x] Imaging: Continuum
• [x] Imaging: Lines
  • [x] HCO+
  • [x] HNCO
  • [x] H13CN
  • [x] H13CO+/SiO
  • [x] Cont 1
  • [x] Cont 2
  • [x] uid___A002_Xf1ecde_X738b.ms needs re-calibration

Product Links:

• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw26.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw20.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw24.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw22.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw18.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16.cube.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw20.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw26.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw22.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw24.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw18.mfs.I.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.pb.tt0.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.tt0.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.tt1.pbcor.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.alpha.error.fits
• member.uid___A001_X15a0_X192.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.alpha.fits

Reprocessed Product Links:

• uid___A001_X15a0_X192.s36_0.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.iter1.image.tt0.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw20.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw26.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw18.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw24.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw22.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw16.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw24.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw22.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw20.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw16.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw18.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw18.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw26.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw20.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw16.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw22.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw22.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw16.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw20.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw26.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw18.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw18.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw16.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw20.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw22.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw24.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw16.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw22.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw24.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw18.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw26.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw20.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s11_0.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.iter1.image.tt0.pbcor.fits
• uid___A001_X15a0_X192.s36_0.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.iter1.image.tt0.pbcor.fits
• uid___A001_X15a0_X192.s36_0.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.iter1.image.tt0.pbcor.fits
• uid___A001_X15a0_X192.s11_0.Sgr_A_star_sci.spw16_18_20_22_24_26.cont.I.iter1.image.tt0.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw20.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw26.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw18.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw24.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw22.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s9_0.Sgr_A_star_sci.spw16.mfs.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw24.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw22.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw20.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw16.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s13_0.Sgr_A_star_sci.spw18.cube.I.iter1.image.pbcor.fits
• uid___A001_X15a0_X192.s38_0.Sgr_A_star_sci.spw26.cube.I.iter1.image.pbcor.fits

[ashleythomasbarnes]

HCO+

HNCO

[keflavich]

Probable SiO v=1 J=2-1 maser:

[xinglunju]

QA summary & issues

• SPW 20 & 22: bad phase calibration solutions? The peak flux of the phase calibrator J1744 at these two spws is lower than that in other spws at the same frequency range (~330 mJy/bm vs. ~380 mJy/bm), suggesting phase de-correlation. The achieved image rms for the phase calibrator is 2-3 times higher than the theoretical value. Inspection of the phase solutions shows that the problem is likely with uid_A002_Xf1ecdeX738b.ms. The warning in task 16 is related: the calibrated visibility flux densities of J1744 in spw 20&22 in uidA002_Xf1ecde_X738b.ms are factor 1.5 lower than the catalog value (see below).

  

• So, uid___A002_Xf1ecde_X738b.ms may need a re-calibration, with special attention to spw 20 & 22, maybe using a different spw phase-up map.

Continuum

• Looks good. The findcont results can be improved.

• The continuum image of spw 20 has a peak that is not seen in any other spws, and the peak value is twice of those in other spws. See the two plots below.

• Could be a bad choice of line-free channel in findcont that includes some line emission (see below)?

Cubes

• Looks ok.
• tclean stopped to prevent divergence for spw 24, although the image and the line-free moment maps seem ok.
• The spectral line in spw 20 is a bit close to the edge, but may be ok. See plots in Ash's comment above.

[keflavich]

Thanks @xinglunju . For the "needs recalibration" step, we need to add that to the to-do list. I'll do that, but please have a look and see if you agree with it:

• [ ] uid___A002_Xf1ecde_X738b.ms needs re-calibration

[xinglunju]

@keflavich Yes I agree. At least we need to double check the calibration and flagging of spws 20 & 22 in this EB, in the end we may simply flag these two spws instead of re-running calibration.

[keflavich]

Options:

1. Flag out those two windows in that EB
2. Attempt re-calibration
3. Request re-calibration by ALMA (QA3)

[thusharags]

Here is a link to the Liszt paper on the potential absorption issue: https://ui.adsabs.harvard.edu/abs/2018A&A...610A..49L/abstract

[xinglunju]

@thusharags thanks, Thushara! But the first two EBs were observed on the same day and used the same calibrators, while the second EB is all good...

[keflavich]

This calibrator does look pretty weird. This is spw20 for the bad one (from tsys):

These are good ones:

All of these spectra look weird (they have lines in the window), but it's interesting that the last one got the right flux scale, while the first did not.

[keflavich]

Also interesting that tsysflag seems to have handled these lines right, though, which makes it less obvious why that one EB was messed up.

[thusharags]

Does anyone know what the threshold is for flagging line channels in the tsys cal table? Wonder whether the rogue dataste just missed that threshold by a bit? Unlikely though given how strong these lines are in the narrow window.

[keflavich]

@thusharags look at https://data.rc.ufl.edu/secure/adamginsburg/ACES/weblogs/humanreadable/Sgr_A_st_ao_03_7M/html/t2-4m.html?sidebar=sidebar_stage7&ms=all&subpage=t2-4m_details.html. The rogue data set did properly flag out the lines.

[xinglunju]

I checked calibrated data, and spw 20 of J1744 does show HCO+ absorption features in all the four EBs. See plots below.

The phase calibration of spw 20 and 22 of the first EB (X738b) doesn't seem good, with large phase scatters in the last four scans.

For a comparison, the next two plots show the calibrated phase for the second EB (X784b), which seems good.

The calibrated amplitude of J1744 of X738b is messed up. The last four scans have clearly wrong amplitudes. This is likely the root of the abnormal flux of J1744 in this EB.

[ksi85]

Hi all,

I contacted ESO about the flux issue of the phase calibrator in the first measurement set and they suggested that the problem could lie with the used reference antenna. So they suggest to re-run the calibration with reference antenna CM03 instead of CM10 and then check if the calibration improved. If this is not the case, the DRM and me will investigate further.

[keflavich]

Suggested solutions:

• [ ] flag out bad scans
• [ ] flag out bad spws in bad EB
• [ ] flag out bad EB

Origin of problem (discussed on telecon):

• probably change in atmospheric line particularly affecting these two SPWs

[xinglunju]

Update: I added a flag in the 'flagtemplate.txt' file to flag the problematic scans in the first EB (spw id 20 & 22, scan id 8~19), and reran the whole pipeline. The result looks promising. Task 16 hifa_gfluxscale now shows consistent fluxes for J1744. The imaging rms for the target does not significantly change: spw 20 before vs. after flagging -- 74/60/87 vs. 80/67/92 mJy/beam (RMS/RMSmin/RMSmax). Will add more info soon...

[keflavich]

@ksi85 will you contact the helpdesk and ask if they can update the flagcommands?

[ksi85]

Yes, I will contact the DRM tomorrow to ask if the flagcommands can be updated accordingly and then report back on what she says.

[xinglunju]

@ksi85 thank you! Here is what I did: In package_path/calibration/uid___A002_Xf1ecdeX738b.flagtemplate.txt (or in SBid*_auxproducts.tgz, which is a tarball that contains this txt file), add a new flag: mode='manual' spw='20,22' scan='8~19' reason='QA3:timegaincal_amplitude_time'

[ksi85]

Hi all, this is the answer I got from the DRM about the procedure on if/how to get the data in the archive corrected:

The only way to request the correction of the results in the archive is through a QA3 procedure via HD. You need to describe the problem and request that the archived data should be corrected. I will then open a PRTSPR ticket with your request and documentation. The assignee will decide if this is needed or not. If it will be accepted, then we will go through QA3. If you really want these data corrected in the archive, send the request today, because due to the Feb shutdown there is some chance that the QA3 procedure will be accepted. In normal operation, this will not be corrected because the reference spw is not affected.

I am very busy today so I don't think I will get to writing the HD message. Can someone else take care of this if you think that it would be useful to have the corrected data in the archive? Thanks!

[xinglunju]

I can submit the ticket. Shall I send it to EU ARC (who are supposed to support this project)?

[ksi85]

Thank you! Yes, this would be the right ARC :-)

[xinglunju]

Oops... my ALMA science portal/helpdesk account was affiliated with the EA ARC so I could only submit tickets to EA. I just changed the preferred ARC to EU, but still I only see EA options in the helpdesk. As far as I remember, the change of preferred ARCs itself is a ticket that needs to be approved by ARC staff. So probably I cannot do it today...

If someone else can do it today, that would be great. I will post a draft message here asap with all the details. Otherwise I will try it tomorrow once the change of the preferred ARC is approved.

[xinglunju]

It seems that my account has been switched to EU, so I've submitted a ticket:

Dear ARC staff,

I am working on the delivered data of the cycle 8 large program 2021.1.00172.L as a co-I, and I noticed that there might be issues in one of the five EBs in the SB Sgr_A_st_ao_03_7M. I wonder if it is possible to make adjustments to the data in the archive and re-ingest the products to the science archive, so that other users can assess the (hopefully) correct data.

The problem can be illustrated in the attached plot. The calibrated flux in spectral windows 20 and 22 of the phase calibrator J1744 in the EB uid://A002/Xf1ecde/X738b has anomalies: the flux drops to about half of the catalog value after the third scan. This has caused low scores for Tasks 16 and 21 in the weblog. We have attempted to investigate the root of this anomaly (e.g., switching the reference antenna) but got little clue so far. Meanwhile we tried to flag these scans in this particular EB, and found the result to be promising. The images from the pipeline after flagging the bad scans have acceptable RMS, and the scores for Tasks 16 and 21 in the weblog become 1.

The fix we did is simply add a flagging command in the flagtemplate file in the 'calibration' directory in the delivered package. In our case it is uid___A002_Xf1ecde_X738b.flagtemplate.txt, and we added one line in it:

mode='manual' spw='20,22' scan='8~19' reason='QA3:timegaincal_amplitude_time'

and then packed it into the tarball member.uid___A001_X15a0_X192.hifa_calimage_renorm.auxproducts.tgz.

Please let me know if what we did looks ok to you. If this is indeed a viable fix, could you replace the data in the archive with this updated flagtemplate and with the bad scans flagged?

[xinglunju]

More updates on the re-calibration

Flagging bad scans and rerunning calibration

• I added a flagging command in uid___A002_Xf1ecde_X738b.flagtemplate.txt under the 'calibration' subdirectory of the delivered package:

  mode='manual' spw='20,22' scan='8~19' reason='QA3:timegaincal_amplitude_time'

• This flagged all the scans toward the phase calibrator J1744 and the target fields after the first two 'good' scans.
• The way the pipeline handles the flagtemplate file is a bit tricky: by default, scriptForPI.py always unpacks the *auxproducts.tgz tarball in this subdirectory and reads the flagtemplates therein. So I packed the updated uid___A002_Xf1ecde_X738b.flagtemplate.txt into that tarball (the other way is to comment out all the lines in scriptForPI.py that unpack the tarball, and ask it to directly read the available flagtemplates in the subdirectory).
• Then I reran the pipeline (not just restore the calibrated products). To do this, one needs to move the 'piperestorescript.py' in the 'script' subdirectory somewhere else, and then start scriptForPI.py. Also there is likely a bug in the source code of the task hif_refant, which I have reported in a HD ticket to ARC. I copied the message here:

  I am trying to re-run (not simply restore) the pipeline calibration of a delivered package, and I think there is a bug in the code:
  In the source code of the task hif_refant, which locates at ~/CASAPATH/pipeline/pipeline/hif/cli/hif_refant.py,
  at line #90, the keyword 'refant' should be able to accept a list, because sometimes we supply a list of EBs to this task, and each EB can have different reference antennas, then the keyword 'refant' would be a list of different antenna names (e.g., refant=['CM01', 'CM02', 'CM03']). However, the code only allows for a single string. 
  To solve this problem, I changed this part of the source code from:
  >'refant': {'type': 'cStr', 'coerce': _coerce.to_str},
  to:
  >'refant': {'type': 'cStrVec', 'coerce': [_coerce.to_list,_coerce.to_strvec]},
  I don't know if this has been solved in newer versions of CASA. It may be helpful to remind users about this bug, if confirmed, because some users might also want to re-run the calibration.

Results after flagging

• The scores for tasks 16 and 21 now are 1.

• However the score for task 1 drops to 0.3 because "Neither primary or backup flux service could be queried. ASDM values used" (see plot below). But I don't think this is a big problem, because the derived fluxes for the calibrators seem to be ok. Any thoughts?

  

• The fluxes of J1744 from task 16 (now the calibrated/catalog flux ratios are all ~1)

  

• Calibrator image info from task 21 (note the green scores, all 1.00)

  

• Target image info from task 38 (note the green scores, all 1.00)

  

Overall assessment

• The continuum and line images seem good, although there is room to improve (better continuum selection, finer masking strategy for line cubes to avoid divergence, etc.).

[xinglunju]

Update on the re-calibration

The ARC has accepted the QA3 request and will re-run the calibration and replace the data in the archive. The problem is actually with the antenna CM02: it is not necessary to flag everything between scan=8 to 19, just flagging CM02 between scan=8 to 19 will solve the problem. The imaging results do not change much, though.

[xinglunju]

@keflavich The QA3 package has been delivered on Feb 16, could you download it to hipergator (if it hasn't been done)?

[keflavich]

The products are downloaded and the pipeline is being re-run

[keflavich]

TODO: I need to put up the new version of the pipeline weblog post-QA3

[xinglunju]

@keflavich did you finish running the pipeline? The two weblogs you posted either stopped before the aggregate continuum imaging or stopped before cube imaging & only included two EBs.

[keflavich]

The pipeline is fully re-run, I think - all the MSes and splits are present. I see all the image cubes.

...but you think some EBs are missing?

I see: https://data.rc.ufl.edu/secure/adamginsburg/ACES/weblogs-reimaging/member.uid___A001_X15a0_X192/pipeline-20220223T160940/html/t1-1.html

• uid___A002_Xf1ecde_X738b.ms
• uid___A002_Xf1ecde_X784b.ms
• uid___A002_Xf20692_Xd716.ms
• uid___A002_Xf20692_X110ee.ms

and in the directory I see:

drwxr-sr-x 28 adamginsburg adamginsburg 4.0K Feb 23 08:38 uid___A002_Xf1ecde_X738b.ms
drwxr-sr-x 28 adamginsburg adamginsburg 4.0K Feb 23 08:41 uid___A002_Xf1ecde_X784b.ms
drwxr-sr-x 28 adamginsburg adamginsburg 4.0K Feb 23 08:44 uid___A002_Xf20692_Xd716.ms
drwxr-sr-x 28 adamginsburg adamginsburg 4.0K Feb 23 08:47 uid___A002_Xf20692_X110ee.ms

so I think the pipeline run is all good.

[xinglunju]

Yes, this one has all the four EBs, but in the 'By Task' tab of the weblog, it goes as far as '10. hif_makeimlist: Set-up parameters for target aggregate continuum imaging' and then stops.

[keflavich]

The lack of weblogs is because the cubes are produced by the second approach to reimaging described here: https://github.com/ACES-CMZ/reduction_ACES/issues/163#issue-1272295566

[xinglunju]

Thanks for looking into this. For such pipeline runs, we need to download the images from Globus and review them, right?

[keflavich]

Yes, that's right. I'll work on integrating quicklooks of these cubes to the github issues.

[xinglunju]

Overview of the QA3 data

Imaging looks good. Set to 'done'? The calibration part of the QA3 pipeline should be in the ALMA archive, which is not accessible here, although it should be good.

Spectral windows

Continuum baseline is fitted with 0th order. Results look good. See spw20 and 22 for examples (from pipeline-20220223T160940)

Continuum & spectral line imaging

Looks ok. There are a few issues that can be fixed later when we combine with 12m/TP.

• As previously noted, the continuum image of spw20 has a questionable feature, which may be a matter of bad line-free channel selection.
• Possible divergence in the spw24 cube:

[xinglunju]

I recleaned the SPW24 cube on a local machine with cyclefactor = 2.0. No divergence can be seen. @pyhsiehATalma please use the updated cube for image combination.

I am uploading the images to Globus at: /upload/Sgr_A_st_ao_03_7M_reclean/

I have submitted a pull request to update the json file: #357

[keflavich]

Updated files have been moved to /orange/adamginsburg/ACES/data/2021.1.00172.L/science_goal.uid___A001_X1590_X30a8/group.uid___A001_X1590_X30a9/member.uid___A001_X15a0_X192/calibrated/working/. Old files are in /orange/adamginsburg/ACES/data/2021.1.00172.L/science_goal.uid___A001_X1590_X30a8/group.uid___A001_X1590_X30a9/member.uid___A001_X15a0_X192/calibrated/working/oldspw24

[ericliang45]

Hi there, I was looking at the images on Globus and found multiple versions of "ALMA pipeline stage". @d-l-walker suggested I report it here so that @keflavich could remove the duplicated file as necessary. Details below:

• Navigate to folder "/rawdata/2021.1.00172.L/science_goal.uid_A001_X1590X30a8/group.uidA001_X1590_X30a9/member.uid___A001_X15a0_X192/calibrated/working/"
• filter by "uid__A001*sci.spw22*cube*"
• "*s13_0*" and "*s38_0*" products co-exist, especially for cleaned cubes with "*iter1*".

ps. I didn't check how wide the scope of this multiplication is, beyond the said filtering I used.

Hope it helps.