 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass00/P2-33/
Дата изменения: Tue May 29 20:22:08 2001 Дата индексирования: Tue Oct 2 04:52:43 2012 Кодировка: Поисковые слова: р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п п р п р п п р п |
The CAOS software system is a set of software tools specifically designed to allow the modeling of any kind of Adaptive Optics system. It was originally developed in the framework of the ``TMR Network on Laser guide star for 8 meter class telescopes'' funded by the European Community. In this same conference an overall description of the original package (see: 249 ) and a specialized version dedicated to the deconvolution of multiple interferometric images for the Large Binocular Telescope (see: 404 ) are also presented.
The Application Builder has been designed in order to provide the scientists with a Graphical Programming Environment in which elementary building blocks could be assembled together to create complex simulation applications in a straightforward manner, so that the user could concentrate on the scientific aspects of his/her problem, while mundane coding problems were managed by some automatic tool.
The functionalities and the overall architecture of the AB are the result of trade-offs among various requirements, and mainly of three principal goals:
When the AB is launched it appears to the user, as shown in figure 1, as a graphical window (the worksheet) provided with a number of rectangular slots and with a number of pull-down menus.
The building blocks, called modules (see figure 2) can be selected from a list and placed on the worksheet to build up the simulation program (the project); modules can be put into any free slot on the worksheet and then inputs and outputs can be joined by means of links which represents the data flow in the program.
Modules are represented as ``computational blocks'' provided with up to two inputs and up to two outputs; in order to convey the concept of input and output data types, the input and output types are encoded by different colors, so that it is clear that only equally colored inputs and outputs can be joined together.
A few modules have been designed to be ``generic type'', i.e., they accept input (output) of any type, and the actual type is assigned when they are linked to some typed output (input). This mechanism is useful for general purpose modules (e.g., the data display module) as an alternative to providing a particular typed module to display data values of each particular data type. The generic data display module has been designed so that it can check the data type of its input and use the appropriate section of code to display the value of a particular item.
For any module that requires the specification of run-time parameters, the user can invoke a Graphical User Interface which helps in the definition of values to be used in the execution of the program. At exit the parameter definition GUI creates the required data structures and saves them in the working directory by means of an IDL standard save command.
It often happens in the design of a simulation program that the same module must be used more than once, in different parts of the program, e.g., an optical element which is used twice in the optical path.
This case is handled by the AB by means of ``module clones'': all modules of the same type share the implementation code, clones also share the set of run-time parameters. When the parameter definition GUI is started for a clone, the parameters which are actually modified are those of the ``father'' module. This ensures that the two modules correctly represent the same physical element.
A special ``feedback'' module must be used to ``close loops'', i.e., to assemble simulation programs which include feedback loops.
In order to ease the project building, the AB includes a few more tools.
The project library, is a repository of projects which are distributed together with the CAOS software system which can be merged into a project being developed, or can be used as examples for similar ones.
Moreover the CAOS software distribution can be customized by defining packages. A package is a subset of the available modules, possibly specialized for a particular area of applications. By selecting a package the user is set into an environment which is exactly suited to the application to be developed.
When the project is finished it can be saved on disk. The save operation generates the source code which implements the simulation program together with a textual description of the graphic layout of the project by which the project may be later restored in the AB for subsequent use.
The code is subdivided in two IDL procedures: project.pro, which contains initialization and looping instructions, and mod_calls.pro, containing the sequence of procedure calls corresponding to the project.
As an example here follows a simplified version of the code generated by the project shown in figure 1:
COMMON caos_block, tot_iter, this_iter, calibration, signature ret=src(O_004_00,src_00004_p,INIT=src_00004_c) ret=atm(O_002_00,atm_00002_p,INIT=atm_00002_c) ;------------------------------------------------ Loop is closed Here IF N_ELEMENTS(O_027_00) GT 0 THEN O_029_00 = O_027_00 ret=gpr(O_004_00,O_002_00,O_006_00,gpr_00006_p,INIT=gpr_00006_c) ret=dmi(O_006_00,O_029_00,O_025_00,O_025_01,dmi_00025_p,INIT=dmi_00025_c,TIME=dmi_00025_t) ret=shs(O_025_00,O_010_00,shs_00010_p,INIT=shs_00010_c,TIME=shs_00010_t) ret=cen(O_010_00,O_012_00,cen_00012_p,INIT=cen_00012_c) ret=rec(O_012_00,O_014_00,rec_00014_p,INIT=rec_00014_c) ret=tfl(O_014_00,O_027_00,tfl_00027_p,INIT=tfl_00027_c)
The project.pro procedure skeleton which is ``wrapped'' around the above code is shown below:
RESTORE, 'Projects/luca1/src_00004.sav' ; Restore parameters
RESTORE, 'Projects/luca1/atm_00002.sav'
RESTORE, 'Projects/luca1/gpr_00006.sav'
RESTORE, 'Projects/luca1/dmi_00025.sav'
RESTORE, 'Projects/luca1/shs_00010.sav'
RESTORE, 'Projects/luca1/cen_00012.sav'
RESTORE, 'Projects/luca1/rec_00014.sav'
RESTORE, 'Projects/luca1/tfl_00027.sav'
@Projects/luca1/mod_calls.pro ; Initialization
FOR this_iter=1, tot_iter DO BEGIN ; Main loop
@Projects/luca1/mod_calls.pro
ENDFOR
Because the IDL language was selected as the best choice for the implementation of modules, it was also decided to implement the AB in the same language, although not fully suited to this particular task. It is started as an usual script from the IDL prompt, and it is completely independent from the simulation program it has created: the simulation program can and will run independently on the AB itself.
The final version of the AB is made up of some 39 IDL source files for a total of 6700 lines of code (including full documentation of the source code).
Fini, L. 1999, Arcetri Tech. Rep. No 5/99
Carbillet, M., Femenia, B., Delplancke, F., Esposito, S., Fini, L., Riccardi, A., Viard, E., Hubin, N., Rigaut, F. 1999, in Adaptive Optics Systems and Technology, R. K. Tyson and R. Q. Fugate eds. SPIE Proc. 3762, 378
Carbillet, M., Riccardi, A., Fini, L., Viard, E., Delplancke, F., Femenia, B., Esposito, S., Hubin, N. 2001, this volume, 249
Correia, S., Carbillet, M., Barbati, M., Boccacci, P., Bertero, M., Fini, L., Richichi, A., Vallenari, A. 2001, this volume, 404