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