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:
    vegasBistableContinuumExposure.png

  • Bistable continuum levels - blown up:
    vegasBistableContinuumExposureBigger.png

  • VEGAS exposure durations:
    vegasExposureDurations.png

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:
    vegasMeanTsys.png

  • Plot showing variation in exposure times:
    vegasBlanking.png

  • 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.

thales 7  akepley1.png

thales 7  akepley2.png

thales 7  akepley3.png

thales 7  akepley4.png

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:
    gbt14a316tsysvsint scan18 ifnum1.png

  • gbt14a317tsysvsint_scan38_ifnum0.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
Topic attachments
I Attachment ActionSorted descending Size Date Who Comment
INTEGRAT_DURATION.psps INTEGRAT_DURATION.ps manage 33 K 2014-05-07 - 16:16 AmandaKepley  
M33-StokesI.pngpng M33-StokesI.png manage 48 K 2014-06-18 - 18:28 AmandaKepley  
gbt14a316calspecvsint_scan18_ifnum0.psps gbt14a316calspecvsint_scan18_ifnum0.ps manage 14 MB 2014-07-09 - 11:43 AmandaKepley  
gbt14a316tsysvsint_scan18_ifnum1.pngpng gbt14a316tsysvsint_scan18_ifnum1.png manage 23 K 2014-07-09 - 11:44 AmandaKepley  
gbt14a317tsysvsint_scan38_ifnum0.pngpng gbt14a317tsysvsint_scan38_ifnum0.png manage 22 K 2014-07-09 - 11:44 AmandaKepley  
m31_hi_vegas_sofar.pngpng m31_hi_vegas_sofar.png manage 14 K 2014-06-18 - 18:23 AmandaKepley  
m31_pv.pngpng m31_pv.png manage 20 K 2014-06-18 - 18:22 AmandaKepley  
phase.pngpng phase.png manage 31 K 2014-06-18 - 18:28 AmandaKepley  
thales_7__akepley1.pngpng thales_7__akepley1.png manage 38 K 2014-05-07 - 16:16 AmandaKepley  
thales_7__akepley2.pngpng thales_7__akepley2.png manage 38 K 2014-05-07 - 16:16 AmandaKepley  
thales_7__akepley3.pngpng thales_7__akepley3.png manage 40 K 2014-05-07 - 16:16 AmandaKepley  
thales_7__akepley4.pngpng thales_7__akepley4.png manage 38 K 2014-05-07 - 16:16 AmandaKepley  
vegasBistableContinuumExposure.pngpng vegasBistableContinuumExposure.png manage 10 K 2014-04-21 - 09:31 RichardPrestage Bistable continuum levels
vegasBistableContinuumExposureBigger.pngpng vegasBistableContinuumExposureBigger.png manage 11 K 2014-04-21 - 09:31 RichardPrestage Bistable continuum levels - blown up
vegasBlanking.pngpng vegasBlanking.png manage 8 K 2014-04-21 - 16:24 RichardPrestage Plot showing variation in exposure times
vegasExposureDurations.pngpng vegasExposureDurations.png manage 9 K 2014-04-21 - 09:31 RichardPrestage VEGAS exposure durations
vegasMeanTsys.pngpng vegasMeanTsys.png manage 14 K 2014-04-21 - 16:24 RichardPrestage Tsys showing effect of observing in TOPO
Topic revision: r14 - 2014-07-09, AmandaKepley
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback