VEGAS Astronomical Observations
Observations affected by the "CRVAL bug"
AGBT14A_212_01 - junk scan
AGBT14A_284_11,12,13 - Kristine Spekkens - Amanda to contact
AGBT14A_418_01,02,10 - Walter Max-Moerbeck - Anish to contact
AGBT14A_437_08,10,11,12,13,14 - Amanda Kepley
AGBT14A_538_01 - Scott Ransom - alerted by Richard Prestage
TGBT13A_501_04,05
TGBT13A_502_23,24,25,26,27,29,33,35,37,39,40,42,46,51,52,53,54,55,56,57
TINT_012214
TINT_12_02_14
TINT_18_03_14
TREG_140128
TREG_140130
TSDW_04_05_01A
TSDW_04_11_01A
Support Scientists - please contact your observers and alert them to this.
AGBT11B_066 - Dan Werthimer.
Friend: Anish, PI: Dan Werthimer.
The original Ku-band galactic center search project. Used mode 1 with 0.5-ms integrations (the vegas "slow pulsar"
mode). As far as Paul knows there were no serious vegas-related problems with this.
AGBT13A_095 - Francesco De Gasperin
Friend: Amanda, PI: Francesco De Gasperin
This was an early project to do radio continuum observations of M87. It ran in September 2013 and wasn't very successful. The PI re-proposed for the project at the Feb. 1, 2014 deadline.
AGBT13A_516 - Andrea Possenti
Friend: Toney M., PI: Andrea Possenti
DDT proposal to observe the galactic center magnetar shortly after it turned on. Used mode 1 with 0.5-ms integrations (the vegas "slow pulsar"
mode). As far as Paul knows there were no serious vegas-related problems with this
AGBT13A_518 - Dan Werthimer
Friend: Paul Demorest, PI: Dan Werthimer
DDT proposal to observe the galactic center magnetar shortly after it turned on. Used mode 1 with 0.5-ms integrations (the vegas "slow pulsar"
mode). As far as Paul knows there were no serious vegas-related problems with this
AGBT13B_169 - Kristen McQuinn
http://library.nrao.edu/proposals/catalog/7714
I don't know the details of these observations
- Alison Ford has been pinged about these observations.
- As far as Alison knows, they are finished, and do not want to use VEGAS. Creation of two datafiles in this directory remains a mystery.
AGBT13B_312 - James Jackson RAMPS survey
http://library.nrao.edu/proposals/catalog/8222
Anish Roshi is supporting this proposal.
Problem :
1. During mapping scans vegas had issues starting the scan at the beginning of a row. This start problem happened every 3rd or 4th row scan. Ray has looked into this issue.
- Ray has fixed this issue.
2. SDFITs file did not fill the data from all feeds. Bob has been informed about it.
The data is present in the raw vegas fits file.
- This was confusion over IFNUM
3. vegasdm -- when displaying requantized values (ie snapblock ?) the measured power in one of the pol is always at 0 dBm. There are occasional drop in power (about 15 dB or more) in the ADC measpwr display (Brian Mason has reported the same issue).
- First issue has been fixed, monitoring second issue
AGBT14A_212 - Farhad Yusef-Zadeh
http://library.nrao.edu/proposals/catalog/8456
I don't know who is supporting these observations
- Ron Maddalena has been pinged
- As far as he knows, they are not planning to use VEGAS. Creation of two datafiles remains a mystery.
AGBT14A_284 - Kristine Spekkens
http://library.nrao.edu/proposals/catalog/8549
Brian Mason is on this proposal.
From Brian:
The continuum level we see in the data appears bi-stable, bouncing between two values with one of them slightly more common than the other and the internal noise to the more common state considerably lower than the "bounce". This appears to relate to variations in the reported integration time ("exposure" in the SDFITS file), although not obviously in a reproducible enough way that I can correct it. I also see some variation in the actual durations of the integrations relative to the reported durations (~0.2 sec), in addition to the larger variations in the "exposure time" that is reported for each integration."
See plots:
- Bistable continuum levels:
- Bistable continuum levels - blown up:
- VEGAS exposure durations:
The "multi-level continuum" instability associated with the blanking did indeed go away in TOPO. See attached plot of the mean across the spectrum (y-axis) vs spectrum number (x-axis) in the SDFITS file. So the x-axis is basically time through a sequence of scans. The last 3rd of the plot was acquired in TOPO and it looks perfectly clean to me other than what's probably RFI and some bright source.
Curiously the EXPOSURE still varies a little, even in TOPO, and sometimes has a value larger than the nominal scan duration (0.2 or 0.1 sec in these scans). See second plot, vegasBlanking. Again, the last 1/3rd of the plot was taken in TOPO. Maybe this is some rounding issue in the manager or filler.
- Tsys showing effect of observing in TOPO:
- Plot showing variation in exposure times:
- We ran out of time to discuss this
AGBT14A_418 - Walter Max-Moerbeck
http://library.nrao.edu/proposals/catalog/8820
Anish Roshi is on this proposal. They appear to have observed successfully. We have no reports of any problems.
AGBT14A_437 - Amanda Kepley
http://library.nrao.edu/proposals/catalog/8622
Amanda is supporting herself...
This is the report on the VEGAS shared risk observations for my project
AGBT14A _437. We are mapping HCN/HCO+ in the disk of a galaxy using both
beams of the W-band receiver. The program should not be affected by the
blanking time estimate issues because it
does not have a noise diode. Four spectrometers have been configured in
mode 4 to provide to spectral windows for each beam. The requested
integration time for this data is 0.5s and there is no switching.
Doppler tracking was used.
Overall, the data look good. Issues I've seen are:
1.) Spikes other than the known center spike in the center of the YY
polarization (plnum=0). Presumably these will improve with the ADC
calibration? These spikes do not subtract out in the final spectrum and
do vary between data sets. Fortunately, they appear
to be issues in single channels. I am currently manually flagging the
affected channels prior to smoothing.
2.) The maximum channel size for the 187.5 MHz bandwidth is much smaller
than I need: 5.7kHz is 0.019km/s at 90 GHz, which is much smaller than
the velocity width of the features I'm interested in (5-10km/s). I've
ended up doing a significant amount of averaging
early on in the data reduction process to get closer to my desired
channel size and reduce the total amount of data.
3.) In a related notes, the data rates for VEGAS are high enough that
using more efficient routines in GBTIDL like putchunk and getchunk
becomes important. We may want to add additional user documentation
emphasizing these routines.
4.) I've attached a plot of DURATION (total time including blanking) -
INTEGRAT (total time excluding blanking time). It looks like difference
is typically 2ms. However, it goes up to 12ms, and even more
mysteriously can be as low as -0.08ms, i.e., INTEGRAT
is
longer than DURATION. See attached figure (INTEGRAT_DURATION.ps).
INTEGRAT_DURATION.ps
AGBT14A_538 - Scott Ransom - Galactic Center Magnetar TOO
No entry in the library database that I can find...
Richard Prestage supported this proposal. They asked for 0.5 ms integration times, but got 1ms integration times.
- we believe this is due to the "rounding up issue. Ray will release a fix Thursday 24th April. Earlier discussions about integration times of 0.524 seconds were a red herring.
- According to Scott, no other problems.
AGBT13B_367 -- Adam Leroy
SUMMARY: We visited for project 14A-367, a program to obtain short spacing information for an
L-Band VLA survey of M31. The project uses VEGAS and seeks line and
continuum information. With extensive help from co-I and friend of the
telescope Kepley, we set up VEGAS configurations for line and polarized
continuum. These needed to be separate with the release of mixed modes
still in the future. Working on code from Pisano, Johnson, and Kepley we
developed a
PAScanMap routine to observe the target (and the paired M33
program) using a series of slews at an arbitrary position angle. The
procedure worked even over the relatively large area of M31 (4x2 degrees
here) but would flounder at the poles. We had a series of successful
observations Saturday, 7 June, in which VEGAS obtained nice mapping of
HI in M31 (though only over a small area). On Monday, 9 June, VEGAS
produced non-useful data and we had to revert to a backup spectrometer
configuration, effectively losing ~3h from the project.
ISSUES
THAT CROPPED UP/SUGGESTIONS (probably all known):
(1) The VEGAS
restart needs to be a basic tool in the operator toolkit. Neither we nor
the operator realized that this was an option (sorry!), but seems like
the first line of defense.
(2) The LO blanking creates an issue
with big maps that prevents rapid scanning while doppler tracking (or,
to a lesser degree, frequency switching). Given that rapid coverages
make for maps more robust to RFI, this could be an issue, though we were
still getting good results. A verified path to reframe non Doppler
tracked data into LSRK and velocity regridding/interpolation routines
would improve the situation, though we still hit a fairly hard floor as
long as we use frequency switching.
(3) Mixed modes would be great, but with frequency switching on and #2 in place, I'm not sure we
see a totally clean path to joint continuum and line mapping of the sort that would be really great to do.
CONTRIBUTIONS (payback for the shared risk part):
(1) The
PAScanMap routine above is with friend/co-I Kepley and we believe it should be useful for the
observatory in general. A few additional generalizations would make arbitrary OTF mapping even easier.
(2) These are mapping experiments, and we have shared with GBT staff Kepley and Frayer
routines that will handle gridding of data inside the GBTIDL environment (rather than going to AIPS). The main gridder is at:
https://github.com/akleroy/herapipe/blob/master/cubes/grid_otf.pro <https://github.com/akleroy/herapipe/blob/master/cubes/grid_otf.pro>
while a path use this with SDFITS and a routine to make FITS headers appropriate for gridding are at:
/home/scratch/aleroy/make_header.pro
/home/scratch/aleroy/build_m31_map.pro
over the rest of the course of the project, we aim to generalize the header constructor a bit
and write a wrapper that handles the general case of transforming a
single or set of SDFITS files into a cube or map. We hope this is of use to the observatory.
(3) We'll keep up the updates on how VEGAS does.
PICTURE: Two attached demonstrating our progress
m31_pv.png shows the position velocity diagram along the minor axis near the western end of the galaxy. This is perpendicular to rotation,
so you're seeing the Galaxy near zero then a weird projection of the M31 spider diagram down around -500 km/s.
-
m31_hi_vegas_sofar.png shows the coverage we have achieved with VEGAS so far.
AGBT14A_258 -- Erik Rosolowsky
Thank you again for your assistance during the shared risk use of VEGAS. From the perspective of
project 14A-258, the run was successful. Between this work and work on
14A-367 we were able to observe the galaxy M33 using Mode 1 and full
cross polarization data. We observed a polarization block on 3C286
using observatory-furnished spider scan methods and used the RHSTK
calibration scripts to obtain a successful calibration solution (Mueller
Matrix solution). The matrix solutions evolve across the bandpass. I
adapted some of the RHSTK code base, which can be found cloned under my
directory on the GBT systems ~erosolow/idl/rhstk
As you know, Adam and I also worked up revisions to
PAScanMap
which are in the 14A367 directory.
Overall, the wideband VEGAS data were sufficiently stable to reliably map the
galaxy. There are small-scale ripples in the bandpass, but these seem
time stationary on the several minute timescale so they can be
calibrated out. I know you invested a lot of effort in making this
happen, so thanks again. I think it paid off.
I attach two plots. The first is the phase
across the band from calibration using the noise cal (
phase.png ). This appears
pretty stable and well determined just from noise injection. The other
one is a poorly gridded map from stokes I which is somewhat calibrated
(say 30%) and runs on a linear brightness scale from 0 to 1 K ((
M33-StokesI.png ). I'll
polish it up with proper gridding soon.
AGBT14A_316 -- Bhaswati Mookerjea, report by Anish Roshi
Hi Toney,
We
used vegas for frequency switched with Doppler track observation of
recombination lines toward the source W49 at Q-band. As per
recommendation
for LO1 switching, we used a switch period of 5 sec, and also used tint =
5 sec. Freq was switched by +/- 32 MHz. Two banks (A and B) of vegas
were used in mode 4 to process 2 IFs. The total on source observing time
was about 2 hrs.
I examined the spectra corresponding to all integrations
and all states. The general spectral shape were consistent -- did not
see any `bad' spectral shape, spectra with all values zeros etc. The
data is useful and we have detected the lines.
Two issues --
Tsys vs integration
number -- Two plots of Tsys vs integration number are attached
(
tsysvsint.png). As you can see in these plots there are `spikes' in
calculated Tsys values. Such spikes are present in about 20 % of the
scans.
The `spike' is present (mostly) in both pol, both banks for
the same integration.
Spectral baseline -- Attached is
a plot of (sig-ref)/ref for different integrations in scan 18. As you
can see in the figure, some of the spectra do not follow the `general
spectral shape'. Those spectra corresponds to the `spikes' in Tsys. So
the Tsys `spikes' and `bad' spectra are related.
Cause -- Since it is Q-band obs, I don't suspect RFI. Two
other possibilities are (1) LO1 blanking is not sufficient is some
cases (2) Vegas is not blanking or calculating the exposure time
correctly. Amanda has tested the second possibility and found that vegas
is doing things correctly, but I will repeat her test this week.
- gbt14a316tsysvsint_scan18_ifnum1.png:
- gbt14a317tsysvsint_scan38_ifnum0.png:
Anish
Update: It looks like this data has something funny with it's Tsys'es. Discussion is on-going.
--
RichardPrestage - 2014-04-21