Images from the JavaTracker and JavaEcal Applets

 

The JavaTracker and Java Ecal applets are tests of the usability of Java for accessing persistent HEP objects which are stored in an Objectivity/DB database.

We have taken the Irwin/Sijin ooTracker prototype C++ code, which simulates the central particle tracking detector in CMS, and converted it so that the tracker layers and hits are made persistent in an Objectivity database. Using the persistent hits, we have modified the code to allow the reconstruction of particle trajectories (tracks) in the detector, which in their turn are made persistent.

The Applet functions by opening the Objectivity database, extracting the tracker geometrical information, and plotting the positions of the detector layers. Tracker layers in the barrel region are colour-coded blue, those in the end-cap region are colour-coded red. The detector is shown in side and end projections. The intersections of particle tracks with the detector (hits) are shown in green. In the third image, reconstructed tracks are shown in white, and only those hits which are associated with tracks are plotted.

The pictures shown above are for a single event. The pictures at the foot of the page are for an accumulation of many events.

We have also used ideas from the Behner ECAL prototype C++ code to generate our own cluster reconstruction for the Ecal detector. These clusters are generated from Theta/Phi maps of the Ecal energy distribution. The map from an example event is shown below:

There are some limitations and problems with the Java implementations:

  1. We cannot access C++ objects from Java which contain array data members: these must be converted to Objectivity VArrays.
  2. Class names cannot contain an underscore character. This seems to be a problem in the beta version of the Java binding.
  3. The "shapes" of the Java and C++ objects must match exactly, otherwise access from Java fails.
  4. The Applet's paint method in principle requires the geometry, hits and tracks to be re-drawn. We don't want to keep opening the database to re-access the information required to re-draw, so we need to define another method. This has been resolved by defining an off-screen image buffer, and drawing exclusively in that.

The JavaTracker code.