FRED Status

VRVS, 23/01/03 - R.Giannitrapani and M.Frailis
Contents

What's happening?

In the last few months we have worked quite a lot on FRED; in September we presented a first demo in which we were tring to achieve some main results
  1. A fast client for the HepRep format
  2. Functionally equivalent to WIRED
  3. Extendable by the user
At that moment FRED was a C++ application using FOX-toolkit for GUI and OpenGL for 3d/2d graphics; moreover it used an embedded Ruby interpreter to open the application to user scripts. But that was not really stable (we had some memory problems) and moreover left out an important issues: GUI extensions from the users. A typical example is the capability to add a button or a new menu voice binded to some user defined function (do you want to set invisible all the gamma? Do you want to have energy-based colors for particles or for volumes hits? Do you want to hide or to show some particular piece of the event? etc etc), but we wanted also to enable more complicate scenarios (Do you want to provide an exension to read fits file and visualize them together with the event, maybe with a dialog full of nice buttons or menus? Etc etc.).

We started to profile the program and to look at performance critical parts, finding them in the HepRep management (an HepRep representation can be VERY large for some event), the 3D/2D view managemnet, the CORBA connection. At the same time we realized that the GUI, on the contrary, is not a performance bottleneck in most of the cases.

So we operated a major shift on the architecture of FRED: now it is a Ruby program that load some C++ shared libraries for the critical part. Since now the GUI is built with scripts, it can be changed/augmented/extended easily. Moreover we solved our memory problem, the application seems more stable (and fast) and we are now able to add new features in a faster way (no compilation or linking time .. I want to try a new feature? I write it and try it)

A user can now write his own extension as small script that can be loaded in FRED .. if the script evolve in something big, he/she can also encapsulate it in a FRED plugin that can be loaded automatically at start of the application; as soon as scripts and plugins will start to pop up we can provide a repository for them .. and the most useful plugin can become part of FRED.

One important thing: a casual user DID NOT NEED to learn Ruby, to write scripts or whatever .. FRED will be provided with enough features to be usable at least as WIRED, with some specific features for GLAST. Only if the user want to customize or extend FRED than he will need to learn something of Ruby .. but also in this case we are working on the exposed API in order to provide a simple C++like one.

We have also started to use a graphic scene manager on top of OpenGL: the OpenSceneGraph This provide use with a faster 3D graphic (also on non accelerated machine) and a lot of new possible features, like text on the screen, transparency, HUD like information on the screen, animations etc etc

So, is it useful in some way? Well, at the moment we are aiming at providing the same functionalities of the Gleam GUI that all of you know and use; apart from doing that offline (no CORBA for now, but expect it in 1-2 weeks), functionalities are almost the same. You can pan the view, rotate, zoom, both with mouse or with keyboard shortcuts. You can save a Bmp screenshot or a PostScript one (true vectorial format). You can select a graphical object and see the attributes that have been attached to it.

For now the fillers mechanism (do you remember that?) are provided for just the geometry and the MonteCarlo data, but that should be enought for this beta testing of FRED .. if you want to help with suggestion to build fillers for digi and recon you are warmly welcomed ...

Ok, but can I try it?

Yes, althougth it is still in a very experimental state; but we would be very happy if people start to use it in their spare time to find out bugs, complaint about features and, more or less, help us in fine tuning both the interfaces and the features of FRED. Since we are actively working on it, the version that you can download now will change very fast and is lacking some major features, but it should be possible to have a stable version 1.0 in about one month, with your help.

At the moment we are packaging everything in orded to distribute FRED in a simple way; if you are impatient and a Windows user, please send me an email and I'll send you a preliminary beta .. otherwise for next week core meeting we will setup the new FRED web page with download/installation for both windows and linux. In the distribution we will put also some HepRep event generated by GLAST to test FRED. This is the only source format for now, but CORBA (do you remember it in September) is almost ready.

How I build HepRep events for GLAST?

If you want to generate new HepRep files (as told before no CORBA for now) from GlastRelease, we need some small changes in the future, but the HepRepSvc package has been tested this morning with GlastRelease and, after some changes, it works. You can checkout it from the repository, together with ZLIB (that will need to be included in the IExternal in the future) and the zlib external library from the glast ftp site, and used with G4Generator and Gleam by including it as a service in their joboptions (see the jobotions.txt in the test directory of HepRepSvc on how to use it). This will generate xml gzipped file with the events that can than be opened in FRED.

Note that this will obviously slow down G4Generator or Gleam; at each event the TDS is "dumped" in the HepRep xml file, with lot of information attached to graphical objects, and this take time.

Useful links