Observation planning: SBs need checking

[keflavich]

there has been a mistake in the implementation of the velocity shifts for the 63 SBs that you asked us to modify. We applied the shift in the "wrong direction", e.g. -30 km/s instead of 30 km/s, and probably part of the line is going to be outside the spectral windows. Fortunately, we are going to be able to fix it (the P2G is already on it) and reobserve the data taken.

Since some of these wrong-shifted data have already been delivered - SBs # 13 (7M), #36 (7M), #37 (TP), #44 (7M) - I would need you to check that, indeed, the line is partially missed and you can not achieve your science goal. This should probably happen just in spw 20 and 22 (the higher spectral resolution ones). If this is the case, we will put these SBs in QA3, which means that the data will be reobserved with the right setup and you keep the already delivered data in the meanwhile.

• 7m 13 m issue Execution Block ID uid://A001/X15a0/Xea Sgr_A_st_m_03_7M [SgrB2] #15
• 7m 36 aj issue Execution Block ID uid://A001/X15a0/X174 Sgr_A_st_aj_03_7M #23
• TP 37 ak issue Execution Block ID uid://A001/X15a0/X17c Sgr_A_st_ak_03_TP #13
• 7m 44 ar issue Execution Block ID uid://A001/X15a0/X1a4 Sgr_A_st_ar_03_7M #19

The to-do item is, for each of these observations, to check the high-spectral-resolution windows (noted as spw20 and 22, but please confirm that) and see whether / how much of the bright line is cut off, and whether a 60km/s shift would likely correct the issue.

[d-l-walker]

7m 13 m issue #15

• Spectra for SPWs 20 & 22 shown below.
• SPW 20 looks OK.
• SPW 22 would benefit from a +60 km/s shift to capture more of that broad emission at the positive edge.

SPW 20

SPW 22

[d-l-walker]

7m 36 aj issue #23

• Spectra for SPWs 20 & 22 shown below.
• Both look OK. If anything the emission is very close to the negative edge of the SPWs already.

SPW20

SPW 22

[d-l-walker]

TP 37 ak issue #13

• Spectra for SPWs 20 & 22 shown below.
• Would benefit from a +60 km/s shift, particularly SPW 20.

SPW 20 (actually SPW 21, but I think this is a TP thing and the numbers are just off by 1)

SPW 22 (23)

(End channel is blank, hence the funky spike there)

[keflavich]

36 / aj had the correct shift, then - ALMA just made a mistake in reporting that one as a problem, but they observed it alright. I think they got confused b/c we had to shift some windows +30, some windows -30

[d-l-walker]

7m 44 ar issue #19

• This would also benefit from the shift. Both SPWs have emission cut off, particularly SPW 20.

SPW 20

SPW 22

[d-l-walker]

Summary

My view is that all of the below would benefit from the proposed velocity shift.

• 7m 13 m issue Execution Block ID uid://A001/X15a0/Xea Sgr_A_st_m_03_7M [SgrB2] #15
• TP 37 ak issue Execution Block ID uid://A001/X15a0/X17c Sgr_A_st_ak_03_TP #13
• 7m 44 ar issue Execution Block ID uid://A001/X15a0/X1a4 Sgr_A_st_ar_03_7M #19

[ashleythomasbarnes]

Thanks for these checks @d-l-walker!

Below are the shifts requested at https://github.com/ACES-CMZ/reduction_ACES/blob/main/SB_naming.tsv, and my thoughts.

• 30kms ---> Execution Block ID uid://A001/X15a0/Xea Sgr_A_st_m_03_7M [SgrB2] #15 -> clearly needs shift
• -30kms ---> Execution Block ID uid://A001/X15a0/X174 Sgr_A_st_aj_03_7M #23 -> not clear from 7m data, but our checks of the SD data showed there is emission at these lower velocities. As these could make up part of the wiggles, I would suggest shifting this velocity down.
• 30kms ---> Execution Block ID uid://A001/X15a0/X17c Sgr_A_st_ak_03_TP #13 -> clearly needs shift
• 40kms ---> Execution Block ID uid://A001/X15a0/X1a4 Sgr_A_st_ar_03_7M #19 -> clearly needs shift - also note this is needs to be shifted by more than the other EBs

[keflavich]

@ashleythomasbarnes for the -30 km/s one, could you clarify? It has already been shifted by -30km/s with respect to the original. Are you saying we should ask for it to change to -40 km/s?

[ashleythomasbarnes]

As I understand it, the EB aj is shifted by +30km not -30kms (or am I missing this) - I can download the cube and check myself tomorrow.

[keflavich]

I thought all four of the EBs we were asked to evaluate were shifted by -30 km/s

[ashleythomasbarnes]

This is not my understanding of the email? "e.g. -30 km/s instead of 30 km/s" - I'll reply for clarification

[ashleythomasbarnes]

Email discussion on the issue - does this clear things up @keflavich?

Could I just ask for some clarification on the issue?

The requested shifts and incorrectly shifted EBs are the following.

• requested +30kms — observed -30kms ---> Execution Block ID uid://A001/X15a0/Xea // Sgr_A_st_m_03_7M
• requested -30kms — observed +30kms ---> Execution Block ID uid://A001/X15a0/X174 // Sgr_A_st_aj_03_7M
• requested +30kms — observed -30kms ---> Execution Block ID uid://A001/X15a0/X17c // Sgr_A_st_ak_03_TP
• requested +40kms — observed -40kms ---> Execution Block ID uid://A001/X15a0/X1a4 // Sgr_A_st_ar_03_7M

Is this correct? This appears to be what our tests are showing, and when comparing to the GitHub table.

Yes, that is correct.
Let me know if you need anything else, and again, sorry for this!
I will copy your last email and my response to the Helpdesk ticket to keep a record of everything there.

[ashleythomasbarnes]

Once we're one the same page I think we should request these shifted as previously determined.

[keflavich]

Yes, let's ask for the reobservations.

[snlongmore]

@keflavich and @ashleythomasbarnes, I've responded to the ALMA helpdesk ticket with the following message:

We've gone through and looked at the observations in detail and can confirm that we need to re-observe at the originally requested velocity shifts to get all of the emission in the bandpass.

[snlongmore]

And an update from AK

just an update on the situation. The SBs that haven't been observed were already fixed a couple of days ago. These are

*_01 (+40km/s --> -0.0117188 GHz)
*_04 (+30km/s --> -0.0087891 GHz)
*_07 (+30km/s --> -0.0087891 GHz)
*_11 (+30km/s --> -0.0087891 GHz)
*_14 (+30km/s --> -0.0087891 GHz)
*_18 (+30km/s --> -0.0087891 GHz)
*_21 (+30km/s --> -0.0087891 GHz)
*_22 (+30km/s --> -0.0087891 GHz)
*_23 (+30km/s --> -0.0087891 GHz)
*_26 (+40km/s --> -0.0117188 GHz)
*_34 (+30km/s --> -0.0087891 GHz)
*_39 (+30km/s --> -0.0087891 GHz)
*_40 (+30km/s --> -0.0087891 GHz)

# 26 and # 40 are set to Ready and the rest to Waiting, since those are lower priority SBs.

[snlongmore]

There are two more question about reprioritisation of the re-observations:

1. What about the P2G suggestion of putting these SBs to a lower priority? (see message from Fri, 4th Feb 2022 10:19am) Would this approach work for you? Or you would like to maintain the current priorities?

2. Additionally, let me know if you want to put some of the low-priority SBs to ready.

What are people's thoughts? Regarding point 1., I would have thought it would make sense to put the re-observations at a lower priority as suggested. I would also think it makes sense to put some of the current low-priority SB's to Ready if we are getting through the high priority ones.

[keflavich]

Yes, put them back in the queue at lower priority

[snlongmore]

OK, responded as suggested.

[keflavich]

Closing as completed; we did all the related work and the SBs have been queued appropriately.