Horst Meyerdierks, at Edinburgh, has now made an interim release to Starlink of SPECX V6.4 (for Unix). This version has no support for GSD files (as produced by the JCMT), and, as the Starlink beta-testers have found, requires a certain amount of jiggery-pokery to translate map files produced on VMS machines. An even more recent version produced at Cambridge does provide support for GSD files (using Remo Tilanus' C-interface to GSD), as well as fixing a few of the bugs produced in the port. Discussions are now under way on the best way to make VMS-style maps directly available, and the next Unix release has been delayed until this issue is resolved satisfactorily. It is still possible that this fully-functional release will leapfrog the one currently in the pipeline. My thanks to Horst Meyerdierks for all his hard work on the Unix port.

The Unix version has now been ported back to OpenVMS V6.1, and is running on an Alpha at MRAO. VMS Specx V6.4 retains the full functionality of V6.3. At the next release (V7?) we hope to bring all three versions - Unix, VAX/VMS and Alpha/VMS - into line, and possibly to include support for NDF files in the VMS versions. Meanwhile, Starlink are providing the interim release in time for the deadline of 1 December 1994, when all Starlink VAXs are to be turned off. Because of this deadline, and the differences between the various flavours of Unix, there will be no support in this version for last-line editing, or for CTRL(C) trapping. It is possible that these will be reinstated in a subsequent release.

Unix SPECX includes calls to many Starlink libraries. Distribution to non-Starlink sites will therefore not be entirely straightforward, and details still have to be resolved with the Starlink management. Starlink should be able to supply either `built' versions, including binaries, for particular machines, or alternatively to supply the full source and makefiles for both Specx and the relevant libraries. Conversely, given that Starlink is no longer going to support VMS-based software, we will probably arrange for the VAX and Alpha versions to be available via anonymous ftp from MRAO.

MERGE and CONCAT

Several people have been observing very wide lines (in distant radiogalaxies for example) by taking two or more spectra with different centre frequencies, and then trying to knit them together into a single spectrum using CONCAT followed by MERGE. The results tend to be variable, and depend on exactly how you achieve the different observing frequencies. One superficially attractive way to do it, which will not work, is to change just the nominal vlsr of the source.

The basic problem is that the SPECX header only stores one set of velocity information (all velocities are for the start time of the observation). That is:

* vte: velocity of telescope wrt earth.

* ves: velocity of earth wrt sun.

* vsl: velocity of sun wrt lsr.

* vlsr: velocity of lsr wrt source.

If your data have different values of VLSR in the two spectra (and slightly different values of vte, ves and vsl), then when you CONCAT, you lose one set. The spectrum that loses its header is no longer properly calibrated in frequency. SPECX - or at least the MERGE routine - takes its cue from the value of F_CEN, and since this is corrected to the source frame it is (almost) the same for both spectra. So once you throw away VLSR it looks as though the spectra have almost the same centre frequencies: MERGE then sorts them according to the very small residual difference.

There is a reason for MERGE working this way. It was originally conceived as a way of putting together spectra taken at the same time, for which the routine would necessarily work correctly by comparing true frequencies (i.e. in the telluric frame). For this particular case you have exactly the same telluric (i.e. i.f.) frequencies, and MERGE knows that.

Now, since a NEW-PLOT of the concatenated spectrum does come out right, you can see that the information is still available (these days): it is obtained from a combination of if_freq, lo_freq and rest_freq, all of which are stored on a per-quadrant basis. So in principle we should be able to use these to decide how to do the MERGE. But there is a fundamental problem in that now MERGE (in reducing many quadrants to one) will instead be throwing away other information, such as the LO frequency. Different bits of the spectrum will then still be incorrectly described by the header. The apparently straightforward MERGE process necessarily produces a spectrum which is now calibrated for only one frame, and any attempt to display it in another frame leads to an erroneous frequency scale.

I have therefore disabled CONCAT for spectra which have different VLSRs. One way to get around this is illustrated in the SPECX macro concat.spx, which is available by anonymous ftp from mraos.ra.phy.cam.ac.uk, in directory /pub/rachael. This works pretty well as long as the spectra being concatenated and merged were taken relatively close together in time, and could be a basis for something more sophisticated if you so desired.

Remember that as long as you don't MERGE, the display should be OK, since you have enough frequency information in the quadrant headers to override the velocity information. But if you do decide to merge the two spectra, then caveat emptor.

Rachael Padman, MRAO Cambridge

rachael@mrao.cam.ac.uk