Fill and Sign the Synthesis Trans Bis Glycinato Copper Form

Atacama Pathfinder EXperiment APEX-IFD-MPI0002 Revision: 1.2 April 10, 2003 Interface Description Jennifer Hatchell Multi-Beam FITS Raw Data Format Interface Description Jennifer Hatchell and Dirk Muders hatchell, dmuders@mpifr-bonn.mpg.de The MBFITS working group: Robert Lucas lucas@iram.fr Helmut Wiesemeyer wiesemey@iram.fr Albrecht Sievers sievers@iram.es Frederic Gueth gueth@iram.fr Dirk Muders dmuders@mpifr-bonn.mpg.de Keywords: Data Format, FITS, APEX Author Signature: Jennifer Hatchell Date: April 10, 2003 Approved by: NN Signature: Institute: MPIfR Date: Released by: Signature: Institute: Date: APEX Multi-Beam FITS Raw Data Format Contents 1 Introduction 1.1 MBFITS and ALMA-TI FITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Scans, observations and integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 5 2 What’s new in v.1.2? 7 3 Explanatory notes 3.1 Scanning/mapping description . . . . . . . . . . . . . . . . . . . . . . 3.2 Phase description for switched observations. . . . . . . . . . . . . . . 3.3 Calibration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Continuum calibration . . . . . . . . . . . . . . . . . . . . . 3.3.2 Spectral line calibration . . . . . . . . . . . . . . . . . . . . 3.4 DATE-OBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 WCS coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Sources of spatial coordinate information . . . . . . . . . . . 3.5.2 WCS representation and telescope control system input . . . 3.5.3 WCS coordinate systems . . . . . . . . . . . . . . . . . . . 3.5.4 30m parameters . . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 WCS parameters (including derivation from 30m parameters) 3.5.6 Moving bodies . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.7 Observations in Az/El, On-the-fly mapping in Az/El . . . . . 3.5.8 Pointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.9 WCS spectral coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 References 9 9 10 11 11 12 13 13 13 14 15 16 16 19 19 20 21 21 5 MBFITS specification 5.0.10 Data types . . . . . . . . . . . . . . . . . . . . . . 5.1 The Primary header . . . . . . . . . . . . . . . . . . . . . . 5.2 The SCAN-MBFITS Binary Table . . . . . . . . . . . . . . . . 5.2.1 SCAN-MBFITS Binary Table Header Keywords . . . 5.2.2 SCAN-MBFITS Binary Table Columns . . . . . . . 5.3 The FEBEPAR-MBFITS Binary Table . . . . . . . . . . . . . . 5.3.1 FEBEPAR-MBFITS Binary Table Header Keywords . 5.3.2 FEBEPAR-MBFITS Binary Table Columns . . . . . 5.4 The ARRAYDATA-MBFITS Binary Table . . . . . . . . . . . . 5.4.1 ARRAYDATA-MBFITS Binary Table Header Keywords 5.4.2 ARRAYDATA-MBFITS Binary Table Columns . . . . . 5.5 The MONITOR-MBFITS Binary Table . . . . . . . . . . . . . . 5.5.1 MONITOR-MBFITS Table Header Keywords . . . . . 5.5.2 MONITOR-MBFITS Binary Table Columns . . . . . . 5.5.3 Anticipated monitor points . . . . . . . . . . . . . 5.6 The DATAPAR-MBFITS Binary Table . . . . . . . . . . . . . . 5.6.1 DATAPAR-MBFITS Binary Table Header Keywords . 5.6.2 DATAPAR-MBFITS Binary Table Columns . . . . . . . . . . . . . . . . . . . . . . . Create Date: April 10, 2003 Contact author: Jennifer Hatchell Page 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 22 23 23 26 27 27 28 30 30 31 32 33 33 33 36 36 37 APEX Multi-Beam FITS Raw Data Format Abstract This document describes a FITS raw data format for multibeam multireceiver/backend single dish telescopes. It is intended for use at the IRAM 30-m and APEX. Create Date: April 10, 2003 Page 3 Contact author: Jennifer Hatchell Multi-Beam FITS Raw Data Format APEX Observ i ng setup ARRAYDATA MB FITS bl ock di agram v.1.2 FEBE FEBE 1 FEBE 2 PRIMARY HEADER SCAN MONITOR head er table DATAPAR FEBE 1 FEBE 2 head er table rows per integration ARRAYDATA and DATAPAR entries are matched by INTEGNUM and MJD Contact author: Jennifer Hatchell Page 4 Create Date: April 10, 2003 Data associated ... FEBE 1 FEBE 2 ... parameters DATAPAR table 2 basebands FEBE 2 ... R aw moni tor data MONITOR table 3 basebands FEBE 1 R aw backend data 2 basebands FEBE 2 ... Header ... 3 basebands FEBE 1 ... 1 ... 2 ARRAYDATA table File Scan Ob servation Integrations (for each observation) Figure 1: MBFITS file structure APEX 1 Multi-Beam FITS Raw Data Format Introduction 1.1 MBFITS and ALMA-TI FITS The MBFITS working group was created at the array receiver meeting at IRAM Grenoble in December 2001. The goal was to define a new raw data format for multibeam receivers based on FITS to be used at the IRAM 30m and APEX telescopes. With a common raw data format it is much easier to share software developments in the areas of data calibration (chopper wheel, atmospheric, etc.) and data reduction. The resulting MBFITS format can be used for all single-dish bolometer and heterodyne observations including multiple frontend/backend combinations and array receivers. The MBFITS format was derived structurally from the ALMA-TI FITS raw data format, although a number of changes had to be made to accomodate the special needs of the IRAM and APEX telescopes. We would like to thank especially Robert Lucas, who is one of the authors of the ALMA-TI format, for his valuable contributions to our discussions. The MBFITS format is based on the scan-observation-integration scheme used by ALMA-TI FITS and retains many of its keywords. However, due to the changes in structure and additional keywords needed to accommodate single-dish configurations, particularly multiple beam observing and multiple frontend/backend combinations, the MBFITS format can now be considered to be an independent format. In Sect. 2 we outline the updates in the latest version of MBFITS. In Sect. 3, various aspects of MBFITS are described in detail. Then follows the specification of the FITS tables (Sect. 5. Finally, we include references (Sect.4). 1.2 Scans, observations and integrations Extracted from the ALMA Software Glossary (via ALMA-TI FITS definition, Lucas & Glendenning 2001): dump The smallest interval of time for which a set of correlated data can be accumulated and output from the correlator. integration A set of dumps, all identical in configuration (except for the antenna motion and some others), that is accumulated and forms the basic recorded unit. observation A set of integrations while the antennas complete an elemental pattern across the source, possibly while frequency switching, nutator switching, etc. scan A set of observations with a common goal, for example, a pointing scan, a focus scan, or an atmospheric amplitude calibration scan, or a correlation scan on a continuum source or a line source. For instance in the case of holography measurements an observation would be a drift across the transmitter or a bore-sight measurement, while a scan could be the whole set of observations needed to acquire a beam map. Or a scan could be a pointing scan with two observations (an azimuth drift and an elevation drift across the pointing calibrator) or an atmospheric calibration scan with three observations (autocorrelations on the sky, and two loads at different temperatures, ...). A scan can be as simple as a short integration on a celestial source while total power and/or correlator output are recorded; or it could be a set of pointed observations that are used together to form a map of an extended celestial source. Here are some examples of how this scheme works for single dish observing. More examples of a scan: – An on-the-fly map of an astronomical source, including associated sky off observations – A raster map . . . – A pointing scan (cross-raster or cross-OTF – A focus scan Create Date: April 10, 2003 Page 5 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format – A skydip – A flux calibration measurement – Five on-source measurements forming a cross and a sky off position – A holography measurement . . . and an observation: – A line of an OTF map – One sample in a raster – A sample on a sky off position – A heterodyne calibration (HOT/COLD/SKY) – One step in a focus scan Create Date: April 10, 2003 Page 6 Contact author: Jennifer Hatchell APEX 2 Multi-Beam FITS Raw Data Format What’s new in v.1.2? Keywords which are new, moved or altered in v.1.2 are given in bold in the tables. 1. The INTMON tables have been merged into DATAPAR. There is now only one additional table, DATAPAR, associated with each ARRAYDATA data table. What previously were INTMON and DATAPAR have been combined. Originally, the two were separated because the information in DATAPAR can be written directly at the time of an integration, whereas the INTMON values are interpolated/calculated from information in MONITOR which is not available until the end of an observation. By buffering the DATAPAR entries until the end of the observation, when the MONITOR values are available, all the data-associated parameters can be written together, saving on duplication in table and header. This change forces the positions etc. which were previously in INTMON to be written in quasi-real-time rather than filled in later offline, but it has become clear that this is necessary anyway to maintain an uninterrupted data flow at the telescope. 2. Variable length arrays in MONITOR The MONITOR array, which stores real-time data at its natural rate, was limited by its format to storing single floating-point values. This is hugely restrictive when one wants to store eg. 5 structural temperatures, a spectral line gain array, or total power measurements for 3 frequency bands. We have changed MONITOR to store variable length arrays instead of single floating point values. This would introduce additional overheads if the majority of entries were still single floating point values. This is not the case as most entries group naturally into small arrays eg. 2 encoder readings, 2 temperatures and 3 powers from a calibration. We store one time, description and units for each array. Thus by changing to variable length arrays in fact we reduce the storage overheads. Variable length arrays in FITS are described in [9] Cotton, Tody & Pence 1995 Appendix A. The IAU FITS group has not yet voted to include this as part of the FITS standard though it is likely that it eventually will. The North American regional FITS group has accepted it and it is already in use in many FITS formats. It is supported by many FITS packages including CFITSIO and FitsView. The storage works like this: in the fourth column of MONITOR a pointer to the variable length data array is stored. The data are stored at the end of the table. See [9] for details. With variable length arrays, almost anything can be stored in MONITOR. This gives MBFITS the flexibility to cope with future unforeseen requirements without making changes to the existing table structure. 3. Calibration A close look has been taken at what’s required in order to calibrate the data and where this should be stored; see 3.3 below. 4. Scanning/mapping description Keywords which describe scanning/mapping keywords have been updated following a work-through of examples. See 3.1. 5. Phase coding We have looked description of multiphase (switching) observations and describe schemes for some common cases in 3.2. 6. Data blocking Data blocking is now possible ie. several rows in the ARRAYDATA table can now be written for one set of DATAPAR. This is controlled by DPBLOCK (DATAPAR header), a flag set to true if blocking, and NINTS(DATAPAR table) which stores how many ARRAYDATA entries correspond to the DATAPAR entry. Create Date: April 10, 2003 Page 7 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format When blocking, all DATAPAR values refer to the first integration of the block. An integration for which no direct entry in DATAPAR exists should take ISWITCH from the previous entry and interpolate between times and angles from bracketing entries. If blocking, a DATAPAR entry should always be written for the first and last integration of each observation. 7. Holography The HOLODATA table has been removed. Holography data is now stored as any other data in ARRAYDATA. If SCANTYPE=HOLO, special holography keywords TRANDIST (transmitter distance), TRANFREQ (transmitter frequency) and TRANFOCU (transmitter offset from prime focus) are stored in the SCAN header. 8. Keyword compatibility: dashes and underscores, and SDFITS Unnecessary dashes and underscores in keywords have been purged. An exception is the unavoidable FITS keyword DATE-OBS. Underscores are used for clarity in the MONITOR point descriptions: these are not FITS keywords. Keyword clashes with SDFITS (Single Dish FITS) have been resolved and a couple of keywords added: – OBSID stores the observer’s and operator’s initials (scan header); – OBS-LONG, OBS-LAT and OBS-ELEV are now SITELONG, SITELAT, SITEELEV (scan header); – MOLECULE and TRANSITI (optionally) together contain the molecule and transition for the main spectral line 9. MJD is used more widely than DATE-OBS to mark the integrations. FITS readers such as fitsview need a numerical (rather than text-format) timestamp to display sequential data. See 3.4 below. 10. Other keyword additions and alterations Keywords which have been altered (new, name changed, or moved) are marked in bold. Includes: – FRQTHROW in the FEBE header gives the frequency step for frequency switched observations. – DEWRTMOD (FEBE) is one of CABIN = dewar rotation fixed in Nasmyth/Cassegrain system, EQUA: RA/DEC; or HORIZ: AZ/EL. DEWANG (FEBE) is measured counterclockwise (anticlockwise) from vertical in the DEWRTMOD system in which the dewar rotation is fixed. Therefore DEWANG is also fixed throughout a scan. The feed offsets FEEDOFFX, FEEDOFFY (FEBE table) are measured in degrees in the system in which the dewar rotation remains fixed. Create Date: April 10, 2003 Page 8 Contact author: Jennifer Hatchell APEX 3 Multi-Beam FITS Raw Data Format Explanatory notes In this section we describe how various aspects of data storage are handled in MBFITS. In particular, these explanatory notes show where to find the keywords/table columns associated with one theme (eg. positions, mapping parameters), as these can be scattered across the tables. Explanation of individual keywords and small keyword groups can be found in the introductions to the individual tables and as comments in the table descriptions. (sections 5.2–5.6). 3.1 Scanning/mapping description The movements which the observer intended the telescope to carry out during a scan are stored in the following scanning parameters, so that the mapping scheme can be envisaged by the recipient of the data/ deduced by the data reduction software. Note that the scanning parameters are not needed for the data reduction, which requires only the absolute positions of the current optical axis(LONGOFF, LATOFF) and information on whether an integration is part of the scan or off-scan (stored in ISWITCH in the DATAPAR table). Thus the scan parameters are optional. From a quick map of the observed positions, the scan geometry can be reconstructed. The data reduction software should not calculate positions based on this description but instead rely on the actual observed positions given in DATAPAR. At the highest level, SCANTYPE shows the type of astronomical observation: POINT, FOCUS, CAL, SKYDIP, HOLO, OTF, ONOFF, PSW, RASTER, CROSS, FLUXCAL, etc. Then two parameters define how the telescope moves during the scan: SCANMODE and SCANGEOM. SCANMODE describes the mapping mode (SAMPLE, RASTER, OTF) and SCANGEOM the geometry (LINE, CROSS, CIRC, ARC etc.). Then follow a number of scan keywords (lengths, directions etc.). Which of these are needed depends on the type of SCANMODE: SCANMODE SAMPLE RASTER OTF keywords required SCANRPTS SCANLINE, SCAPTS, SCANXSPC, SCANYSPC, SCANLEN, SCANDIR, ZIGZAG, CROCYCLE SCANLINE, SCANRPTS, SCANXVEL or SCANTIME, SCANYSPC, SCANLEN, SCANDIR, ZIGZAG, CROCYCLE The keywords are: Create Date: April 10, 2003 Page 9 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format SCANDIR SCANLINE SCANRPTS SCANLEN SCANXVEL SCANTIME SCANXSPC SCANYSPC SCANSKEW SCANPAR1 SCANPAR2 CROCYCLE ZIGZAG (optional) scan direction, described as: USER (user native frame) or xLON/xLAT as in CTYPEj (standard basis system), including ALON/ALAT for Az or El scanning. (optional) number of lines in a scan. Default 1. (optional) number of repeats of each scan line. Default 1. (optional, OTF/RASTER) For OTF, the line length or turn angle (SCANGEOM=CIRCLE) in Deg; for RASTER, the number of samples in a line. (optional, OTF) tracking rate along line (units depend on SCANMODE definition) (optional, OTF) time for one line (optional, RASTER) step along line between samples (optional, OTF/RASTER) step between scan/raster lines (optional, OTF/RASTER) offset in scan direction between lines (optional) spare scan parameter (for modes I haven’t thought of) (optional) another spare scan parameter CAL/REF/ON loop string showing how often to go to CAL and REF. eg. CROOCOO is a REF every four ONs and CAL every two ONs. See 30m NCS documentation. CAL/REF/ON are stored in OBSMODE per observation. (optional, OTF/RASTER) TRUE if alternate lines traced in opposite directions, FALSE if all lines traced in same direction Most standard types of map can be coded in the SCAN header using these keywords. A few unusual types require one or more parameters to change during the scan, between observations. In this case, the parameters which change are taken out of the SCAN header and appear in the DATAPAR header. Jenny Hatchell has examples of how to code standard scans (on-off, fivepoint, rectangular raster map etc. ) using these parameters. 3.2 Phase description for switched observations. Switched observations include wobbler switching, frequency switching, 2-horn beam switch, load switching, and calibration observations. Which of these modes is active for each frontend is determined by SWTCHMOD (FEBE), apart from wobbler switching which applies to all receivers and is flagged by WOBUSED (SCAN). SWTCHMOD can take the values: TOTP FSW BEAMSW HORNSW LOADSW CAL total power frequency switch beam switch (as 30m) horn switch switch between source and load calibration cycle Wobbler switching is controlled by 5 parameters in the SCAN header: WOBUSED, WOBTHROW, WOBDIR, WOBCYCLE and WOBMODE. WOBUSED WOBTHROW WOBDIR WOBCYCLE WOBMODE True if wobbler in use wobbler throw in deg. wobbler throw direction - described as USER (user native frame) or xLAT or xLON, inc. ALON or ALAT for Az or El scanning wobbler period in seconds wobbler mode (SQUARE/TRIANGULAR). Triangular switching is wobbling in a direction perpendicular to the scan direction, during OTF mapping. Create Date: April 10, 2003 Page 10 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format The wobbler movements can be deduced from plotting the positions of each integration (eg. LATOFF and LONGOFF in DATAPAR). Frequency switching: FRQTHROW (FEBE header) gives the frequency step for frequency switched observations. LOFREQ (MONITOR) gives the LO frequencies from the frontend, one of which switches when frequency switching. Phases for switched observations are stored with each integration in ISWITCH (DATAPAR). Some common examples are: Type of switching frequency switching wobbler (nutating subreflector) 2 phases 4 phases (symm. switch) 2-horn beam switch 2 phases 4 phases (symm. switch) load switching 2 phases calibration 3 phases ISWITCH FHI/FLO ON/OFF LON/ROFF/LOFF/RON L/R LON/ROFF/LOFF/RON SKY/LOAD HOT/COLD/SKY Users of more complex switch cycles (eg. combined wobbler and frequency switching) can invent their own coding. The phase weighting has to be calculated from the total integration times in each phase (INTEGTIM in DATAPAR). 3.3 Calibration parameters A rough calibration of both spectral line and continuum data is carried out at the telescope. The derived calibration parameters are stored in the FEBE table (for parameters which don’t usually vary from scan to scan, but are measured occasionally) and in the MONITOR table. Although this at-the-telescope calibration is stored, a careful data reduction should go back to assess the quality of the original calibration data, average and interpolate between calibrations as necessary. Calibration parameters in the FEBE table which are not available at the time of writing should be left blank to be updated later. 3.3.1 Continuum calibration To calibrate a continuum observation the following are needed: opacity per feed(elevation-dependent); gain-elevation correction; counts-to-Jy calibration factor; feed offsets, HPBW of each feed, and beam shapes; and flatfield. This information is stored in MBFITS as follows. Ref: APEX-SRS-RUB-0002 (BOA Software Requirements). – Opacity correction The elevation-dependent opacity per feed per frequency band can be derived from the zenith opacity at each frequency. This comes from skydips, taumeter or bolometer total power measurements. In the case of bolometer total power and taumeter reports, the zenith opacity can be updated on an integration-by-integration basis. TAUZEN in MONITOR stores the zenith opacity. Bracketing taumeter readings from at least the beginning and end of each scan should be available so that the optical depth can be interpolated to each integration. If TAUZEN is determined from skydips, the value from the last skydip will have to be written at the telescope (but can be updated during further data reduction). Create Date: April 10, 2003 Page 11 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format – Gain-elevation correction ???? For homology telescopes (Effelsberg and the 30m) this can be simply parameterised but is empirically measured? What is the parameterisation for APEX? Should we store these parameters in MBFITS? – Calibration factor (counts-to-Jy) From comparison of observed/theoretical planet fluxes and secondary calibrators. At the telescope a standard value will be taken but during later data reduction, the planet observations should be taken into account. The standard value is stored in BOLCALFC (FEBE header) (previously BOLREFGN). Measured values from scans on flux calibrators are stored in the MONITOR point OBSFLUX CALFLUX CALFAC. – Array geometry Feed offsets and HPBW are determined occasionally from maps of strong sources and stored in FEEDOFFX, FEEDOFFY and HPBW (FEBE table, per observation) per frequency band. More information about the beam shapes is not stored. The array feed position and other calibration parameters in the FEBE table change with wobbler position. This is not taken into account at the moment. It may not be as simple as storing these parameters twice for two wobbler positions, as the wobbler displacement may be more complex than this (eg. 2-D, and data taken at intermediate positions). One possibility would be to parameterise the change in the calibration parameters with wobbler position. Calibration information at this level of detail is unlikely to be available for the raw data file and should be handled by the data reduction software. – Flatfield Array flatfield/ relative gains (measured occasionally) are stored in BOLFLAT (FEBE, per scan). 3.3.2 Spectral line calibration To calibrate a spectrum one requires: the Gain Array, the calibration temperature Tcal , and the beam efficiency. These quantities are derived from cal colds (comparison of cold load, hot load and sky) plus continual monitoring of ambient and chopper temperatures and occasionally measured telescope efficiencies. Alternatively, T sky and Tcal can be calculated more frequently via an atmospheric model which reads the opacity from a water vapour radiometer. ref: APEX-SRS-MPI-0000 (APEX spectral line software requirements) – Gain array The channel gains are determined by comparing hot load and sky during a cal cold. Cal colds are observations which can occur within one scan interspersing astronomical data collection. The gain array is stored per cal cold in the MONITOR table. – Calibration, receiver and system temperatures The calibration temperature TCAL for each frequency band is determined from cal colds or the atmospheric model, along with receiver (TRX), main band and image system (TSYS, TIMAG) temperatures. These temperatures are stored in TRX TSYS TIMAG TCAL ¡baseband¿ in the MONITOR table at the time of the cal cold. The basic measurements (THOT, TCOLD, PHOT, PCOLD, PSKY are also stored in MONITOR. – Image/signal sideband gain ratio GAINIMAG, which is also used in the calibration to derive TCAL, is measured occasionally by comparison with atmospheric models and stored in the FEBE table every scan. – Beam efficiency The main beam, aperture and forward efficiencies are measured occasionally on calibrators and are stored in the FEBE table for each feed and band. Create Date: April 10, 2003 Page 12 Contact author: Jennifer Hatchell APEX 3.4 Multi-Beam FITS Raw Data Format DATE-OBS The following description of DATE-OBS as used in MBFITS is adapted from Bunclark & Rots 1996. For more details on the DATE-OBS format see that reference. The new format is a restricted subset of ISO-8601: CCYY-MM-DDThh:mm:ss.ssss1 represents a calendar year, the ordinal number of a calendar month within the calendar year, and the ordinal number of a day within the calendar month. represents the hour in the day, the minutes, the seconds. The value of the integer part of the seconds field is normally in the range [0..59] but may take the value 60, if the time scale is UTC, to indicate a leap second. The literal ’T’ is the ISO 8601 time designator. There must be a ’T’ time designator between the date and the time. The decimal point character is an ASCII full-stop (hexadecimal value 0x2E). 1 APEX DATE-OBS requires the time field with a precision of 100µs or four decimal places in the ‘seconds’ field. 3.5 WCS coordinates The representation of spatial coordinates has undergone a major revision in v. 1.0. The aims of this are to take into account the latest version of the World Coordinate System (WCS), making clear the relationship between parameters in current use at the 30m and those stored in this format; and to clarify the sources of positional information written in the raw data. Spectral coordinates have also been updated to comply with WCS (see Sect. 3.5.9). 3.5.1 Sources of spatial coordinate information The spatial coordinate information stored in the raw data file has several origins: – Observer’s setup the user’s setup of spatial coordinate frame, wobbler and scanning setups. The observer’s setup is stored in the SCAN header (reference frames, source position, observing, switch and scan modes) and the DATAPAR header (scan direction). – Commanded coordinates User’s setup translated into commanded antenna and wobbler position at a given time. For the antenna drive the commanded coordinates must be translated into (Az,El). For later comparison with the real-time coordinates, the commanded coordinates including the wobbler offsets can also be calculated at this stage, in any appropriate frame (eg. RA/Dec, or the user’s native frame). In v.1.0 we store the commanded longitude and latitude offsets in the user’s chosen basis frame (defined by CTYPEj, eg. RA/Dec) in the DATAPAR table as (CBASLONG, CBASLAT) – Raw drive commanded and readout coordinates The commanded (Az,El) antenna position is translated into telescope drive commands via the pointing model: part of this is handled by the telescope control system and part by the antenna pointing computer (see Sect. 3.5.8). – Real coordinates The readout from the antenna drive is then back-translated by the pointing model into the real antenna Az/El at the time of observation. The telescope pointing can be affected by wind, tracking errors etc. and thus the readout positions will differ from the commanded coordinates. This pointing correction should be carried out at the telescope and once only (see Sect. 3.5.8). The real coordinates at a given time — the pointing-corrected antenna position in Az/El, plus the wobbler offsets – are stored in the MONITOR stream. Create Date: April 10, 2003 Page 13 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format – Derived coordinates From the real antenna coordinates in Az/El plus the wobbler offsets, various forms of the celestial coordinates associated with an integration can be derived. Example coordinate systems are a standard basis frame such as RA/Dec, or offsets with respect to source position in user native frame according to the current observing setup. In v.1.0 we store derived Az/El (AZIMUTH, ELEVATIO), offsets in the user’s native frame (LONGOFF, LATOFF), and longitude and latitude in the chosen basis frame(BASLONG, BASLAT) (which can be directly compared with the commanded coordinates CBASLONG, CBASLAT) in the INTMON table. 3.5.2 WCS representation and telescope control system input The World Coordinate System (WCS) (Greisen & Calabretta, Calabretta & Greisen, Greisen & Valdes 2002) is considered by the FITS committee as a soon-to-be standard. It is a general, flexible and powerful system for the representation of image coordinates, both spatial and spectral, notably including support for nonlinear coordinates (such as spatial projections and nonlinear spectrometers). The ALMATI-FITS format, and our MBFITS format, based their representation of coordinates on this format (following the ALMATI-FITS data-reduction-oriented storage scheme). However, WCS is an evolving format and has been updated since the ALMATI FITS format was designed (latest update considered here Apr 2002). At some stage in the data reduction process, there will almost certainly be the requirement to write images out as FITS. The current plans for NIFTI and for APEX envisage carrying out all the data reduction within FITS formats, starting with MBFITS, until finally FITS images are written. It makes sense to ensure at the raw data stage that all the necessary coordinate information is stored in suitable format to allow easy construction of WCS-format image headers. This does not mean storing a complete FITS-format image at the raw data stage. A data reduction program will be required to turn the raw data into a useful image (averaging integrations, subtracting off positions etc.). The same reduction software can compile the headers for the image, provided all the necessary information is made available. At the raw data stage, the only useful images that could be produced are uncalibrated maps of observed positions eg. for array o-t-f maps (note FITS images do not have to be gridded on rectangular pixels). Even a full description of the image axes does not comprise all the positional information: a small amount of additional description of how the observations were actually carried out is necessary for the calibration/data reduction process (as well as for the construction of the image headers). The 30m currently stores extra positional information by storing the inputs to the telescope control system, OBSINP (see OBSINP manual), as well as the fundamental real-time positions in the DAPs (Data Associated Parameters). The OBSINP inputs reflect all the current flexibility of the telescope control systems. The system is tailored to single-dish observing and encompasses the observing modes that are likely to be in use at APEX. However, APEX will have a different telescope control system with different input keywords, and may have different observing modes. There are plans to upgrade the 30m control system to the New Control System (NCS), which will be more flexible than the current system. MBFITS should be general enough to support all the modes available at the 30m (current and future) and APEX. MBFITS keywords need to be general enough to cover what is needed from the OBSINP input, the NCS, and the APEX TICS commands. The coordinate storage scheme used in MBFITS up until now has consisted of limited WCS-style keywords with added 30m-type parameters. But there has been duplication of information without it being clear which parameters are redundant, and the format has neither fully conformed with WCS-FITS nor provided for the full range of observing modes of the 30m system. Thus we undertake a revision in v.1.0, continuing with a scheme that is based on FITS WCS, but incorporates additional coordinate information where this is necessary for the data reduction or clarifies the observing procedure. MBFITS is (as it stands) a raw data and not an image format. The information needed to construct an image becomes available at different times during the observing from different sources (eg. TCS and telescope position monitors) and thus appears in various tables. We have left this information scattered about, but coded in a form such that it could be easily collected together to produce an image table. A Create Date: April 10, 2003 Page 14 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format y Array position ρ p2 LATOFF (x,y)=((LONGOFF,LATOFF)) Origin of user native frame p1 Object LONGOFF α (φ,θ)=(LONGOBJ,LATOBJ)) (x,y)=((φcosθ θ, θ) δ Projection of user native frame (φ,θ)=(0,0), (x,y)=(0,0) (α,δ)=(CRVAL1,CRVAL2) (p1,p2)=(CRPIX1,CRPIX2) si ba l ca mi o n tro As x e ram f s Figure 2: Coordinate relationships for single dish array observations in WCS scheme. next step is to write a definition for a separate image table, as a necessary step in the data reduction, but this is postponed until a later version. Clearly, it must be possible to derive the WCS image descriptions from the OBSINP parameters, or from the APEX control system, plus the real-time position information. Where the same information can be stored in more than one way, the WCS format is always given; additional parameters are given where the WCS parameters are derived in such a complex way from the observing setup that a reverse translation is non-trivial, and where information is added that is not stored in the WCS header. The derivations of WCS quantities from the 30m parameters are given below in Sect. 3.5.5, but first in Sect. 3.5.3 we give a brief description of the relevant aspects of WCS and in Sect. 3.5.4 list the 30m OBSINP parameters which currently control positioning at that telescope. 3.5.3 WCS coordinate systems In this section we describe the coordinate systems in WCS and their meanings for single-dish observing. For the details of representing spatial coordinates using WCS see Calabretta & Greisen 2002. Fig. 2 illustrates the coordinate systems – more explanation of the figure is given at the end of Sect. 3.5.5. The WCS specifies how to describe the celestial ‘world’ coordinate system – the coordinates in a Create Date: April 10, 2003 Page 15 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format standard astronomical basis frame – of an image given in pixel coordinates. It makes this translation using two intermediate coordinate systems: intermediate world coordinates, where angles are given in a spherical frame which is offset and rotated with respect to the basis frame, and intermediate pixel coordinates, the flat-plane projection of the intermediate world coordinates, which may be rotated with respect to the pixel axes. The translation between the (planar) intermediate pixel coordinates (x, y) and the (spherical) intermediate world coordinates (φ, θ) is a non-linear one which depends on the projection. Calabretta & Greisen 2002 give many projections: the usual one for single-dish radio astronomy is Sanson-Flamsteed (SFL). This is similar to the former FITS global sinusoidal ‘projection’ (GLS) (though this was necessarily a linear coordinate translation), and gives a translation between intermediate pixel coordinates (x, y) and intermediate world coordinates (φ, θ) of x = φ cos θ y = θ. (1) In terms of our needs, the intermediate world coordinates (φ, θ) correspond to longitude and latitude offsets in the user’s native coordinate frame - an arbitrary rotated frame appropriate to the observations. The pixel (p1, p2) to intermediate pixel (x, y) coordinate offset/rotation then allows for translation of pixel offsets into the user’s native system, in our case for array rotation and wobbler offsets. 3.5.4 30m parameters The main OBSINP parameters which currently control positioning at the 30m are given in Table 1. For details see the OBSINP manual. Keyword SBAS Table 1: OBSINP positioning parameters Description Basis system: if followed by D, D * or P then use SL0P, SB0P and SK0P additionally to define a user native frame Equinox (where necessary) SEQN In SBAS D: SL0P origin of user frame in basis system SB0P origin of user frame in basis system SK0P angle which user frame zero meridian makes with basis system meridian In SBAS D * or SBAS P: SL0P pole of user frame in basis system SB0P pole of user frame in basis system SK0P angle which user system zero meridian makes with basis meridan through pole SLAM Source longitude in basis system SBET Source latitude in basis system OLAM or OLAM* Long. offset from source in user frame OBET Lat. offset from source in user frame In addition, the 30m DAPs store the RA and Dec for each integration, and the longitude and latitude offsets LAM(t) and BET(t) if scanning. The on-the-fly scanning parameters also control position, but only affect the WCS description through the resulting LONGOFF and LATOFF. The scan parameters are covered by SCANxxxx in the SCAN header: see Sect. 3.1. 3.5.5 WCS parameters (including derivation from 30m parameters) The following list gives the keywords required in the WCS description. We also give the derivation from the 30m OBSINP+DAP, and what is now stored in MBFITS v.1.0. Create Date: April 10, 2003 Page 16 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format CTYPEj Define basis frame and projection: format is 4-3 with 4 characters for the basis and 3 for the projection, padded with dashes. The first four characters give one of the basis systems available in the FITS standard: RA/DEC, GLON/GLAT, ELON/ELAT, HLON/HLAT, or SLON/SLAT. (G for galactic, E for ecliptic, H for helioecliptic, S for supergalactic: see Calabretta & Greisen 2002). The usual projection for single dish radio astronomy is Sanson-Flamsteed, coded SFL, for which x = φ cos θ y=θ (2) where φ and θ are longitude and latitude in the user’s native spherical system, and (x,y) are latitude/longitude offsets. Other projections can be specified if required. We need two basis representations which are non-standard, to handle Az/El and moving body coordinates. WCS FITS allows for the possibility of coding your own basis system as xLON/xLAT, with definition of the system given in the additional keyword WCSNAME. We propose to use ALON/ALAT with WCSNAME ’Horizontal coordinates’ for Azimuth/Elevation. See Sect. 3.5.6 for a description of how MBFITS works in the case of moving bodies. CTYPEj are stored in the SCAN header. WCSNAME A description of the basis coordinate system, especially where it is non-standard. See CTYPEj (above). Stored in SCAN header. RADESYS Additional ecliptic/equatorial basis system definition eg. Greisen (2002) Table 1. FK4/FK5: see Calabretta Stored in SCAN header. EQUINOX Basis system equinox. Stored in SCAN header. A combination of CTYPE, WCSNAME, RADESYS and EQUINOX cover all the astronomical basis systems in the OBSINP scheme. PVj m Additional projection parameters – not needed for SFL, so we leave these out of MBFITS. pi Pixel coordinates if not a regular grid. Stored in the FEBE table, in the array offsets FEEDOFFX, FEEDOFFY PCi j Rotation/skew matrix to translate pixel coordinates to intermediate pixel coordinates (projection of user frame). For an integration where the array y axis makes an angle ρ with the native (user) frame θ axis, PC is the rotation matrix   cos ρ − sin ρ PC = . sin ρ cos ρ For single feed observations, PC is the identity matrix. The angle ρ is derived from the dewar angle, optical arrangement and elevation. PCi j are stored in INTMON, derived from the dewar angle DEWANG (MONITOR table). CRPIXi Pixel coordinates of the native frame origin. Note these are not the pixel coordinates of the source, which may not be at (0,0), and that they are measured in the pixel coordinate frame, which we take to be centred at the array centre and oriented along the array axes. Given the source position in the native frame (LONGOBJ, LATOBJ), plus lat./long. offsets to the array centre (which may include wobbler offsets), then the CRPIX are: Create Date: April 10, 2003 Page 17 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format  CRPIX1 CRPIX2   = −P C −1 LONGOBJ cos(LATOBJ) + LONGOFF SBET + LATOFF  where P C is the matrix to rotate the array pixel coordinates into the user native frame, given above, with PC −1 =  cos ρ − sin ρ sin ρ cos ρ  . The CRPIXi condense the source position and offsets in the user frame into one pair of coordinates. We therefore keep the source position in the user frame as LONGOBJ and LATOBJ (SCAN header), and the offsets from this position in LATOFF and LONGOFF (INTMON table). The CRPIXi are stored in INTMON. CDELTj Scale pixel coords to intermediate pixel coords. FITS requires all angles to be given in degrees. As long as FEEDOFFX and FEEDOFFY comply with this, the CDELT take their default values of 1 and can be left out. CRVALj Origin of native frame in basis coordinates Stored in SCAN header. In the SBAS D scheme, these are SL0P and SB0P. LONPOLE Longitude of native pole in basis coordinates Stored in SCAN header. In the SBAS D scheme, sin(LONPOLE) = − sin(SK0P) cos(SB0P) . sin[arccos(cos(SB0P) cos(SK0P))] LATPOLE Latitude of basis pole in native coordinates (note the opposite definition to LONPOLE Stored in SCAN header. In the SBAS D scheme, sin(LATPOLE) = cos(SB0P) cos(SK0P). CRVAL, LONPOLE and LATPOLE can also be calculated in terms of SL0P, SK0P and SB0P for the alternative SBAS P or D * scheme (not yet done). We propose to store the frame definition in the WCS format. Storing CRVALj, LONPOLE and LATPOLE is equivalent to storing SL0P, SK0P and SB0P, and the translation is straightforward. The keywords required for each step in the coordinate transformation are: Pixel coordinates (p1 , p2 ) to projection plane coordinates (x, y) – (FEEDOFFX, FEEDOFFY): pixel coordinates – CRPIXi: pixel coordinates of projection plane origin – PCi j: rotation matrix Projection plane (x, y) to user native spherical coordinates (φ, θ) – CTYPEj: xxxx-SFL projection Create Date: April 10, 2003 Page 18 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format User native spherical (φ, θ) to celestial basis (α, δ) – – – – – – CRVALj : native system origin in basis coordinates LONPOLE: longitude of native pole in basis coordinates LATPOLE: latitude of basis pole in native coordinates CTYPEj: xLON/xLAT-xxx basis system RADESYS: equatorial/ecliptic system additional description EQUINOX Fig. 2 illustrates the general situation which we have just described using WCS keywords. We show the array centred at offsets (LATOFF, LONGOFF) from a source position (LONGOBJ, LATOBJ) in the user’s rotated frame. The user’s native frame is in turn centred at (CRVAL1, CRVAL2) in the standard astronomical basis frame defined by CTYPEj. If observations are made with a single feed, then the P C matrix reduces to the identity matrix and the pixel offsets are all zero. In this case, it would be simpler to define the pixel offsets as (LONGOFF, LATOFF) and measure the pixel offset of the user frame origin CRPIX from the source position in the user native frame. This scheme could well be useful later in the data reduction process, but here in the raw data format we give the more general description for rotated array observations so that all observing possibilities are covered. 3.5.6 Moving bodies Moving bodies are a special case for coordinate storage, because the local reference frame is defined by the ephemeris and rotates with time. To support moving body observations, we have a flag MOVEFRAM in the SCAN header. The orbital elements are then also listed in the SCAN header. As the native coordinate frame rotates with time, the parameters which define it with respect to the fixed basis frame need to be stored with each integration. These are given as MCRVAL1, MCRVAL2, MLONPOLE and MLATPOLE in the DATAPAR table, per integration. The equivalents in the SCAN header can be ignored for moving bodies. We then need two WCS descriptions of the image (multiple image axes descriptions are allowed in FITS). Firstly, as in order to carry out the observations we have already defined the body frame in terms of a fixed basis system (eg. RA/Dec), we have the description to provide output in that fixed frame, using the CTYPE values in the SCAN header. This is only useful on an integration-by-integration basis, as the body moves across the sky. More usefully, we propose a second coordinate description with CTYPE=BLON/BLAT (longitude and latitude in the frame of the body) with WCSNAME ’Moving body coordinates’. As this frame exactly tracks the body’s native coordinate system, CRVALj= (0, 0), LONPOLE= 0 and LATPOLE= 90. At present this second axis description is not written explicitly into MBFITS as it does not change and is only useful at the point where an image table is written. Whether the more complex observing modes such as on-the-fly can be used on a moving body will depend on the cleverness of the telescope control system. The MBFITS format allows for a full description in the case of a moving frame as for a fixed frame. 3.5.7 Observations in Az/El, On-the-fly mapping in Az/El Another special case for coordinate representation are observations where the user native frame is Az/El but the required basis frame is a fixed celestial one. The Az/El frame shifts and rotates with time with respect to the celestial frame. Again, the moving frame flag MOVEFRAM is set and the horizontal frame centre is defined by MCRVAL1, MCRVAL2, MLONPOLE and MLATPOLE in the DATAPAR table, per integration, and the equivalents in the SCAN header can be ignored. If output is only required in Az/El frame, then the native frame is the basis frame and the frame centre stays fixed. For on-the-fly mapping in azimuth (or elevation) about a source/offset position defined in a celestial system, the basis frame and native frame are celestial frames related by the usual parameters (neither is Az/El), and (LATOFF, LONGOFF) is given in the native celestial frame for each integration as usual, Create Date: April 10, 2003 Page 19 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format although the scanning was specified in azimuth. The derivation of as (LATOFF, LONGOFF) from the real-time antenna coordinates and wobbler offset plus frame definitions must then take into account the chopping direction, stored in WOBDIR. 3.5.8 Pointing The corrections to the pointing can be divided into antenna, subreflector and receiver-dependent static terms, dynamic pointing and focus corrections from observations of pointing sources during the observations, focus/elevation interplay, and the refraction correction. The pointing corrections are dealt with in two stages: the telescope control system (TICS) handles the refraction correction, the dynamic antenna pointing correction, and the receiver terms; and the antenna pointing computer deals internally with the static pointing, the dynamic focus correction, (and the focus/elevation interplay ?). The static pointing coefficients for the APEX antenna follow the 7-coefficient model described by Mangum (2001), which follows the Stumpff (1972) model, plus an extra flexure term which behaves in the same way as receiver offsets at the Nasmyth focus. The pointing terms are given in Table 2. Table 2: Pointing terms Term 30m equiv. Description Antenna static terms, in SCAN header IA P1 Azimuth zero offset CA P2 Collimation NPAE P3 Collimation of the axes /Non-perpendicularity between mount azimuth and elevation axes AN P5 Azimuth azis offset north-south / zenith shift AW -P4 Azimuth offset east-west / zenith shift IE P7 Elevation zero offset ECEC P8 Gravitational flexure perpendicular to optical axis plus vertical receiver offset at Nasmyth focus ZFLX Gravitational flexure parallel to optical axis plus horizontal receiver offset at Nasmyth focus Receiver static terms, in FEBE table IARX Receiver azimuth zero offset CARX Receiver collimation IERX Receiver elevation zero offset ECEC Receiver flexure term Focus/elevation correction: internal to pointing computer? Observed pointing corrections, in MONITOR IAOBS NULA azimuth offset determined from pointing obs. CAOBS COL* collimation determined from pointing obs. IEOBS NULE Elevation offset determined from pointing obs. Dynamic focus correction, in MONITOR FOCUSOBS SFC2 Radial focus correction determined from focus measurement. Refraction correction, in MONITOR REFRACTIO Refraction correction, from HUMIDITY, TAMBIENT, and PRESSURE as a function of elevation At APEX it is yet to be decided if the raw telescope drive readouts and the focus/elevation correction (?) will be available from the pointing computer and therefore if the full pointing calculation can be repeated offline. We also don’t store the full set of coefficients for reconstructing the refraction correction. Create Date: April 10, 2003 Page 20 Contact author: Jennifer Hatchell APEX Multi-Beam FITS Raw Data Format However, we do store the static antenna and receiver terms and the dynamic antenna and focus corrections, plus the total refraction correction, for reference. 3.5.9 WCS spectral coordinates The v.0.3 scheme for spectral coordinates followed the ALMA-TI FITS format which basically complied with WCS, but as WCS has been updated since ALMA-TI FITS was written we have made some changes in v. 1.0 to keep in line with the latest version (Greisen & Valdes 2002). These axes descriptions are in the ARRAYDATA header. (The velocity description is only given for spectral line receivers.) There are alternative frequency and velocity descriptions of the data axis, both in the chosen rest frame. These are described by WCSNAME ‘xxxxFreq’ and ‘xxxxVRad’ where xxxx represents the rest frame (eg. LSRK). The frequency description is labelled ‘F’ and the radio velocity description ‘R’. In the WCS system, VELOSYS (VSYS) stores the observer’s velocity with respect to the rest frame, which we previously stored in V FRAME. This velocity difference changes with time – here it is stored every observation, but if needed it could be stored closer to the integration level (in MONITOR?). The old keywords VELO SYS and V FRAME have been removed from the scan header. VELO SYS – a 4-letter description of the velocity frame – clashed with the WCS name. SPECSYS (SPEC) describes the velocity standard of rest frame. SSYSOBS (SOBS) is added to take the constant spectral coordinate of each image (pixel) plane - here the observer’s frame ‘TOPOCENT’. VSOURCE (VSOU) gives the source velocity with respect to the standard of rest, and VELOSYS (VSYS) gives the observer’s velocity with respect to the standard of rest. The keywords V EARTH, V HEL and V SYS subdividing VELOSYS into components are not included. These values can be stored in the WCS system by adding extra velocity frame descriptions in addition to the ‘LSRK’ one. It would also be simple to provide alternative frequency/velocity axis descriptions for the image sideband or for velocities in the source frame, if required. Actual frequency settings for the receivers/LO chain are stored in the MONITOR stream. 4 References References [1] Lucas, R., and Glendenning, B., 2001, ‘ALMA Test Interferometer Raw Data Format’, ALMA-SW0015. [2] Brunswig W., Thum C., Salter C., Ruiz M., Schraml J., http://www.iram.es/IRAMES/otherDocuments/manuals/ ‘OBSINP manual (30m)’, [3] Greisen E. W., Calabretta M.R. 2002, ‘Representation of world coordinates in FITS’, in prep., available from http://www.aoc.nrao.edu/∼egreisen/ [4] Calabretta M.R., Greisen E. W., 2002, ‘Representation of celestial coordinates in FITS’, in prep., available from http://www.aoc.nrao.edu/∼egreisen/ [5] Greisen E. W., Valdes F. G., 2002, ‘Representations of spectral coordinates in FITS’, in prep., available from http://www.aoc.nrao.edu/∼egreisen/ [6] Wells, D.C., Greisen E.W., Harten R.H., 1981, A&AS, 44, 363 [7] Mangum J. G., 2001, ’A Telescope Pointing Algorithm for ALMA’, ALMA Memo 366 [8] Bunclark P., Rots A., 1996, ‘Precise re-definition of the DATE-OBS Keyword encompassing the millenium’, http://www.cv.nrao.edu/fits/wcs/year2000.txt [9] Cotton W.D., Tody D., Pence W.D., 1995, ‘Binary table extension to FITS’, A&AS 113, 159 Create Date: April 10, 2003 Page 21 Contact author: Jennifer Hatchell APEX Create Date: April 10, 2003 5 MBFITS specification 5.0.10 Data types The following coding is used in the tables for data types: L 1-byte logical A 1-byte ASCII character I 2-byte integer (±32767) J 4-byte integer E 4-byte real D 8-byte double P 16-byte pointer 5.1 The Primary header Page 22 Keyword NAXIS SIMPLE BITPIX EXTEND TELESCOP ORIGIN CREATOR MBFTSVER COMMENT Type 1I 1L 1I 1L 20A 20A 20A 10A 20A Value 0 T 32 T Description Telescope Name Organisation or Institution Software (including version) MBFITS version Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell The SCAN-MBFITS Binary Table Stored every scan, containing parameters which do not change between observations, including: APEX Create Date: April 10, 2003 5.2 – Telescope and observatory parameters – Time system – Coordinate system – Velocity system – Project ID – Source and coordinates – Observing mode – Pointing coefficients 5.2.1 SCAN-MBFITS Binary Table Header Keywords Page 23 Type 20A 20A 1D 1D 1E 12A 12A 1J 23A 1D 1D Units deg deg m day s N OBS TIMESYS UT1UTC TAIUTC CTYPE1 CTYPE2 RADESYS 1J 4A 1D 1D 8A 8A 8A s s - EQUINOX 1E Julian yrs FITS Description ’SCAN-MBFITS’ Telescope Name observatory longitude observatory latitude observatory elevation Project ID Observer and operator initials Scan number scan start in TIMESYS system Scan date/time (Modified Julian Date) Local apparent sidereal time (scan start) Number of observations in this scan time system (TT, TAI, UTC ...) UT1-UTC time translation TAI-UTC time translation Basis system (longitude) – XLON-SFL Basis system (latitude) – xLAT-SFL additional system definition for ecliptic/equatorial coords Equinox Comment was 4 characters, now 12 - less restrictive See Sect. 3.5 for coordinate system definition Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell Keyword EXTNAME TELESCOP SITELONG SITELAT SITEELEV PROJID OBSID SCANNUM DATE-OBS MJD LST Page 24 deg Native frame zero in basis system (long.) Native frame zero in basis system (lat.) Native longitude of celestial pole Basis latitude of native pole Source name Source longitude in native frame Source latitude in native frame Calibrator Code True if tracking a moving frame CRVAL2 LONPOLE LATPOLE OBJECT LONGOBJ LATOBJ CALCODE MOVEFRAM 1D 1D 1D 20A 1D 1D 4A 1L deg deg deg deg deg - PERIDATE PERIDIST LONGASC 1D 1D 1D Julian yrs AU deg OMEGA INCLINAT ECCENTR ORBEPOCH ORBEQNOX DISTANCE SCANTYPE 1D 1D 1D 1D 1D 1D 20A deg deg yrs Julian yrs AU - TP, Julian date of perihelion passage QR, perihelion distance OM, Longitude of ascending node (in degrees) W, Angle from asc. node to perihelion IN, Inclination EC, Eccentricity EPOCH, Epoch of orbital elements Elements equinox Geocentric Distance Scan astronomical type SCANMODE 20A - Mapping mode SCANGEOM 20A - Scan geometry SCANDIR 4A - (optional) scan direction In the case of moving objects, the orbital elements are also stored. The abbreviations in the description match JPL Horizons. including POINT, FOCUS, CAL, SKYDIP, HOLO, OTF, ONOFF, PSW, RASTER, CROSS, UNKNOWN, FLUXCAL. . . Formerly OBSTYPE. Any of the following SCANxxxx parameters can change from observation to observation move to the DATAPAR header and should be looked for there. Particularly SCANDIR often changes between observations. The parameters should be included as needed depending on SCANMODE. See text. SAMPLE, RASTER, OTF. v.1.2: SCANMODE now holds map type and SCANGEOM the geometry including SINGLE, LINE, CROSS, RECT, QUAD, CIRC, CURVE described as USER (user native frame) or xLON/xLAT as in CTYPEj (standard basis system), including ALON/ALAT for Az or El scanning. Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell 1D APEX Create Date: April 10, 2003 CRVAL1 Page 25 - (optional) number of lines in a scan. Default 1. (optional) number of repeats of each scan line. Default 1. user-defined (optional, OTF/RASTER) line length SCANRPTS 1J SCANLEN 1D SCANXVEL 1D SCANTIME SCANXSPC 1D 1D SCANYSPC 1D SCANSKEW 1D SCANPAR1 SCANPAR2 1D 1D CROCYCLE 20A user-defined (optional, OTF) tracking rate along line. user-defined (optional, OTF) time for one line user-defined (optional, RASTER) step along line between samples user-defined (optional, OTF/RASTER) step between scan/raster lines user-defined (optional, OTF/RASTER) offset in scan direction between lines user-defined (optional) spare scan parameter user-defined (optional) another spare scan parameter CAL/REF/ON loop string ZIGZAG 1L - TRANDIST 1J m TRANFREQ 1J m TRANFOCU 1J m WOBUSED WOBTHROW WOBDIR 1L 1D 4A deg - (optional, OTF/RASTER) Scan in zigzag? (optional, HOLO) Holography transmitter distance (optional, HOLO) Holography transmitter frequency (optional, HOLO) transmitter offset from prime focus Wobbler used? wobbler throw wobbler throw direction WOBCYCLE WOBMODE NFEBE IA 1E 20A 1J 1E s deg wobbler period wobbler mode (SQUARE/TRIANGULAR) NFEBE number of FEBEs Pointing Coefficient (P1) For OTF, the line length or turn angle (SCANGEOM=CIRCLE) in Deg; for RASTER, the number of samples in a line. Units depend on SCANMODE definition. for modes I haven’t thought of. . . SWTCHMOD has moved to the FEBE header, as it is receiver-dependent showing how often to go to CAL and REF, eg. CROOCOO is a REF every four ONs and CAL every two ONs – see 30m NCS documentation. TRUE if alternate lines traced in opposite directions, FALSE if all lines traced in same direction. If SCANTYPE=HOLO, these three special holography keywords are stored. Wobbler parameters apply to all receivers. Described as USER (user native frame) or xLAT or xLON, inc. ALON or ALAT for Az or El scanning. Previously N FEBE For a full description of the pointing terms see Sect. 3.5.8. Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell 1J APEX Create Date: April 10, 2003 SCANLINE 5.2.2 deg deg deg deg deg deg deg Pointing Pointing Pointing Pointing Pointing Pointing Pointing Coefficient Coefficient Coefficient Coefficient Coefficient Coefficient Coefficient APEX Create Date: April 10, 2003 1E 1E 1E 1E 1E 1E 1E CA NPAE AN AW IE ECEC ZFLX (P2) (P3) (P5) (-P4) (P7) (P8) (Flexure) SCAN-MBFITS Binary Table Columns The scan table just contains a list of FEBEs. Keyword FEBE Type 17A Units - Description Frontend-backend combination identification Comments format: – where FE and BE are 8-letter identifiers Page 26 Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell Page 27 5.3.1 The FEBEPAR-MBFITS Binary Table The FEBEPAR table is stored per FEBE per scan and contains the frontend-backend setup. Parameters common to all FEBEs are in the SCAN table. Includes: APEX Create Date: April 10, 2003 5.3 – FEBE setup: number of pixels, polarisations and basebands – Pointing coefficients specific to this FE – Calibration parameters specific to this FEBE A note on feed/pixel counting: An array has a certain number of pixels/elements/feeds, each of which has associated polarisation, offset and other properties. For any one scan, only a subset of these may be in use. In order that the arrays storing the fixed properties (polarisation etc.) remain the same for each use of the array, but to minimise data storage when only a subset is in use, we differentiate between the number of feeds on the array (FEBEFEED = total number of array elements) and the number of feeds in use (USEAC, USEDC = AC/DC coupled array elements in use for bolometers, USEFEED for heterodyne receivers). A receiver outputting two polarised feeds is equivalent to an ’array’ with two ’pixels’: the polarisations are then stored in POLTY and the feeds (here polarisations) in use in USEFEED. FEBEPAR-MBFITS Binary Table Header Keywords Type 20A Units - Description ’FEBEPAR-MBFITS’ Comment FEBE 17A - format: – where FE and BE are 8-letter identifiers SCANNUM DATE-OBS 1J 23A - DEWRTMOD 5A - Frontend-backend combination identification. Scan number observing date (Y2K format with time) in TIMESYS system (scan start) Dewar tracking system DEWANG 1J Deg Dewar angle FEBEBAND FEBEFEED 1J 1J - NBD number of basebands for this febe NFD total number of feeds CABIN = fixed in Nasmyth/Cassegrain system, EQUA: RA/DEC; HORIZ: AZ/EL Fixed in DEWRTMOD system, measured counterclockwise from vertical. Fixed throughout a scan. Frequency bands FEBEFEED stores the total number of feeds for the receiver in use. A receiver outputting two polarisations counts as two feeds. For an array, count the total no. of pixels, even if not all in use. Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell Keyword EXTNAME Page 28 1J - NUSFD Number of feeds in use. SWTCHMOD 20A - Switch mode NO SWITCH FRQTHROW IARX 1J 1E 1E Hz deg CARX 1E deg IERX 1E deg ECECRX 1E deg ZFLXRX 1E deg no. of switch phases in a switch cycle Frequency switching throw Pointing Coefficient (receiver), adds to IA (P1) Pointing Coefficient (receiver), adds to CA (P2) Pointing Coefficient (receiver), adds to IE (P7) Pointing Coefficient (receiver), adds to ECEC (P8) Pointing Coefficient (receiver), adds to ZFLX 5.3.2 So that we can minimally dimension the data storage array in ARRAYDATA table. Now for bolometers or heterodyne. A bolometer feed which is AC- and DC-coupled counts twice here TOTP, FSW, BEAMSW, HORNSW, LOADSW, CAL. . . Moved from SCAN header, as receiver-dependent - apart from WOBSW, which is covered by WOBUSED in SCAN header fs/wobbler APEX Create Date: April 10, 2003 NUSEFEED Here are the receiver-specific pointing coefficients: FEBEPAR-MBFITS Binary Table Columns Multidimensional parameters that can’t go in the FEBEPAR header. These include parameters for the whole array and for the subset which is in use. Type NUSFD J Units - Description List of feeds which are in use FEEDTYPE NUSFD A - feed type FEEDOFFX NFD D deg feed x offset Comments The data in the ARRAYDATA table are stored in the order listed in USEFEED (heterodyne receivers). v.1.2: USEAC, USEDC and corresponding data arrays are removed so that table structure remains constant. ’H’ for heterodyne; for bolometers, ’A’=AC-coupled, ’D’=DC-coupled. The following parameters depend on feed and (sometimes) frequency band, and are given for the whole array, not just the feeds in use. x offset of each feed from rotation centre in DEWRTMOD system. Multi-Beam FITS Raw Data Format Contact author: Jennifer Hatchell Keyword USEFEED Page 29 NFD D deg feed y offset REFFEED 1J - feed number of reference feed POLTY POLA NFD A NFD E deg Feed type (X, Y, L, R) Feed orientation APEREFF BEAMEFF ETAFSS HPBW ANTGAIN BOLCALFC NFD ×NBD NFD ×NBD NFD ×NBD NFD ×NBD NFD ×NBD NBD E BOLFLAT GAINIMAG NFD ×NBD E NFD ×NBD E E E E E E Aperture efficiency Beam efficiency Forward efficiency deg Half-power beam width K/Jy Antenna Gain Jy/countsBolometer calibration factor - y offset of each feed from rotation centre in DEWRTMO