Some Thoughts on LCD software futures

Since we will probably be seeing quite a shift in the manpower working on the LCD project over the next few months, I think it would be a good time to review the progress we have made over the last year.

Over the last year we have been developing software in both C++ and Java. Watching the progress/manpower ratio for the Java code vs. the C++ code has convinced me more than ever that Java is far more effective way of developing this type of software. A  huge amount of time from skilled software developers has gone into dealing with porting issues and subtle bugs in the C++ code, which does not directly relate to the goals we are trying to achieve. Furthermore the resulting code and its related support infrastructure (DEC etc.) seems too complex for the amount of manpower which we have, and poses a significant barrier to new people entering the project.

In comparison with far less manpower, the Java reconstruction effort has made rapid progress, and is easy to distribute and easy for others to start using and developing, and requires no complex, HEP-specific infrastructure.

Since we have already committed to switching from Gismo to Geant 4 in the next 12 months I think we should seriously reconsider the use of C++ in the project. Obviously I am not proposing that we rewrite Geant 4 in Java, but I do think that we could write a thin wrapper around Geant 4 which would enable all of the LCD specific code to be written in Java. I think this would greatly simplify our task of attracting new users and making it possible for them to customize the software to handle new detector geometries.

Note that this does not mean abandoning ROOT as a parallel analysis environment. We can still have both the simulation and reconstruction programs generate output files that can be analyzed using either JAS or ROOT. Nor does it mean introducing links between JAS and simulation code, in the same way that our current reconstruction and Java FastMC code is completely independent of JAS, we can write the simulation code to work either standalone or inside JAS (useful for event displays, debugging etc.). 

The block diagram below summarizes the software organization I have in mind.

An initial step in this direction would be to do a quick prototype of a Java interface to Geant 4. Finding someone with some prior experience of Geant 4 to help with this effort would be a great way to get off to a quick start.

Finally note that although I think using Java will vastly simplify our task, we still cannot do anything with no manpower. We need to put some serious thought into what manpower will be available to the LCD effort over the next 12 months, and how to use that effort.


Updated: Tuesday, January 13, 2004 by SLAC\tonyj