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?
Hey Paul, Yeah, I used the "update" command in the top level directory which does that automatically. So I don't think that is the issue. (and I re-did "bootstrap" and the "config", of course")
compile error in ComplexRVMFit.C with new Ubuntu
And note that using Patrick's crazy diff (i.e. adding another NMF1 to the end of the declaration where it already exists!) lets the file compile. I have no idea why that is.
I just ran into this as well. I'm using Ubuntu 21.10, and so my gfortran is really new (v 11.2.0). I think that might have something to do with it.
Cannot update ephemeris