Closed low-sky closed 7 years ago
Hey Erik, Thanks for working on this! I've taken a look at the L1688 data. It looks like the new gridding code is getting rid of the spikes, at least as far as I've checked in the (3,3) cube. It also seems to be getting rid of good signal, though. Here's a comparison of the same velocity channel in the DR1 vs. new cube for NH3 (1,1): (Same colour range, DR1 is on the right)
Thanks; good check. The defaults must be too aggressive.
The issue is that some feeds were producing a lot of scans flagged by rms flagging. Namely, if the rms in a spectrum is > 1.25 times the radiometer expectation, it was getting flagged. This is also new in this refactor. Some files lost 90% of their data, which appear to be okay otherwise. Maybe the Tsys data were bad? Regardless, I've upped the default GAS rejection threshold to 1.5 and this cleans up the issues with missing data.
I'm running some new versions now.
Here's the comparable image using the new code.
I need to wait for the (3,3) to finish to make sure it's working as intended.
@low-sky Running through the gridding on the GB machines, and I ended up with an 'UnboundLocalError' in the gbtpipe calls re: the eulerFlag variable being referenced before assignment. It looks like I've got gbtpipe up-to-date on the GB machines, so am I missing something?
Hi @rfriesen -- Okay; I pushed an untested fix to main (the default for the flag needs to be set to False). I'll try to test it ASAP, but if it clears things up; let me know.
I squashed a couple more bugs in GBTpipe (pesky commas) and it looks to be running again. thanks for the heads-up.
Seems to be running now!
Coming up with an error again while trying to grid, this time with the header of the new cube:
IOError Traceback (most recent call last)
That looks like a readfits
failure. Probably triggered by trying to read an invalid file at some point. I will try to reproduce on the GBT machines to isolate what's causing it.
Hi @rfriesen @jpinedaf
First, don't merge quite yet. I wanted to get this out for discussion.
My fix to the spikes in the (3,3) window is to completely rewrite the gridding code. Or rather, what I've done is to use some code that has been evolving and refactored into a stand-alone package called
gbtpipe
that includes a lot of the common framework used across spectral line surveys. The code hasn't changed too much, but it does have some additional flagging that I had already built for KEYSTONE, namelyflagSpike
which flags spikes in VEGAS. I'm running a full-end-to-end right now for L1688 but it seems to be working as intended.The gbtpipe repo is at https://github.com/low-sky/gbtpipe/ with relevant changes to the gridding code here.
Check out the files in
/lustre/pipeline/scratch/GAS/images/L1688
as they come in over the next day.