Let me inject just a little based on the end of Christian's message. In the spirit of AliRoot, I took all of the GBRAHMS stuff last year when I learned of it during the ROOT workshop and made them into AliRoot type objects with the lofty goal of eventually using this to accomplish the benefits Christian stated at the end of this message. However, the statement several times has been that we have a GBRAHMS that works and we have many things to do that are not working yet and should concentrate our efforts on them. That makes sense to me as the only real issue here is that GBRAHMS is written in the "wrong" language making some of the interfacing difficult and we obviously have ways (imperfect perhaps) to deal with that. On the other hand, as I mentioned, I have laid out an infrastructure based on GBRAHMS (release March 1999) which is not far from ready to start debugging (as well as update to current GBRAHMS status with all of the new detector details). There are ROOT objects for every detector as well as the beampipe and cave and FS and MRS etc. I say all this only in case we decide all important things are done and we have time to spend on this so that whoever does it would not start from scratch, but might find what I did useful to get a head start. Kris Christian Holm Christensen wrote: > Hi Flemming and others, > > On Tue, 18 Apr 2000 09:08:20 -0500 "Flemming Videbaek" ?videbaek@sgs1.hirg.bnl.gov? wrote: > ? Let me comment rather strongly on this > ? > ? - I am very strongly against any expansion of use of Zebra files, and > ? coupling of code to cernlib in any part of our software except for > Geant. > > Oh, I agree. The only reason I asked, was because I wanted to play > around with the putput from gh2root, and see if it was worth trying to > incorporate these features into BRAT or similar. > > ? It does not benefit what we are doing. There is in fact no such > ? thing as a standard Zebra way - zebra describes the packing of > ? records but not their content. > > I thought at least GEANT had a standard way of writting on ZEBRA > files. > > ? I have also had little luck with the root gh2root though this was > ? back in time. > > Hmm. Just playing around I must say the generated library is _very_ > nice. A nice set of TTree's is created, and the format is extremly > intutuive. That's why I'd like to apply it to `real' GBRAHMS data. > > ? On the eventfile format I will much rather go in the direction of the OSCAR > ? format which has been implemented for nexus, and could easily be done for > ? fritiof 7.02 This will bring things in line with further developments of > ? even model/tgenerator code by several theorists. > > Oh yes. OSCAR is very nice. The only problem is, that the output is on > a plain ASCII file. That takes up too much space. Rather, it should be > some binary format, but then you're ofcourse likely to get into > trouble with formats and so on. > > Is there any kind of `after-burner' on VENUS and FRITIOF to make OSCAR > files out of the ZEBRA files? > > Let me state my deper laying motivation for all of this: > > Looking into AliRoot from the Alice experiment at CERN, in became > apparent to me, that it's almost trivial to create a ROOT wrapper for > GEANT Fortran77 calls. In fact, it should be almost trivial to make a > abstraction layer for _any_ detector simulation library in ROOT. (Sort > of similar to what has been done for Event Generators - see library > libEg.so and web-pages http://root.cern.ch/root/html/EG_Index.html, > http://root.cern.ch/root/html/EGPYTHIA_Index.html, and > http://root.cern.ch/root/html/EGVENUS_Index.html.) > > The benefiet of incorporating the detector simulation into an existing > ROOT based framework (like BRAT) is tremendious: > * The geometry is already there for later steps. No need to have > intermediate ASCII files laying around. > * The Event generator step can also be fully incorporated into the > framework, giving the user the oppertunity to compare > simulated/digitized/reconstructed data to the output from the > model. > * Digitization can be done on the fly, so no need for intermediate > simulation files, if so desired. > * Visulasation becomes extremly simple. > > In the case of BRAHMS, there are a few difficulties, Namely the input > formats from Fritiof, Venus, RQMD, URQMD, and Nexus. The output format > would ofcourse be a ROOT file. But otherwise, it should be straight > forward to implement GBRAHMS in a abstraction layer in ROOT for > GEANT. > > Cheers, > > Christian ----------------------------------------------------------- > Holm Christensen Phone: (+45) 35 35 96 91 > Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 > DK-2200 Copenhagen N Web: www.nbi.dk/~cholm > Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue Apr 18 2000 - 15:13:19 EDT