 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
It is useful to record how the design process worked.
We did not use any formal methodology or even diagramming tools, except at the end to record the design. We did a detailed analysis of the MeasurementEquation before starting the design. We did lots of prototype coding, all in c++. The Sun native compiler (in various beta releases) was mainly used. Compile and link times ranged from a few minutes to more than ten once we increased the use of templates. This is bearable but far from ideal.
We were able to work together effectively by splitting responsibilities for development in different areas and reconciling, by hand, code divergences every few days. That this is possible is a good sign for close-knit collaborations in AIPS++ and is in line with experience in other parts of the project. One of us (TJC) worked principally on design, and the other (MHW) on efficiency issues. We spent a considerable amount of time writing special classes for matrices with few elements and special symmetries (SquareMatrix) and vectors with few elements (RigidVector).
We started with toy classes representing the MeasurementSet and the Image and only later changed to use the actual AIPS++ classes. This was an excellent idea which enabled more rapid debugging than would have been possible otherwise.
The overall breakup into classes was settled fairly early on and
changed relatively little. The assignment of responsibilities to
classes changed a lot as we looked for and found a natural split of
the evaluation of gradients of 
. This probably represented most
of the experimentation that was performed. We also flirted with global
functions for the the solve step. That solve is not polymorphic is
conventional wisdom of long-standing in the project. While this is
obviously true in general, we believe that we have chosen an approach
that is flexible enough to allow most calibration and imaging schemes
now known.
Symmetry in the design between the Jones matrices and the SkyModel was the most powerful organizing principle that we came upon.
Enforcing uniformity of interface across objects was also important.
Finally, we came to the split between SkyEquation and VisEquation quite late on. While the split was obvious, the reasons for maing the design split became more pressing as we got deeper into the details and also began to think in more detail about e.g. Single Dish processing.