Where we are at the moment with LArG4/LArG4TB: ============================================== LArG4 and LArG4TB are two packages that provide Geant4 simulations for the ATLAS LAr detectors in the full ATLAS geometry as well as in their geometry used for the testbeam. Instructions are given in documentation provided in both of the packages. Both packages reside inside the larger package: LArCalorimeter. LArG4: ------- LArG4 is a package for Geant4 simulations of the LAr Calorimetry in ATLAS, i.e. with LAr detectors in the full ATLAS geometry. it can be checked out from the Atlas cvs repository at Cern. LArG4 relies on the packages: GeoModelKernel (which resides in the larger package: DetectorDescription) and LArGeoModel ( resides in LArCalorimeter and also contain useful documentation). And, of course, it also relies on Geant4 and a Geant4 visualization tool (we use DAWN). Once those three packages have been checked out, and the Geant4 environment has been set up, LArG4 can run stand-alone and produce Geant4 simulated events. LArG4TB: --------- LArG4TB is a package for Geant4 simulations of LAr detectors in their testbeam geometries. LArG4TB relies on LArG4. Once LArG4 is up and running, LArG4TB can be compiled and run. LArG4TB contains sub-packages for different testbeam setups which are maintained by different people. Code exists for Barrel, Emec, FCAL, HEC-alone, EmecHec (2002 comb. testbeam). Some of that code is part of Athena releases, but lots of it is not. Present state of the code available via cvs: --------------------------------------------- Pavol explained that the most up-to-date code for EmecHec at the moment resides in the stand-alone version of LArG4TB. "Stand-alone" here means that it is not run within the Athena framework. The code can be checked out via cvs, but the full code is not part of a proper Athena release, because originally there were difficulties of storing some information within Athena. He is convinced however, that any modifications and contributions to the stand-alone code can be implemented into Athena. Bill Seligman's documentation on LArG4 explains that LArG4 is, at the moment, maintained both as stand-alone and also within the Athena framework. The stand-alone version makes it easier to do fast extensive development of the code, however the final aim is to run it in the Athena framework, so eventually the stand-alone maintenance will be phased out. Present status of the packages at UVic and possible strategies for proceeding in the next few weeks: ------------------------------------------------------------------- Ashok is in contact with Bill Seligman about how to run LArG4 and ultimately implement LArG4TB into Athena at UVic. He feels that he needs a bit of time to get this properly sorted out. Ian and Margret have checked out LArG4 and LArG4TB. The installation, compilation and running of LArG4 provided no problems, given the detailed documentation available. LArG4TB checked out and compiled ok, but did initially not run. A line in the code needed to be fixed in order to get it going. Once that was done, both Ian and Margret managed to produce EmecHec events and view them on the screen. So, we should have the most up-to-date code up and running at UVic now. The LArG4TB simulation produces an Ntuple, which (among many other things) contains the energy deposited in the LAr on a cell by cell basis. It also contains the energy deposited in HEC Cu plates, but only on a plate by plate basis. Margret had looked at the code earlier on and found that retrieving the cell information for hits in the copper is not trivial, because crucial geometry information is stored for the LAr hits, but not stored for the Cu hits. There are two ways to proceed from here: 1) take the existing code to the stand-alone HEC geometry and apply extensive fixes to store the geometry information for the Cu plates. The fixes will not be trivial, because some of the code relies on the absence of geometry information to identify a hit as to be in the copper. 2) There is another geometry coded by Gaiane Karapetian. Its code looks much cleaner and it is likely easier to obtain cell information for copper hits. That code however is for entire wheels and has a different naming convention (actually, a nicer one), which means that the geometry will have to be modified for the testbeam setup and there will quite likely have to be fixes in other parts of the code to accommodate the different naming convention of the Geant volumes. It might take a little bit of mulling over to decide which road to take here. For the moment, Ian is just familiarizing himself with the actual running of the program. Margret will take him through the main routines and explain to him what they do. She thinks that the very first definite steps that need to be done are: a) put the code into the cvs repository at UVic. and mirror the MySql database at UVic, so we don't have to rely on Cern. b) fix the bug that prevented LArG4TB from running in a proper way, such that it could run anywhere else. c) Run the code with Gaiane's detector description and see what the Ntuple output produces - even though it puts an entire wheel into the little H1 cryostat (not sure how it even gets away with that, but it does), it would be a fairly straightforward test to see what is available within her geometry. that study will likely solve the question as to whether to proceed via road 1) or road 2). d) Have a look to see what makes the LArG4(TB)Sim base of the code, which is used for running in Athena, different from LArG4(TB)App, which is used for running stand-alone. To work through these points properly will probably take a week to 10 days. After that we'll choose road 1) or 2) (or, as another option, one person per road?), which will could likely take 3 weeks, which brings us to the end of June. Our final interest is in the separation of hadronic and e.m. energy within a shower. so additional code will have to be written to separate the two. (another 2 weeks?) Once that is done, simulations will have to be done to see what results these changes in the code tell us (another few weeks - it will take some time to generate events and look at them). Well, and that I suppose takes us into the late summer....