<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>Dear all,</div>
<div><br>
</div>
<div>Recently we made a number of small changes to the PSRFITS files being written by the Parkes PDFB systems. Most of changes are small and have no major impact, but one does have implications for PSRCHIVE processing, especially scripts. This change was to
CTR_FREQ in the HISTORY table. Previously it was set to be the same as OBSFREQ in the main header, but the PSRFITS standard (http://www.atnf.csiro.au/research/pulsar/index.html?n=PsrfitsDocumentation.Txt) defines it to be the weighted centre frequency for
the observation and it is now set to this value. (This differs from OBSFREQ since the PDFBs do not write Channel 0.)</div>
<div><br>
</div>
<div>Currently the PSRCHIVE Archive::get_centre_frequency command reads from the last line of CTR_FREQ in the HISTORY table. This is the value given by "vap -c freq" and "freq" in PSREDIT and commonly used in scripts etc. It is also used by PAC to decide if
obs and cal files match. Since this value will now change with frequency channel zapping etc, there will be problems. </div>
<div><br>
</div>
<div>It is worth mentioning that OBSFREQ was only defined in Feb 2007 to make PSRFITS more VO compatible (V2.8). Similarly, OBSBW and OBSNCHAN were defined in Feb 2008 (V3.2). These parameters are in the main header and should never change. (A exception may
be when multi-band observations, say with a UWB receiver, are stitched together, but we'll cross that bridge when we come to it.) For observations before these dates, the HISTORY table values were used, which is why PSRCHIVE was written in this way.</div>
<div><br>
</div>
<div>We propose that Archive::get_centre_frequency be changed to read from OBS_FREQ in the main header. This should avoid all problems with frequency matching and will work for both old and new files. </div>
<div><br>
</div>
<div>We also plan to change PAZ so that it writes the weighted centre frequency (summed across all channels and subints) into CTR_FREQ in the HISTORY table. Note also that programs which convert to PSRFITS from other formats should also calculate this weighted
centre frequency and place it in CTR_FREQ. </div>
<div><br>
</div>
<div>Note that PAT and similar programs use the weighted centre frequencies from the DAT_FREQ array in the SUBINT table as reference frequencies. This is as it should be. </div>
<div><br>
</div>
<div>It would be useful to have a "wtctrfreq" available in PSRCHIVE and a command in VAP to print this out. Evidently this was implemented in 2010 by Jonathan Khoo but it has since been lost. </div>
<div><br>
</div>
<div>Please send any comments on this asap. We propose to implement the change as a branch in the sourceforge git repository and implement it at CASS in the next few days, but will not commit it to the mainline version before September 15 in case issues turn
up. </div>
<div><br>
</div>
<div>Regards</div>
<div> Dick and Matthew K.</div>
</div>
<div><br>
</div>
</body>
</html>