Re: GBRAHMS libraries

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Tue Apr 18 2000 - 13:42:17 EDT

  • Next message: hagel@comp.tamu.edu: "Re: GBRAHMS libraries"

    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 - 13:44:57 EDT