TGBT15A_915_89 - Test fftshift values for various BOF files

Goals

  • Test different values of fftshift for different BOFs to see which eliminate overflow and artifacts

Details

Session begins at 14:15
  • Switched VEGAS to pulsar branch
  • Performing initial scan using overflow BOF file (c0800x0512_fft_ovf_01_x14_7_2017_Feb_16_1132.bof)
    • Using 00-CoherentModeArtifactTesting scheduling block
    • Set up for L-Band at fctr=1500 MHz
    • SB submitted at 14:26
    • Scan is #1
    • VEGAS is still not balancing, but hopefully Ray's new version fixes this
    • SB ended at 14:28
    • Artifacts are not clearly present, but the LED is on, so there do seem to be overflows. But vegas.scale was too high (vegas.scale=40), so maybe that caused issues? Trying again with vegas.scale set to 2.25
    • SB submitted at 14:33
    • Scan is #2
    • SB ended at 14:35
    • Artifacts are present. Hmm.
  • Taking a scan with fftshift=0xffffffff, cranking vegas.scale up to 100.
    • Doing VEGAS system stop/start
    • Using 00-CoherentModeArtifactTesting scheduling block with new vegas.scale
    • SB submitted at 14:42
    • Running successfully this time
    • Scan is #3
    • SB ended at 14:45
    • Levels seem OK. Artifacts are not present but some sub-integrations seem to have
  • Taking a scan with fftshift=0xffffffff in coherent search mode
    • Using 00-CoherentModeArtifactTesting scheduling block in coherent search mode
    • SB submitted at 14:51
    • Scan is #4
    • SB ended at 14:53
    • Will need to process separately.
  • Taking another scan with same set up, but in coherent cal mode with shorter dump times. Increasing vegas.scale slightly to 120.
    • Using 00-CoherentModeArtifactTesting scheduling block with 1 s dump times, 20 s scan.
    • SB submitted at 14:56
    • Scan is #5
    • SB ended at 14:57
    • Levels look OK. No artifacts or oddities in the cal. There is a ripple in the cal profile but it is present identically in GUPPI.
  • Going to set fftshift=0xffffffff for all coherent pulsar modes and play around with vegas.scale to try and get acceptable levels. Seems like the best way forward if the data look OK.
    • Edited vegas.conf and did system stop/start
    • Using AcceptanceTestingCoDD Prep scheduling block. vegas.scale values are 125, 150, 125, 275, 100, 300, 100 for 64, 128, 256, 512, 1024, 2048, 4096 channels.
    • SB submitted at 15:24
    • First scan is #6, last scan is #13
    • Balancing worked with 64 channels. Interesting.
    • Looks like no data was taken on Bank G for 64 channel mode.
    • Levels way too high for 128, 256, 512, 1024, 2048, 4096 channel mode.
    • Got psrfits error when combining data from scan #9: Pulsar::ProfileColumn::load_amps data NaN in row=1. Actual data seem OK at first.
    • Same error as above for scan #10. Data still look OK.
    • Whoa whoa whoa whoa. I was accidentally taking 4 scans in each mode. Fixing that and starting over.
    • Trying some different scale values.
    • New starting scan is #14, last scan is #20
    • Levels are a little low for 64 channel mode using vegas.scale=20.
    • Levels are also a little low for 128 channel mode using vegas.scale=35
    • Levels are maybe a little low, but acceptable for 256 channel mode using vegas.scale=70.
    • Levels are OK for 512 channel mode with vegas.scale=125. Could be a little lower.
    • Levels are a little low for 1024 channel mode with vegas.scale=100
    • Levels are too high for 2048 channel mode with vegas.scale=300
    • Levels are too low for 4096 channel mode with vegas.scale=100
  • Going to do the same as above with different vegas.scale values and 30 second scans.
    • Using AcceptanceTestingCoDD Prep scheduling block. vegas.scale values are 40, 70, 80, 110, 125, 150, 200 for 64, 128, 256, 512, 1024, 2048, 4096 channels.
    • SB submitted at 15:58
    • First scan is #21, last scan is #27
    • Levels in 64 channel mode look good.
    • Levels are a little high for 128 channel mode with vegas.scale=70. Maybe try around 50 next time.
    • Looks like an MMCM calibration issue with 256 channel mode....data maybe look OK though??
    • Levels look good for 512 channel mode.
    • Abort error on Bank B during 1024 channel scan. Pushed through anyway but no data. This would have been scan #25
    • Levels look OK for 2048 channel mode.
    • Levels look OK for 4096 channel mode.
    • SB ended at 16:08
  • Done for today. Switching back to release branch at 16:08. Ran into some problems, Ray had to intervene.
  • Taking verification scan in spectral line mode
    • Using CheckMode1 scheduling block
    • SB submitted at 16:31
    • Scan is #28 (duplicate with a pulsar scan, probably because of that last abort message)
    • Data look OK
Session ended at 16:32

Conclusions

I think we are going to go ahead with fftshift set to 0xffffffff. We seem to have some good vegas.scale values for the coherent 800 MHz modes.

-- RyanLynch - 2017-02-28

This topic: CICADA > WebHome > GreenBankSpectrometer > CICADAGreenBankSpectrometerCommissioningLogs > CICADAGreenBankSpectrometer2017Feb28
Topic revision: 2017-02-28, RyanLynch
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