PSRCHIVE 8.1 file-format specific release notes
Main PSRCHIVE
page
Version 8 release notes
For all new data types (ASP, WAPP, BPP):
- PSRCHIVE only reads these formats, it doesn't write
them. For any operations that modify the files, it's best
to convert to psrfits (which is read/write) first, using
either the "pam" or "psrconv" programs.
- In principle all this code works on both big-endian
(Sun, etc) and little-endian (Intel, etc) machines.
However, I've only been developing and testing on Linux/PCs.
If any of you still use Suns regularly, I'd be interested to
hear how/if it works for you!
- To get started, try "pav -GTp data_file_name" on some
data you have handy. You should get a plot of intensity
versus phase and freq.
For WAPP data:
- WAPP header versions 2 through 9 are handled, however
I've only had access to ver 8 and 9 data to test. Arun is
supposed to be digging some older data off tape for me, but
if any of you have old data available, try it and let me
know of any problems.
- PSRCHIVE converts WAPP ACFs ("lags") to spectra using a
slightly different method than Sigproc and Presto (DCT-III
rather than a real-to-complex FFT). This results in correct
channel frequencies, with no half-channel offset. See this
for a detailed description of the issue.
- The quantized power (aka Van Vleck) correction is not
fully working for either 9-level or full-Stokes WAPP modes.
Does anyone actually use these modes?
- WAPP files typically don't have a filename extension
(for example "p2178.B1937+21.wapp1.54135.0006"). Some
PSRCHIVE data-conversion programs will try to change the
extension and end up removing the scan number (0006 in the
example) in the process. I recommend adding a ".wapp" to
WAPP filenames before messing with them.
For BPP data:
- There is still some remaining work to fully implement
the infamous "midscan correction." So don't expect
super-precise timing results from BPP files yet. I'm
working on fixing this.
- The new PSRCHIVE code uses a different (in my opinion
more correct) 2-bit quantized power correction than the
older Berkeley "ctoa" code. This applies to all observing
modes, but especially affects polarization cross-terms.
Anyone interested in details should contact me.
For ASP data:
- There are no issues. ASP is perfect in every way ;)