Beni, See mt responses below. -rtj beni zihlmann wrote: > Hi Folks, > I guess this is the correct mailing list to address this topic > (probably again). > > I write down here a few points I gathered while looking into the > digitization > of the FTOF detector but I am sure most of what I found is also true > for the > other detector parts. Before any of use can/should implement any > digitization > of his/her detector we need some clear guide lines otherwise we will > do the > work twice or more. > > 1) currently nothing really is done yet (to my knowledge) We do not do digitization in HDGeant. It is a design decision. For more background on this, speak with Matt Shepherd or Dave Lawrence or myself. > 2) the user function GUDIGI.F does not exist (yet). This > is the logical place to connect all the digitization routines of > all detectors to. Also in view of a future upgrade to GEANT4. It would be, if we were interested in writing ADC and TDC values in the output stream. We don't, so it doesn't exist. > 3) currently some very poor man's energy attenuation etc. is done > in the sequence of GUSTEP.F. This is the wrong place to do any > digitization part. Different hits should not be mixed already at > this stage. > Also, hit positions are not stored and other additional information > maybe > also needed like parent particle. The attenuation is done during the tracking process in hitXXX.c (general I have refused to write code (that actually does something in Fortran). Hits merging, thresholds, etc are done in the pickXXX() functions, also located in hitXXX.c. I would prefer it if you didn't try to go in and overhaul the design, as the present one is adequate for what it does. > 4) a lot of hard coded parameters are floating around that should be > defined > in a database (could be a simple file) and initialized at the proper > location > in the code. This would be a good thing to plan as a part of the port to the G4 framework. We really need someone who might take on the job of designing the parameters database interface and implement a set of reference classes for reading the values and maintaining the database. > 5) as we will use FLASH ADCs and Multi-Hit TDCs the exact functionality > of them and how the readout will work and what exactly is read out > is crucial > for the implementation of the digitization. In particular for > example how will > the pedestal subtraction be done on the level of the FLASH ADC in a > FPGA etc. ? All of that is upstream of the point where the MC data merges with the real data stream in the dataflow model. See http://zeus.phys.uconn.edu/halld/glueXmeetings/mtg-5-2004/halldmc-5-04.ppt, slide 8. > 7) the GEANT cutoff parameters for the particles and volumes needs > attention and > definitions in the code. The present defaults are found in the control.in file. At present only the vacuum needs special sets of cuts. People who know what they are doing can refine these, but for most purposes the defaults are ok. > 8) currently the whole MC code resides in almost just one directory. > In view of the future > massive increase in code we need a structure that helps us keeping > an over view. There are a couple of subdirectories (hitutils, gelhad). There could be more, especially as more people get involved in specializing their own parts of the detector. > 9) and many more points I am sure come to your mind that I have not > mentioned. > Very good, new ideas are always needed, and very welcome! Welcome to the team. Richard Jones
S/MIME Cryptographic Signature