PSRCHIVE 8.1 file format-specific release notes
PSRCHIVE 8.1 added support for several new file formats. Here is
a list of known issues with each of these.
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 first, using either the "pam" or
- In principle the new code works on both big-endian
(Sun, etc) and little-endian (Intel, etc) machines.
However, development and testing has been done mainly on
Linux/PCs. If anyone experiences problems that may be
related to this, please report them!
For WAPP data:
- Folded WAPP file versions 2 through 9 are handled,
however only versions 8 and 9 have been tested. If anyone
runs into any problems with old versions, please let Paul
- 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. It's best to add 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. This is
on the list of things to fix.
- The new PSRCHIVE code uses a different (hopefully 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 Paul.