(G)UI status and developments

1. (G)UI status and developments Geant4 Workshop at CERN Oct. 02, 2002 Hajime Yoshida

2. Overview • (G)UI design guidelines reiterated • Mechanism of “interactivity” • Available (G)UI implementations • Recent developments; network • Summary

3. (G)UI Design guidelines • (G)UI shall not deteriorate the performance of the simulator • (G)UI provides user-friendly interfaces for • Steering the execution　of G4 • Help to code user mandatory classes; geometry, physics list etc. • Visualization, analysis • (G)UI must be able to cohabitate with rapid progress of • GUI tools • Script languages etc. • (G)Geant4 provides only front-end interfaces to specific UI implementations

4. Mechanism of an interactive session A concrete session must be derived from G4UIsession • Accept a command • Keyboard/menu/icon • Validate the command • Execute the command • Show the result if any • G4cout/window/widget • Above loop is steered by the session • aSession->SessionStart();

5. Loop and Breaks • Loop must be handled by aSession • PauseSession is called on • /run/breakAtBegin/EndOfEvent • /run/brealAtBegin/EndOfRun • User’s codes • External loop can do things in the method of • aSession->PauseSesionStart()

6. Internal States of G4 and User Interactions Geant4 accepts user commands whenever it is ready to accept them • Accepting user commands is absolutely under the control of the concrete class of G4UIsession. • The G4UIManager communicate with only one concrete class which will be notified about the state of Geant4 • G4 kernel doesn’t set the optional pause state. But it must be set explicitly by user codes. This mechanism provides the extra hook for interactive sessions.

7. Breakpoints for interaction • Breakpoints at the beginning/end of an event/run are provided by G4RunManager • pauseSessionStart method must be provided in the concrete session classes • Deeper breakpoints which might deteriorate simulator’s performance such as at every track/step will be invoked explicitly by user codes using pause method in userAction.

8. Available Implementations • All are derived from the base class G4UIsession • Interfaces/common • Interfaces/basic • Terminal/csh/tcsh • Win32/Xaw/Xmo • Interfaces/GAG • GAG/Gain • Interfaces/OPACS

9. basic • G4VUIshell is the abstract base class for • G4UItcsh, G4UIcsh • G4UIsession is the abstract base class for • G4UIXm, G4UIXaw, and G4UIWin32,

10. GAG and Gain • G4UIGAG/G4UIGainServer • Adaptive GUIs • Geant4 and GUIs are independent processes • Geant4 is invoked by GAG • Geant4 is the server vis-à-vis Gain • Communication via pipes or sockets • Private text-based protocol • Multi-platforms • G4UIGAG: Linux, Solaris, VC++ • G4UIGainServer: Linux, Solaris, Cygwin-g++

11. OPACS • Integrated GUI and visualization • scripting • Derived from G4UIsession • StartSession • getEvent and dispatch • PauseSessionStart() • Do things at breakpoints • Assistance of its own messenger

12. Sessions and Streams • Streams and buffers are managed by G4; global/management • G4couts are SetCoutDestination(aSession) in the constructor of the concrete session • When session==NULL, G4couts are out to the console • The destructor of the concrete session must do SetCoutDestination(NULL); • User can switch multiple sessions • For the omnipotent session which may control multiple sessions (GUI, visualization, analysis, for example) • For distributed simulation

13. Example of switching sessions • #include “G4UIterminal.hh” • #inlude “G4UItcsh.hh” • #include “G4UIGainServer.hh” • … • G4UImanager * UI = G4UImanager::GetUIpointer(); • G4UIsession * tcshSession = new G4UIterminal(new G4UItcsh); • G4UIsession * gainSession = new G4UIGainSession(); • .. • UI->SetCoutDestination(gainSession); • gainSession->SessionStart(); • delete gainSession(); • UI->SetCoutDestination(tcshSession); • tcshSession->SessionStart(); • delete tcshSession;

14. Networked utilization • Design issues for distributed computing and visualization • Server/client • In/out streams • Out-of-band input data • Secure data transfer • Logging/monitoring

15. JavaPVM prototype for GAG • Prototyped in 1998 • G4UIGAG front-end • Communication via RMI • JavaPVM for GAG • Daemon running at every host

16. Gain • G4UIGainServer front-end class • Text-based communication • Extensible to XML schema protocols • G4 is the server waiting a connection from Gain at port 40000 or higher • Not a daemon mode (need control terminal) • Solaris, Linux, cygwin • Gain has a control panel for each remote G4 • Java application runs on Linux, Windows etc. • Combined use with VRML viewer, the only available networked viewer at present

17. Gain for two hosts

18. Server client • Existence of a firewall • A server runs in a “public” center • A client may be in a private network/firewall • Same schema for DAWN and VRML under way • Secure data transfer • Use of the SSL • OpenSSL • Use of the SSH • Platforms • Winsock vs sockets; cygwin API

19. Out/In streams and log • In-band G4cout data can be socketized within the present scheme • Out-of-band data; CTRL-C etc. • G4cin issues • Dialog method • Logging or monitoring • Full session log or occasional monitoring • Save to a file remotely or locally

20. Secure Xfer of data; Use of SSH • SecureGain prototype • Use free Java SSH • Gain opens a SSH session • G4 is invoked via remote terminal • All data flow encrypted/decripted by SSH • Natural extension of GAG • G4UIGAG class • Efficiency ?

21. secureGain; ssh login • Ssh to a remote host (now localhost)

22. secureGain; session • Gain started

23. Secure Geant4? • Introduction of a common SSL for • Steering of execution • Visualization • Analysis • SSL wrappers • Stunnel • stone

24. Summary of vis-gui mini-workshop 2000 • There is an obvious requirement for Geant4 to fit into existing Interactive Frameworks. • Examples of Interactive Frameworks are: Momo, Explorer, AVS, the BaBar Framework, Gaudi, OPACS, JAS, WIRED, ROOT. • They each come with their own way of interacting with the applications inside. • We studied the requirements this placed on Geant4. • Geant4 already offers interactivity through intercoms (G4UImanager, several concrete G4UIsession classes - G4UIterminal, etc.); GAG uses this approach.

25. Wrapper/adaptor approach • An alternative approach commonly used is to wrap application classes directly with wrappers/adaptors. • Tools for automatic creation of wrappers exist or are in development, e.g., SWIG (for Python, etc.), JACO (Java Access to C++ Objects). • Conclusion: it appears that Geant4 is now sufficiently open that both techniques can be used but this remains to be tested in a real application; Geant4's C++ interface to the world needs defining and documenting. • In particular the G4RunManager can now be extended/inherited. • This would be sufficient for most frameworks.

26. We see today • Reservations which arise from the current dominance of the intercoms way of interacting: • the existence of G4messengers means that some intelligence has been built into them rather than kernel methods; • there is not always a one-to-one correspondence between command and kernel method; • there might be, or might come to be, functionality that is only accessible through intercoms, which would restrict direct wrapping techniques and other direct object oriented interfacing techniques. • there is a dual use of intercoms ((a) for inter-category communication and (b) for a command interpreter) and they might need distinguishing in future.