Open keflavich opened 2 years ago
ksi85
commented
2 years ago Size mitigated (spw 33 dropped) although initial predicted product size (272 GB) is smaller than allowed product size (500 GB)
In the weblog in step 31 (hif_findcont) no images are available (status = old).
Spw 29: residual line emission in findcont channels?
keflavich
commented
2 years ago Something very strange has happened in the reimaging - the final continuum image looks nothing like continuum
It looks far more contaminated than even the worst of the individually-imaged MFS windows.
Left is "s36", right is "s10". I think 's36' is actually the result of running the full pipeline, while s10 is the 'rerun' version. s10 looks a lot more reasonable.
keflavich
commented
2 years ago The s10 image is actually fine, but dramatically under-cleaned.
xinglunju
commented
2 years ago I just checked the continuum images, and indeed s10 makes much more sense. This region is Sgr C. The s10 image clearly shows the cores & the HII region bubble. I am wondering what you have changed in the 'rerun' version of s10 @keflavich
xinglunju
commented
1 year ago The 's36' image I saw on Globus is different from the one in https://github.com/ACES-CMZ/reduction_ACES/issues/123#issuecomment-1222779605, and it is the same as the 's10' version.
SPW29 cube: line identification may be problematic, and thus the 'line-free' mom8 map shows some emission features. The line-ID plot below.
SPW33 cube size-mitigated, and has been added to the override list. The cube is available on Globus and looks good.
No other issues, so I will set this one to 'done'.
SpacialTree
commented
6 months ago While doing continuum QA for this field, I noticed divergence in spw 25 that impacts the SiO 2-1 v=1 maser map.
SiO 2-1 v=1 maser map:
Spw channel 1174
Spectrum at divergence point:
SpacialTree
commented
6 months ago Continuum QA
There is currently no new spw33_35 continuum image, so I am only looking at spw25_27
New continuum spw25_27
mfs:
old high spw33_35:
old total continuum spw25_29_31_33_35:
The continuum images seem to share the compact sources and HII region. The new continuum image includes some more diffuse large scale emission, which might be line emission sneaking in. This structure is missing from the mfs images, will need to compare with higher freq image when it is made.
SpacialTree
commented
5 months ago Continuum QA
This field is still missing the high spw continuum image. The spw25_27 continuum image looks fine.
Top: left = new spw25_27 cont, right = v1.1 spw25_27 Bottom: left = v1 high spw33_35, right = old aggregate
SpacialTree
commented
4 months ago Continuum QA
Big differences between the two continuum images - line emission?
Top = high spw33_35, bottom= low spw25_27
Update: The old v1 high spw33_35 continuum image looks fine. Were they misnamed?
keflavich
commented
4 months ago Unfortunately, it was not mislabeled. Something went horrendously wrong.
spw_selection = "33:97.68881475594455~97.69369776835802GHz;97.6956509733234~97.70444039566765GHz;97.70883510683977~97.74252789249272GHz;97.74496939869944~97.8016123426957GHz;97.80454215014377~97.93687178654882GHz;98.07359613412596~98.09849949743466GHz;98.10045270240006~98.15318923646554GHz;98.15514244143093~98.20299596308291GHz;98.20836727673773~98.21813330156468GHz;98.22106310901276~98.25768570211379GHz;98.26061550956186~98.265010220734GHz;98.26745172694072~98.29723810266289GHz;98.30065621135232~98.30602752500714GHz;98.31042223617926~98.3616938665207GHz;98.36364707148608~98.45105299368718GHz;98.45447110237662~98.45886581354875GHz;98.46619033216895~98.539435518371GHz;98.54334192830177~98.54968984443929GHz;98.5550611580941~98.55799096554217GHz;98.56482718292104~98.5706867978172GHz;98.57459320774798~98.58435923257491GHz;98.58924224498838~98.59119544995377GHz;98.59705506484994~98.61268070457305GHz;98.61512221077977~98.63367765795097GHz;98.64197877905386~98.64539688774329GHz;98.65027990015676~98.68885569822316GHz;98.69080890318855~98.7098526516011GHz;98.71327076029053~98.72743149628958GHz;98.73182620746171~98.73866242484057GHz;98.74305713601268~98.74940505215021GHz;98.75135825711558~98.7752850179416GHz;98.77821482538967~98.81923212966282GHz;98.82265023835225~98.89052411089949GHz;98.89394221958891~98.90614975062259GHz;98.90810295558798~98.9281233064832GHz;98.93300631889667~99.01162281875354GHz;99.01406432496026~99.0975638372306GHz;99.09951704219598~99.14590566012396GHz;99.14932376881339~99.16446110729514GHz;99.16641431226051~99.24844892080682GHz;99.25040212577221~99.25967984935781GHz;99.26749266921935~99.26846927170205GHz;99.27091077790878~99.28018850149438GHz;99.31485788963~99.31681109459541GHz;99.3636880137647~99.36612951997145GHz;99.38273176217724~99.4134947403821GHz;99.4154479453475~99.44181621238023GHz;99.44376941734562~99.45451204465525GHz;99.45646524962063~99.47111428686105GHz;99.47306749182644~99.47550899803316GHz;99.47746220299855~99.49357614396301GHz;99.4955293489284~99.53410514699482GHz;99.5360583519602~99.5370349544429GHz;99.53898815940829~99.5516839916833GHz;99.55461379913139~99.55559040161407GHz,35:99.5828859854252~99.60388255605783GHz;99.60583572541903~99.6068123100996GHz;99.60876547946079~99.67859128412289GHz;99.68298591518553~99.68835713092876GHz;99.69275176199142~99.69372834667202GHz;99.69568151603319~99.70788882454055GHz;99.7122834556032~99.75769464325057GHz;99.76208927431323~99.79529315345324GHz;99.79724632281442~99.80017607685619GHz;99.80359412323826~99.82312581685002GHz;99.8250789862112~99.86414237343475GHz;99.86609554279595~99.89734625257476GHz;99.89929942193595~100.00379398275895GHz;100.00623544446043~100.05604126317046GHz;100.09168660401195~100.095104650394GHz;100.1405158380414~100.14588705378463GHz;100.15662948527111~100.22303724355115GHz;100.22499041291232~100.32216058863091GHz;100.32557863501297~100.33534448181885GHz;100.33925082054121~100.34755179032621GHz;100.35438788309033~100.38661517754976GHz;100.38954493159152~100.39345127031388GHz;100.39540443967506~100.46230049029539GHz;100.46425365965656~100.48769169199069GHz;100.49745753879658~100.50966484730395GHz;100.5135711860263~100.51796581708894GHz;100.52187215581131~100.54482189580514GHz;100.54677506516632~100.56777163579898GHz;100.56972480516015~100.57070138984074GHz;100.57265455920191~100.62490183961341GHz;100.62685500897459~100.64052719450284GHz;100.64541011790578~100.65810571875343GHz;100.66201205747579~100.66494181151756GHz;100.6708013196011~100.6869149668308GHz;100.688868136192~100.69912227533817GHz;100.70107544469936~100.70888812214406GHz;100.71474763022759~100.72988469277672GHz;100.7318378621379~100.73672078554084GHz;100.74111541660348~100.74209200128408GHz;100.74502175532585~100.75234614043026GHz;100.75429930979143~100.85977045529503GHz;100.86172362465621~100.89150945741417GHz;100.89346262677535~100.91250602804682GHz;100.91445919740801~100.92178358251242GHz;100.92373675187359~100.93887381442272GHz;100.94082698378391~100.94229186080479GHz;100.94424503016596~101.00772303440424GHz;101.00967620376541~101.01846546589071GHz;101.02090692759218~101.02969618971747GHz;101.03311423609954~101.06387665353809GHz;101.06778299226045~101.07364250034396GHz;101.07559566970517~101.12100685735253GHz;101.1229600267137~101.12442490373459GHz;101.12637807309576~101.12784295011666GHz;101.12979611947783~101.13809708926284GHz;101.14005025862402~101.16544146031933GHz;101.1673946296805~101.16837121436109GHz;101.17032438372226~101.1756955994655GHz;101.17764876882669~101.2025516781817GHz;101.20645801690405~101.21427069434876GHz;101.21622386370994~101.32120671687323GHz;101.32413647091501~101.33634377942236GHz;101.33829694878354~101.35489888835355GHz;101.35685205771473~101.3592935194162GHz;101.36515302749973~101.41495884620977GHz;101.41691201557094~101.4213066466336GHz;101.42325981599477~101.44181492492596GHz;101.44376809428714~101.44669784832891GHz;101.44962760237067~101.45109247939155GHz"
Let's look at the frequency selection...
keflavich
commented
4 months ago selection looks fine?
keflavich
commented
4 months ago It got worse when I retried.
ashleythomasbarnes
commented
4 months ago Just talking to @keflavich about this, but this must be continuum, as the old continuum maps (as shown above) look like the MeerKat image
keflavich
commented
4 months ago The only explanation I have for this is that the _target.ms files being used for imaging are continuum subtracted. I don't think that's supposed to happen normally, but if it happened here, we need to check other fields carefully
keflavich
commented
4 months ago The story I've reconstructed so far:
uvcontsub is performed in the pipeline on the _target.ms file:
https://data.rc.ufl.edu/secure/adamginsburg/ACES/weblogs-reimaging/member.uid___A001_X15a0_X172/pipeline-20220713T050259/html/t2-4m.html?sidebar=sidebar_stage6&ms=all&subpage=casapy.log
However, when we go to image that, it's gone:
2024-05-17 15:28:23 INFO MSTransformManager::parseMsSpecParams Input file name is /blue/adamginsburg/adamginsburg/ACES/workdir/aj_aggregate_high_mfs_TM1_A001_X15a0_X172/uid___A002_Xf89be2_Xe4fd_target.ms
2024-05-17 15:28:23 INFO MSTransformManager::parseMsSpecParams Data column is CORRECTED
2024-05-17 15:28:23 INFO MSTransformManager::parseMsSpecParams Output file name is /blue/adamginsburg/adamginsburg/ACES/workdir/aj_aggregate_high_mfs_TM1_A001_X15a0_X172/uid___A002_Xf89be2_Xe4fd_target_aggregate_high.ms
2024-05-17 15:28:23 INFO MSTransformManager::parseDataSelParams field selection is Sgr_A_star
2024-05-17 15:28:23 INFO MSTransformManager::parseDataSelParams spw selection is 33,35
2024-05-17 15:28:23 INFO MSTransformManager::parseChanAvgParams Channel average is activated
2024-05-17 15:28:23 INFO MSTransformManager::parseChanAvgParams Channel bin is [10]
2024-05-17 15:28:23 WARN MSTransformManager::checkDataColumnsToFill CORRECTED_DATA column requested but not available in input MSI don't know what this implies.
An option I'm considering is overriding the data selection to go back to the non-target ms files:
"Sgr_A_st_aj_03_TM1": {
"tclean_cont_pars": {
"aggregate_low": {
"vis": [
"uid___A002_Xf89be2_Xe4fd.ms",
"uid___A002_Xf8b429_X1ea4.ms",
"uid___A002_Xf8b429_X2c01.ms"
],
"datacolumn": "data"
},
"aggregate_high": {
"vis": [
"uid___A002_Xf89be2_Xe4fd.ms",
"uid___A002_Xf8b429_X1ea4.ms",
"uid___A002_Xf8b429_X2c01.ms"
],
"datacolumn": "data"
},
"aggregate": {
"vis": [
"uid___A002_Xf89be2_Xe4fd.ms",
"uid___A002_Xf8b429_X1ea4.ms",
"uid___A002_Xf8b429_X2c01.ms"
],
"datacolumn": "data"
}
}I'm not sure this will help anything, though.
keflavich
commented
4 months ago Changing to datacolumn='data' worked.
top: spw25+27, spw33+35 bottom: composite new, composite old
There are two bright SiO maser stars contaminating the images with spw25+27
keflavich
commented
4 months ago I suspect the masers are showing up because of elevated noise in the line wing channels of the SiO masers, causing them to be included based on the peak threshold. I suspect the peak of the line is not included, but the wings are, and they're bright enough to cause this contamination.
Probably in v3, we want to hand-flag SiO maser lines - maybe the whole +/-200 km/s around them
xinglunju
commented
4 months ago Just FYI, comparing 0.3" resolution Band 3 continuum image from a PI project (left) and ACES spw33+35 (right)
Sgr_A_st_aj_03_TM1 uid://A001/X15a0/X172
[x] Observations completed?
[x] Delivered?
[x] Downloaded? (specify where)
[ ] Weblog unpacked
[ ] Weblog Quality Assessment?
Extra Weblog Sgr_A_st_aj_03_TM1_1 -> pipeline-20220713T050259, Extra Weblog Sgr_A_st_aj_03_TM1_0 -> pipeline-20220622T104538
[ ] Imaging: Continuum
[ ] Imaging: Lines
Product Links:
Reprocessed Product Links: