GAG: GEANT4 Adaptive Graphical User Interface M. Nagamatsu y, T. Kodama y;æ, H. Uno y, H. Yoshida y, K. Ohtsubo z;ææ, S. Tanaka z, M. Asai?, Y. Oohata

Transcription

1 GAG: GEANT4 Adaptive Graphical User Interface M. Nagamatsu y, T. Kodama y;æ, H. Uno y, H. Yoshida y, K. Ohtsubo z;ææ, S. Tanaka z, M. Asai?, Y. Oohata x;æææ, R. Hamatsu x y Naruto University of Education z Fukui University? Hiroshima Institute of Technology x Tokyo Metropolitan University æ Now at Hitachi Information Technologies ææ Now at NEC æææ Now at NTT USERS OF GEANT4 AND GUIS GEANT4 has three kinds of users; end users, application programmers and framework providers. We have developed GUIs for the ærst two categories. GAG for end users End users run GEANT4 executable æles customized and provided by application programmers. GAG ègeant4 Adaptive GUIè is a GUI for them to run GEANT4 by using commands and by changing associated parameters. We have two implementations of GAG, that is, TclèTk and Java versions. GAG provides them with a tree èjavaè or Pull-down menu ètclètkè of commands, a widget of parameter inputs of variable formats, an editor widget for logging, an error dialog and a widget for command history. GAG and GGE for Application programmers Application programmers are those who customize GEANT4 Toolkit for their detector simulation. They deæne their detector geometry and custom commands. GAG is designed so that application programmers can concentrate on their problem domains without any knowledge on visual programming. GGE ègeant4 Geometry Editorè is a GUI which helps application programmers to create their own geometry of small-scale or simple conæguration. Users can create such arrangements of volumes like, aè Single Positioned Volume, bè Repeated Volumes with translational or axially symmetric arrangements, cè Replicas

2 and dè Parametrised volumes. It provides them with a persistent editable database of materials and with widgets to deæne solids, logical and physical volumes and to save them as a persistent object. It produces C++ codes of the detector geometry from a persistent detector object. CSG or BREP solid can be previewed directly with GGE, while the full geometrical conæguration can be constructed and visualised through the compilation in conjunction with with the GEANT4 toolkit. GAG is helpful to use GEANT4's visualisation systems like DAWN and OGLIX. See the ægure 1. Momo is a uniæed environment to use GAG and GGE as well as users plug-ins. This paper reports on the design, implementation and network extension of GAG. CLASS CATEGORIES OF GEANT4 AND GAG GEANT4 oæers multiple GUIs. This leads to the splitting of the interfaces category into several sub-categories and the creation of the environments category; GEANT4's UI GUI Categories; intercom and interfaces UI GUI categories are to deæne, generate and maintain commands èintercom categoryè and to provides various types of user interactions èinterfaces categoryè. The separation of intercom category from that of interfaces is the key decision for the present scheme of UI and GUI of GEANT4. They are designed so as to minimize its disturbance to the simulator's performance, while providing various æexible and user-friendly interfaces. Interfaces category deals with UI GUI sessions with users. This category has several sub-categories corresponding to various implementation of GUIs. It provides with the abstract class G4VUIsession for user interactions. It contains basic and common interface classes such as for character terminal as well as GEANT4's backend interfaces speciæc to respective GUI implementations. The class G4UIterminal is GEANT4's backend for the terminal mode. The class G4UIGAG is the backend for the GAG mode. G4UIGAG have the same functions as those of G4UITerminal and additional functions speciæc to GAG. Environments category This category contains various GUI implementations as well as visualisation systems. Momo, GAG and GGE èjava and TclèTk versionsè are placed here. Transparent execution environment The separation of the choice of a UI session at the compilation time from its execution environment may lead to users' confusion. To avoid such simple but

3

4 annoying troubles, G4UIGAG and GAG are designed and implemented to satisfy transparent execution environment. This means that GEANT4 with no èbatch modeè or G4UIterminal ècharacter terminal modeè or G4UIGAG ègui modeè backend can be run equivalently under GAG or terminal without recompilation. DESIGN OF GAG In designing GAG, we had guidelines speciæed by the GEANT4 user requirements and oriented by the Model-View-Control model. In the MVC, a visual application is devided into three parts; model, view and controller. This model oæers very æexible schemes to GUIs. The simplest application of MVC to GAG is a separation of model ègeant4è from view and controller, in which view and controller are united in GAG. The model, or GEANT4 receives messages from GAG. GAG windows are deæned by the messages from GEANT4. For computation eæciency, GAG is allowed to ask GEANT4 all necessary information for it, only when GEANT4 is in the idle or pause states. Consequences after the MVC Model The consequences of the above design are as follows; Independent processes GEANT4 is a long-running computation. GAG is an independent process of the GEANT4 process, whose behaviour is entirely passive vis-a-vis the GEANT4. User invokes GAG which in turn executes GEANT4 as its child process. Dynamic generation of views GAG is ordered what to do in making its view by messages sent by the GEANT4 process. In this way, the view may be changed on the æy during a GEANT4 session. No visual programming required Thanks to the complete separation of GEANT4 from view and control, any commands of GEANT4 can be deæned totally independent of GAG, using classes deæned in the intercom category. This means that any knowledge on GUI programming like window manipulation, event handling and concurrency etc. is not required for application programmers. Character-based communication The two processes communicate with each other via pipes or sockets in a non-blocking mode with protocols deæned by character strings. This design allows wide choice of implementation languages for GAG.

5 Independent development of multiple views GEANT4's independence of GAG allows framework providers to develop the GEANT4 kernel without any details of GUI, and vice versa. We have witnessed the eæectiveness of TclèTk as a simple UIMS during our rapid cycling of prototyping and evaluation of GAG. Multiple implementation of GUIs End users can use both Java and TclèTk GAGs to run a GEANT4 executable. Networked GUI This abstraction a la MVC facilitates the extension of GAG to networked GUI. This was veriæed by a prototype version of RemoteGAG using Java RMI èremote Method Invokationè, described later. DEVELOPMENT OF TCLèTK AND JAVA GAG TclèTk and Java oæers necessary features for GUI in common; aè platformindependent methods of inter-process communication, bè concurrent or multithread programming, cè rapid prototyping and evaluation, dè platform independence, eè network programming, fè rich GUI components, gè ease of maintenance, hè wide user groups and experiences in many æelds, iè serialisation of objects èjavaè, jè æexible script language and robust interpreter ètclètkè, and kè future. The parallel development of GAG proved to be helpful for the validation of GUI. Two versions of GAG have identical functions. In general, the validation of GUI programs is a diæcult task without little methodological help. By developing them in parallel, we can check GAG's functions more correctly. Our experience of parallel development convinced us that the adopted strategy is general enough to be implemented with other languages or extended with more advanced schemes in future. PROTOTYPING OF A REMOTE GAG RemoteGAG using RMI has been prototyped for remote use of the expensive server systems or distributed simulation over a LAN. The RemoteGAG will be used in conjunction with a remote visualisation like VRML. This leads to network distribution of computation and visualisation. For example, GEANT4 computation runs on a UNIX server, while an end-user controls it via LAN with Windows PC. Modiæcation of GAG to RemoteGAGwas minimum. The only one class GAGpipe of Java GAG handling the pipe connection between GEANT4 process and GAG widgets must be modiæed to a remote object. We have conærmed that the use of RMI is quite eæective for the implementation of a remote GUI, since GEANT4 itself and GAG's GUI parts are completely unchanged. We have tested RemoteGAG on a UNIXèLinux + JDK1.1.5è server and client on UNIX, Windows-NTè4.0, or Windows-95. The communication speed

6 FIGURE 2. RemoteGAG client on a remote Windows95 limitation was found to be torelable in the present design by a test using ISDN of 64KBPS and by a test connecting Naruto èrmi serverè and SLAC èrmi clientè. REFERENCES 1. Y. Oohata: Master thesis, Tokyo Metropolitan University, H. Uno: "Development of GUI for GEANT4", Master thesis, Naruto University of Education, Nagamatu, Uno, Obana, Yoshida, Asai, Ohata, Hamatu: "Experience of Prototyping Tclètk-based GUI for Geant4; an Object-Oriented Toolkit for Simulation in High Energy Physics" The Fifth Annual TclèTk Workshop '97 Proceedings, p187, Boston, USENIX 4. K. Ohtsubo: Master thesis, Fukui University, T. Kodama: Master thesis, Naruto University of Education, 1998