Re: TOFW - GBRAHMS, .cdat files and geometry in general. Dear Djamel (and others). I will like to comment on the discussion which in part has been on the list and in part by Djamel sending me his proposed modification to the geant setup. There is a good issue at hand here, but I have real concerns about the proposed solution which breaks existing code and concepts several places. The Hit structures that are output by the gbr2c.f have the general feature of looking having information about a.. Local coordinates in/out; where local coordinate are those relevant for being able to digitize the data into the raw data structures. For TOF slats these are to be given within slat parameters not the master volume (for TOFW in a panel (TFP1 #1,#2 #3 or #4) or in TOF1 TOF2 master. For others like the TPC they are given in the master active volume since this is the relevant volume. b.. This consideration have lead to the somewhat hard to understand coding / selection of Master/local volumes in gbr2c.f program. It is though completely consistent with Geant and the proper selection of volume for the master to local coordinate transformation of hits. c.. The slat number output from gbr2c.f for the TOWF is not strange; the proper setup was introduced in the December 12 version of gbr2c.f where each panel is in fact 21 slats such that the numbering scheme geantslat =1-84 (83) is equal to the actual slat numbering on the floor. (You somehow work with an earlier version). d.. The output files have in the start written out some information of which the only piece in fact being used in the name of the Hit structure . It can certainly be argued that these should have been the proper names as H1 H2 and TOFW rather than TOF1 TOF2 (historical) and TFP1. They also attempt to write out some volume information, which is though not used by any piece of code later except for reading. At some point way back I had thought this might be useful. Since it is not use the error message written out (when using the gbr2c.f stuff) can be safely ignored. It is obvious one needs the geometry of each panel in the PID analysis, so the right question to ask is how to get this, and not to change the geant description. As we move forward the geometry is in fact going to be accessible to analysis modules, not by reading the .geo files, but by requesting this from the Database. Likewise Gbrahms will get the information from DB not generate it by itself. This DB needs to contain information the about a.. Panels, position and rotation in the MRS, FS etc system b.. Slats in panel (and their relative position to the panel) c.. Slat geometry. d.. This all needs more discussion as part of the ongoing DB discussion and needs input. The raw data structures themselves i.e. the BrDigTof you will get in hand when reading real data are numbered 1,2,.. 83 in this years run and 1,2..~120-140 when the next set of panels are build. Thus making a splitting in the geant output files by sub numbering 1.21 in some sub panels do not make sense either. Though I have not seen your working versions of BrDigitizeTof I will guess that you now have special code to deal with the 4 different sets of 'input' hits (as we unfortunately also have to do in a few other detectors). My real preference and advice as the person responsible for overall coordination the Geant setup and interaction with other pieces of software is 1.. to output from the write_geom the position of the 4 panels TPF1,(volumenumber 1,2,3,4) to the .geo file - and you can name then TFP1,TFP2 at that point if you like. Add to the common block parameters ( e.g. tofw_xref, tofw_zref or zc, zc values) such this can be done Do not break the structure of panels and panel types, but maintain the structure in eg-tofw as is. 2.. Do not modify gbr2c.f 3.. Not all is obvious perfect, but one should not change what is already done unless there is a real good argument. 4.. If this does not give the information you need for PID analysis I think you should outline this to us. I will look forward to the next iteration and hopefully closure on this subject, so it can be checked into CVS, and used . You may also be interested at some point in a large set of simulated data (~150 cpudays) that exists for AuAu MB and central collisions at RCF. /brahms/data01/simu/gbrahms_output/sim_450.cdat and up. Generated by the brmdc code (the scripts and .geo etc files are all in ~bramreco/brmdc/gbrsim directories. Best regards Flemming ------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax: 631-344-1334 videbaek@bnl.gov
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 15:15:17 EDT