Next: Redesign and Reimplementation of XSPEC
Up: Software Applications
Previous: Parallelization of Widefield Imaging in AIPS++
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

Smirnov, O. 2001, in ASP Conf. Ser., Vol. 238, Astronomical Data Analysis Software and Systems X, eds. F. R. Harnden, Jr., F. A. Primini, & H. E. Payne (San Francisco: ASP), 411

Ionospheric Corrections in AIPS++

Oleg Smirnov
Netherlands Foundation for Research in Astronomy (ASTRON)
P.O. Box 2
7990 AA Dwingeloo, The Netherlands

Abstract:

The ionosphere induces significant distortion in radio astronomical measurements at lower frequencies. For polarimetric work, the most significant effect is Faraday rotation, reaching up to several turns at, e.g., meter wavelengths. Over the course of an observation, variations in the Faraday rotation can completely wash out any polarization in the signal. The effect can be corrected for only if an accurate enough estimate of the electron density distribution along the line-of-sight is somehow obtained.

Campbell (1999) has experimented both with an a priori theoretical model of the ionosphere, and with GPS observations, to perform ionospheric corrections in VLBI observations. I present an extension of this approach into the AIPS++ system. AIPS++ now includes an Ionosphere module, encompassing the Parametrized Ionospheric Model (Daniell et al. 1995), and a calibration component that, given a dataset, will automatically estimate and correct for the Faraday rotation. This paper also describes some other applications of the AIPS++ Ionosphere module, such as modelling and simulation.

1. Introduction

The ionosphere induces significant distortion to radio astronomical measurements at lower frequencies. These effects are:

For low-frequency polarimetric work, by far the most significant effect is Faraday rotation (FR). Ionospheric FR can reach up to several cycles at, e.g., meter wavelengths. Over the course of an observation, variations in the FR can completely wash out any polarization in the signal. The effect can be corrected for only if an accurate enough estimate of the electron density distribution along the line-of-sight is somehow obtained.

Here I describe ionospheric calibration as being implemented in AIPS++. AIPS++ is a data processing system under development by an international consortium of observatories. The latest public release is AIPS++ 1.4. AIPS++ includes extensive support for calibration of radio astronomical data, and correction for FR fits nicely into the framework. Note that the implementation discussed here is currently only available in the development branch of AIPS++, but should make its way into the next public release in 2001.

2. Possible Approaches

Two approaches to the problem of estimating the ionospheric electron density have been pursued. We can use an a priori ``climatological'' model of the ionosphere. One such model is PIM (Parametrized Ionospheric Model), developed at the USAF Phillips Lab (Daniell et al. 1995). Given a time and date, PIM can compute a predicted electron density distribution for any region of the ionosphere. An inherent limitation of a priori models is that they can't predict small-scale structure, such as traveling ionospheric disturbances (TIDs), which are, in effect, ``clouds'' of higher electron content.

Another approach is to use direct observations of the ionosphere. Of these, GPS satellites offer perhaps the most interesting opportunity.

The Global Positioning System (GPS) provides an inexpensive and accurate way to continuously probe the ionosphere. GPS satellites transmit on two L-band carrier frequencies. By measuring the time delay between modulation on the two carriers, the total ionospheric delay (and thus the total electron content) along the line-of-sight to the satellite can be estimated. Relatively inexpensive GPS receivers will readily provide delay data. With at least six GPS satellites overhead at any time, we can derive measurements of the ionosphere along at least six different moving lines-of-sight. The International GPS Service (IGS) continuously collects data from many GPS receivers around the world; it is available via the Internet from various IGS data centers. Besides, most radio observatories have a co-located GPS receiver.

It should be noted that GPS measurements provide only an integral measurement of the electron density (the TEC) along a line-of-sight to the satellite (which, most of the time, is not the direction that we are really interested in). Faraday rotation cannot be derived from TEC directly, as it is also dependent on the magnetic field. To estimate FR, we need to know the electron distribution along the line-of-sight. In effect, the problem becomes one of tomography, with the GPS satellites providing moving slices through the ionosphere. Some sort of fitting of an a priori model is still required in order to derive profiles. Erickson et al. (1996) have experimented with a GPS receiver at the VLA, and have had some success even with a relatively simple ionosphere model.

Campbell (1999) has tried a combination of the two approaches. He has used PIM as a base model, and fitted GPS data to build up a field of ``corrections'' to PIM profiles. The AIPS++ implementation is loosely based on this approach (although secondary GPS-based corrections are not actually implemented at this point in time).

3. PIM in AIPS++

AIPS++ now includes a version of PIM. ``Classic'' PIM is a huge bulk of FORTRAN code, not especially user- or programmer-friendly. To make life even more difficult, it requires large amounts of diverse external data, such as:

AIPS++ PIM hides all of this complexity from the end-user (or application developer).

The Ionosphere Module.

The Ionosphere module of AIPS++ totally encapsulates PIM, and hides the difficulties of running it behind a rather simple class interface. To C++ programmers, Ionosphere provides functions for computing profiles of the ionosphere, TEC, and Faraday Rotation for any specified time, location, and line-of-sight.

The FJones Module.

The AIPS++ calibration package is based around the Measurement Equation (ME; Hamaker et al. 1996, Sault et al. 1996). Within the ME, the term responsible for FR is just a 2$\times$2 Jones matrix. The FJones class of the calibration package implements this matrix. Time, location, and direction are extracted from the measurement set and passed to Ionosphere. The resulting FR is used to compute the F-Jones term used in the calibration process. Thus, to perform corrections for FR, the user need do nothing more than enable the F-Jones term.

Data handling.

All of the data required to run PIM are loaded by AIPS++ automatically. Maintenance scripts on the central AIPS++ site regularly download the latest $F_{10.7}$, $K_p/A_p$, and IMF observations from appropriate data centers. These data are placed into AIPS++ tables and automatically distributed via the AIPS++ Global Data Repository.

4. GPS Data in AIPS++

Two types of GPS data are required for ionospheric work:

RINEX
is the standard output format for GPS receivers. A RINEX file will contain a list of times, satellite IDs, and observed delays, usually for a single day. RINEX files from IGS-participating receivers all over the world can be downloaded via FTP from several data centers (e.g., IGN, GSFC).

Ephemeris
data is required to tie RINEX observations to a satellite's position on the sky. Ephemeris files are available by FTP from JPL.

Two modules in AIPS++, RINEX and Ephemeris, are responsible for maintaining this data. Both will automatically download files from relevant FTP sites, and convert them into AIPS++ tables and data structures. They can also combine the data into a single location-direction-TEC table. RINEX and ephemeris services are available to C++ programs, Glish scripts, and interactive users.

5. Other Applications

Glish is the high-level scripting language of AIPS++. Most of the data processing modules, though implemented in C++, have corresponding Glish bindings, so their functionality is available to Glish scripts, or interactively, via the command line. The Ionosphere module is no exception.

Glish programmers can easily use PIM to obtain ionosphere profiles for any given time, location, and line-of-sight. This makes it quite easy to develop various modelling and simulation tasks. Thus, Ionosphere has been used at ASTRON to evaluate requirements for the future Low Frequency Array (LOFAR) instrument.

Acknowledgments

Bob Campbell laid the groundwork for this development, and provided lots of valuable assistance.

References

Campbell, R. M. 1999, New Astr. Rev., 43, 8-10, 617

Daniell, R. E., et al. 1995, Radio Sci., 30, 1499

Erickson, W. C., Perley, R. A., Kassim, N. E., Payne, J. A., Flatters, C. 1996, AAS Meeting, 189, 107.06

Hamaker, J. P., Bregman, J. D., & Sault, R. 1996, A&AS, 117, 137

Sault, R. J., Hamaker, J. P., & Bregman, J. D. 1996, A&AS, 117, 149


© Copyright 2001 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: Redesign and Reimplementation of XSPEC
Up: Software Applications
Previous: Parallelization of Widefield Imaging in AIPS++
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

adass-editors@head-cfa.harvard.edu