Useable data prodcuts are rays, PSF's and encircled energies. Rays are exportable as FITS photon lists. PSF's will be FITS images, unless an analytical formulation is found.
Interfacing SAOsac to the outside world can take two forms:
There are two areas limiting the portability of SAOsac: the data flow paradigm (pipes), and the code structure.
SAOsac runs as multiple concurrent processes which communicate via UNIX pipes, which in turn are created by a shell (in this case the system supplied Bourne shell). While pipes are not unique to UNIX, our use of the shell to stitch them together may be difficult to translate to other operating systems. I am too ignorant of the details of other OS's to comment on the difficulty. We have no plans to port to non-UNIX systems.
The code itself is required to work on Solaris and IRIX. It should be cleanly portable to other UNIX platforms. In order to make our life easier, we have developed a set of template makefiles which reflect our directory structures, network environment, development environment, etc. We have attempted to isolate the platform specific parts as much as possible, but there is a very unique flavor to the way we do things. It wouldn't be too difficult to make the configuration and build parts more portable, but things will never be "simple".
SAOsac does require proprietary spline routines from NAG. This will need to be worked around before a public release.
While it is possible to run the programs that make up the ray trace suite individually, it is a complicated and messy business. We have provided a very simple, albeit limiting, "driver" script which allows the user to ray trace from a set of configurations, altering things such as the shell to trace, the source position and energy, and the number of rays to trace. We are upgrading this driver to handle the more complicated situations possible with the new (unreleased) ray generator. Because this is a parameter driven, non-interactive driver, it would be possible to create a GUI for it which could be made available to remote users of the ray trace code.
As I see it, the biggest problem with interfacing SAOsac to ascfit is that the latter depends upon a response matrix formalism to specify the characteristics of the mirrors. SAOsac may be used to generate the matrices, but this would not be as part of the optimization loop. SAOsac could be used to generate a stream of events from the combined source and mirror, which could be formed into an image (if that's what ascfit wants).
Currently, SOAsac ray traces a single shell at a time, requiring four serial runs to trace the entire HRMA. In addition there is considerable start-up overhead, which makes running it in an optimization loop very expensive.
This document was generated on 18 November 1997 using the texi2html translator version 1.51.