Execution Block ID uid://A001/X15a0/X184 Sgr_A_st_am_03_TM1 #259
Comments
|
I'm doing the QA2 for this SB, and it has a similar issue to #126 in that it is an irregular and elongated mosaic. It's not quite as severe as the other instance, but the PSF is still just outside the mosaic and causing the synthesised beams to misbehave. I'm going to do the manual imaging at the QA2 stage for this, which will take a while, but I just wanted to flag this. |
|
The auto-script-writing failed because there are no clean parameters: This is mostly a note for me; I need to put in an exception for this case, which I did in c780237 |
|
@keflavich any idea what the status of this is? I've assigned myself since I did the manual QA2. I know that we need to re-do the imaging with full spectral resolution, and that it's a bit awkward due to the over-sized image to account for the PSF offset. I don't see any final products in |
|
Update: @keflavich is going to look into this in the next ~ week. If it's easier to do so, I will run the un-size-mitigated cleaning locally. |
|
@d-l-walker can you add the parameters as you did for al in #290? |
|
I've added the continuum parameters in 12b4e64 |
|
Scripts weren't being written because I had to manually link the files from |
|
@keflavich I added the cube parameters to your PR in 50738ae I also tweaked the continuum parameters that you had added:
|
|
Got a failure: |
|
Should we just be using the |
|
There are two re-imaging cubes of spw33, they are, (1) Sgr_A_star_sci33.cube.I.manual.pbcor.fits-> There is no divergence in the cube, but it only has 1917 channels ( |
|
Thanks @pyhsiehATalma! Yes, the full resolution one should be the new one, but I don't think it had been checked until now, so thanks for checking the cube! I can submit a PR to increase the cyclefactor, which will hopefully fix the issue. Edit: Per discussion in telecon, we'll probably proceed with the mild divergence for now, as this cube takes a long time to clean. |
|
|
|
channel 670
For the purpose of combination, I can reimage the narrowband within the -300 km/s to 300 km/s velocity range locally. For archival purposes, would you like to rerun the pipeline? |
|
Thanks @pyhsiehATalma. This is much more significant that the previous one you posted. @keflavich I think this necessitates re-cleaning now, right? |
|
Yes, with new parameters. |
|
Bumped cyclefactor to 2.5 in 0051bbc |
|
This field has a huge beam: This is problematic, as it is the limiting factor in full-field mosaics. I think we may need to taper to force a higher resolution here, or just leave this field out of the final images (which is what I'm doing right now). |
|
The weblog indicates that the beam should be smaller, 2.32x1.47 arcsec: That link also says this field shouldn't have passed QA because the beam is too large. @d-l-walker ideas? |
|
@keflavich yeah that's strange. I've just checked the products that I manually imaged, and I see: Not great, but better than what you're seeing here for the cubes. Also using As far as I can tell, you're still manually forcing the PSF to be inside the mosaic with the re-cleans, right? The beams that you're reporting are broadly consistent with, though slightly larger than, what we were seeing during the QA2 stage prior to fixing the issue with the PSF 🤔 My suspicion is that this must be related to the weird mosaic shape and PSF issue still. I've just checked, and while there is a difference between the phasecenter that I used vs. what you're using (see below. mine = red square, yours = yellow), they're both firmly inside the mosaic, so I'm not sure why that would cause any issues. TL;DR: I don't know. Seems suspiciously similar to the issues we saw prior to fixing the PSF, but that should be addressed based on what I can see ... I'll keep digging.
|
|
Hi @keflavich @d-l-walker , I am also curious about this larger beam issue, so I did some tests (robust=0). I have found that the reason for the large beam is the gridder="mosaic" and mosweight=True option, as the beam size is approximately 2.1"x1.6" when I use the gridder="standard" option on the same mosaic image. Here is the explanation of the gridder='mosaic' option and its warning. The gridder='mosaic' option will trigger mosweight=True by default. https://casadocs.readthedocs.io/en/stable/notebooks/synthesis_imaging.html When doing Brigg’s style weighting (including uniform) in tclean, the mosweight subparameter of the mosaic gridder determines whether to weight each field in a mosaic independently (mosweight = True), or to calculate the weight density from the average uv distribution of all the fields combined (mosweight = False). The underlying issue with more uniform robust weighting is how the weight density maps onto the uv-grid, which can give high weight to areas of the uv-plane that are not actually more sensitive. The setting mosweight = True has long been known as potentially useful in cases where a mosaic has non-uniform sensitivity, but it was found that it is also very important for more uniform values of robust Briggs weighting in the presence of relatively poor uv-coverage. For example, snap-shot ALMA mosaics with mosweight = False typically show an increase in noise in the corners or in the areas furthest away from the phase-center. Therefore, as of CASA 5.4, the mosweight sub-parameter in tclean has the default value mosweight = True. WARNING: the default setting of mosweight=True under the mosaic gridder in tclean has the following disadvantages: (1) it may potentially cause memory issues for large VLA mosaics; (2) the major and minor axis of the synthesized beam may be ~10% larger than with mosweight=False. Please change to mosweight=False to get around these issues. So, perhaps using mosweight=True, larger beam can occur because areas (or shorter baselines) with higher sensitivity (and therefore more weight) contribute more to the final PSF. I found the beam size is 2"x1.6" using gridder='mosaic' and mosweight=False, but I haven't had a time to check the image quality. |
|
|
|
Continuum QA This field has none of the new continuum images made, there is only the old spw25_27_29_31_33_35 continuum image. There are also no mfs images. spw25_27_29_31_33_35 |
|
Continuum QA This field is still missing any other continuum images except the aggregate.
|
|
Continuum QA Still missing new continuum images. |
|
We never resolved the beam size issues. @pyhsiehATalma did you ever check the image quality? Is it safe to switch to mosweight=False? |
github-project-automation
bot
moved this to Execution Blocks under QA
in Data Reduction
Sgr_A_st_am_03_TM1
uid://A001/X15a0/X184
Observations completed?
Delivered?
Downloaded? (specify where)
Weblog unpacked
Weblog Quality Assessment?
Imaging: Continuum
Imaging: Lines
Product Links:
Reprocessed Product Links:
The text was updated successfully, but these errors were encountered: