Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass00/reprints/P2-33.pdf Дата изменения: Wed May 30 01:31:13 2001 Дата индексирования: Tue Oct 2 10:42:36 2012 Кодировка: Поисковые слова: mercury surface

Astronomical Data Analysis Software and Systems X ASP Conference Series, Vol. 238, 2001 F. R. Harnden Jr., F. A. Primini, and H. E. Payne, eds.

The CAOS Application Builder
Luca Fini, Marcel Carbillet, Armando Riccardi Osservatorio Astrofisico di Arcetri, Firenze, Italy Abstract. In order to ease the design and implementation of simulation pro jects a graphical interface has been built on top of the CAOS Simulation Package. The CAOS Application Builder allows a user to build a simulation program (a project) by putting together elementary building blocks and specifying the data flow between blocks. When the pro ject has been defined to the user's satisfaction the IDL code which implements the program is automatically generated.

1.

Introduction

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: · the programming effort for the development of the AB had to be smal l, i.e., much less than the programming effort devoted to the development of the full package, · the AB must have marginal impact on the structure of simulation programs, i.e., the coding of blocks must not be significantly affected, and the time efficiency at run-time of the code produced must not be degraded significantly, · the requirements on the coding of single blocks imposed by the use of the AB must not prevent the use of blocks in the traditional way, i.e., as ordinary routines to be called by a user written program.

253 c Copyright 2001 Astronomical Society of the Pacific. All rights reserved.


254

Fini, Carbillet, and Riccardi

Figure 1. 2.

A Pro ject is being built in the Application Builder.

How the Application Builder Works

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 pro ject); 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.


The CAOS Application Builder
Father's ident. (if a clone) Input Section Link Input Colors encode input/output data types Output section Link

255

F:778

GPR
Link

702
Module Identification

Link Module name

Figure 2.

Anatomy of a Module.

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 runtime 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. 3. A Few More Goodies

In order to ease the pro ject building, the AB includes a few more tools. The pro ject library, is a repository of pro jects which are distributed together with the CAOS software system which can be merged into a pro ject 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. 4. Code Generation

When the pro ject 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 pro ject by which the pro ject 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 pro ject. As an example here follows a simplified version of the code generated by the pro ject 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

Output


256

Fini, Carbillet, and Riccardi

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, RESTORE, RESTORE, RESTORE, RESTORE, RESTORE, RESTORE, RESTORE, 'Projects/luca1/src_00004.sav' 'Projects/luca1/atm_00002.sav' 'Projects/luca1/gpr_00006.sav' 'Projects/luca1/dmi_00025.sav' 'Projects/luca1/shs_00010.sav' 'Projects/luca1/cen_00012.sav' 'Projects/luca1/rec_00014.sav' 'Projects/luca1/tfl_00027.sav' ; Restore parameters

@Projects/luca1/mod_calls.pro FOR this_iter=1, tot_iter DO BEGIN @Projects/luca1/mod_calls.pro ENDFOR

; Initialization ; Main loop

5.

Implementation

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). References 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