 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
Oleg Smirnov
20 June 2000
A postscript version of this note is available (100 Kb)
The workhorse of the ionospheric calibration system is the Ionosphere class. The basic function of the Ionosphere class is to predict the electron density distribution (aka ED profile) and rotation measure (RM) along specified slants. A slant is defined as a time, position and line of sight (T, Lon, Lat, Az, El).
The Ionosphere class relies on two other class hierarchies, inherited from two abstract base classes. Descendants of IonosphModel provide apriori ionospheric models, such as PIM. Descendants of IonosphData handle observations of the ionosphere, such as GPS or ionosonde data. Ionosphere uses IonosphModel to build up apriori estimates of the ED distribution, then applies secondary corrections to achive the best fit with IonosphData.
Currently implemented is an IonosphModelPIM class, encapsulating PIM (the Parametrised Ionospheric Model developed by the USAF). An IonosphDataGPS class, for secondary corrections via GPS observations, is currently under development. Observations of GPS sattelites provide measurements of TEC (the total, or integral electron content) along lines of sight. Since at least six sattelites are passing across the sky at any given point in time, a GPS receiver can produce a wealth of TEC measurements, which can significantly improve any models of the ionosphere. Note that the GPS receiver does not need to be co-located with an inteferometer - just near enough, so that the GPS sattelites are observed through ``interesting'' parts of the ionosphere at least some of the time.
PIM itself is a monolithic edifice of FORTRAN code. Additional FORTRAN routines have been added by Bob Campbell, to facilitate access to the model using slants. IonosphModelPIM is basically a C++ wrapper around all this FORTRAN code. None of the FORTRAN was modified. Thus, we can reasonably expect future versions of PIM to plug into AIPS++ without too much trouble.
The FVisJones class (inherited from TimeVarVisJones) implements the F-term of the Measurement Equation. This facilitates correction for Faraday Rotation in the visibilities plane (thus assuming a spatially-constant ionosphere over the whole beam). FVisJones extracts the epochs, source and station coordinates from the Measurement Set, passes them to Ionosphere to obtain ED profiles and derive rotation measures, and constructs a rotation matrix for each frequency channel.
Note that ionospheric prediction is thus completely decoupled from the calibration. FVisJones knows nothing of how the ionosphere is predicted. The Ionosphere classes can be revised and developed independently of FVisJones. Finally, an FSkyJones, for corrections in the image plane, may be developed independently of Ionosphere.
Operationally, the Ionosphere classes require a large number of external data sets from a variety of sources. These data sets must be somehow integrated into AIPS++ in a way transparent to the end-user.
The PIM FORTRAN code reads an impressive amount of external data files. Since this code is plugged into AIPS++ ``as is'', these files must be available at run-time, in their ``native'' (i.e., PIM-readable) format.
This is a large set of data files used by the PIM model. This data set is a total black box. It should be considered an integral part of the PIM software, since the databases are never updated in between PIM releases.
PIM databases are distributed by the USAF along with the PIM software. The distribution format is ASCII files; a set of utilities is provided for converting the ASCII files into native binary format which is required by PIM at run-time. Total size is roughly 30 Mb.
Daily solar flux data is available by anonymous ftp from NOAA, with a 1-2 month lag. More recent data is available in ``preliminary'' format, as well as near-future ``forecast'' data. PIM cannot work with preliminary/forecast data (yet?).
Daily IMF observations are available via the Web from NASA/GSFC. Time lag is about 3 months. An important open issue is that IMF observations contain gaps. For some days, there is no IMF data at all, so some fallback strategy must be devised. Note that the only IMF datum of interest to PIM is the sign of the Bz component (which ultimately determines whether the IMF force lines are easily coupled with the EMF force lines).
Since the rotation measure is determined by both electron density and the magnetic field strength, Ionosphere needs to know the Earth magnetic field. The current version relies on a FORTRAN routine within PIM, which in turn uses the IGRF model. Because IGRF is already incorporated into the AIPS++ Measures system (see, e.g., MVEarthMagnetic, EarthMagneticMachine), I plan to implement a C++ version of this routine in the near future.
Note: So far, I've only written up RINEX and Ephemeris tables. They are the only ones that involve the Measurement Set. Table formats for geophysical data are, for the most part, quite trivial.
The strategy here is to stay as close as possible, content-wise, to the ``raw'' data formats.
The RINEX table is supposed to store RINEX data relevant to the MS. This data is not necessarily homogenous, as it can come in several RINEX files and perhaps from several GPS receivers (with different sampling rates, etc.). I propose to store the data in ``chunks''. One chunk is a block of samples from a single receiver, contiguous in time. A single RINEX file corresponds to a chunk; several RINEX files from the same receiver for adjacent time periods can be (but do not have to be) merged into one chunk.
Each row of a RINEX table will correspond to a chunk; attaching another RINEX file to the MS adds one row to this table.
The EPHEMERIS table holds GPS sattelite ephemeris. Since this table is going to be either stored in the MS (as a small sampling), or distributed incrementally, it seems reasonable to hold one day's data for all sattelites in a single row of the table. This makes it easier to separate the data into daily chunks when necessary. This also simplifies mapping of the EPHEMERIS table to original IGS-SP3 files (which are distributed on a 1-day basis).
