Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 803

News	FAQ
Search	Home

a) Current state of the library

The current state is generally good. There are two deficiencies which need to be addressed before the first release.

FITS

This isn't really a show stopper, but it has dragged out for FAR too long. As I see it, we have three options for the underlying FITS classes and one suggestion for isolating this layer. - Copy the current, old, FITS classes to aips and update their documentation. We loose the random access code in the latest FITS classes. - Start with the latest. The amount of work to document this is probably not terribly more than with the old classes. - Wait for Allan Ferris to deliver something with documentation.

My suggestion is that independent of which of these we go with, that we develop (really formalize the parts which are already there possibly with a few additional parts) a layer of our own which provides our classes with the FITS access they need without ever having to know about Allan's classes. This would also allow us to use some other set of FITS classes (e.g. cfitsio if it ever supported tape devices) without disrupting our classes. We could also, I think, then most easily justify not putting any time into documenting the underlying FITS classes ourselves. In the long run, I think this is the way to go - but it is a fair amount of work and we need to have a body to actually do the work.

Fitting

Our primary need here is for a multi-component fitting class. Notice I avoided mentioning the word "Gaussian" although that is at least initially what we need. The trick here that isn't available isn't multiple-components, its the ability to hold various parameters constant at will AND the ability to hold relationships between parameters constant (which if the problem is parameterized correctly isn't a problem once you can hold some parameters constant). The need here is to be able to fit molecular hyperfine lines so that, for example, the relative spacing between the components is held fixed and/or the relative height is held fixed. I also suspect that users will want to fit other functional forms. In the long run, it would be nice if users could specify some general functional form either via a glish function or through some specialized syntax so that they could set up a more complex fit that just a simple polynomial, or a sinusoid, or a Gaussian, etc.

Calibration

There are clearly needs for the calibration work. This will be merged into the synthesis development plan.

MS columns

We are currently archiving Parkes multi beam data from MS version 1 in SDFITS files. For the large number of MS header words which are not mentioned in the SDFITS convention, we store them in the file as MSSUBTABLE_COLUMNNAME, which effectively preserves information about MS version 1 forever. At a minimum sdfits2ms will need to do the right thing here. It would be nice if there were some concise document describing how MS 1 columns map to MS 2 (this might also aid in helping those of us who will need to rewrite our fillers in doing so).