Scott Ransom

Thanks for the efforts, Paul and Willem! So with the new changes, the fluxcal gets written. But I'm seeing that it still has FITS errors and pacv doesn't like it for plotting. Here is what pacv says: Graphics device/type (? to see list, default /NULL): /xwin pacv: vegas_59705_19470_B1442+101_0001_cal_0001.zap.fluxcal is a processed Calibrator pacv: constructing FluxCalibrator from Extension pacv: Plotting FluxCalibrator Pulsar::CalibratorPlotter::plot no points to plot Type <RETURN> for next page:...

Hi Willem: You can grab two on/off cal files that show this behavior from here: https://www.cv.nrao.edu/~sransom/vegas_59705_19470_B1442+101_0001_cal_0001.zap.cf https://www.cv.nrao.edu/~sransom/vegas_59705_19608_B1442+101_0002_cal_0001.zap.cf Note that those only 1024 channels, but they are still showing the problems with the flux_cal columns. Scott

erroneous FLUX_CAL table creation

bump Ryan Lynch and I are now seeing this exact same issue at Green Bank while testing merging of VEGAS files across frequency (for the new UltraWideband receiver)....

And nope. With the fscrunching, it is even more messed up and definitely not correct. S On 4/5/22 3:38 PM, Scott Ransom wrote: I'm not sure what should be expected, but I /think/ so? It seems like the data now has a DM of 0.0. However, there is a bunch of junk at the beginning of the output file (like the buffer had garbage in it, or all zeros). Maybe things /are/ working with fscrunch and -K and I was just expecting something different. For the subbanding that psrfits_subband does, the resulting...

I'm not sure what should be expected, but I think so? It seems like the data now has a DM of 0.0. However, there is a bunch of junk at the beginning of the output file (like the buffer had garbage in it, or all zeros). Maybe things are working with fscrunch and -K and I was just expecting something different. For the subbanding that psrfits_subband does, the resulting file acts like a coherently dedispersed .fil file with bigger channels. In other words, the subbands have not had their center-freq...

Hi Paul, It seems to run, but the resulting file is definitely not dedispersed properly (and, in fact, seems to have extra artifacts etc). My command lines were like: digifil -D 71.02 -K -f 8 -o out.fil input.fil Scott On 4/5/22 1:38 PM, Paul Demorest wrote: Hi Scott, from a quick look at the code I think dedispersion (-K option) should be applied before fscrunch (-f) if both options are used. I guess that is not what you are seeing? [bugs:#98] https://sourceforge.net/p/dspsr/bugs/98/ digifil not...

digifil not able to remove interchannel dispersion when fscrunching?