Hi Djam, Kris, et al, On Fri, 26 Oct 2001 01:28:31 +0200 (CEST) Djamel Ouerdane <ouerdane@nbi.dk> wrote concerning "Re: BB vertex question": > > Yes, you're missing something crucial. BrBbRdoMoule is the old > software which reads the ascii files made a long time ago by Yury > and updated from time to time. That is, not that often! > The calibration stored in the SQL db is handled by a completely > different software. The modules to use are: > > BrBbCalHitsModule to reconstruct calibrated hits (in time and energy) > BrBbVertexModule to reconstruct the vertex BrBbVertex > > Note: it's not BrBbRdo. If you have some software trying to get it, > you'll run into trouble. Shouldn't BrBbCalHitsModule really replace BrBbRdoModule, and BrCalHits replace BrBbRdo, so that we have a consistent naming? (not really a question :-) This obviously requires a class version bump to BrBbRdo (there, I've said it - don't make me repeat it). I assume that the present classes BrBbRdo and BrBbRdoModule are outdated and should not be used. Replacing those classes will have the benefiet that there is no confusion as to what code to use - a reoccuring problem in our collaboration, despite the hard work of many to document what they are doing as they progress. > If you want to get the vertex BrBbVertex, you should have this: > > BrBbVertex* vtx = (BrBbVertex*)eventNode->GetVertex("BB Vertex"); > > then: Double_t Z0 = vtx->GetZ0(); > Double_t T0 = vtx->GetTime0(); > Int_t method = vtx->GetMethod(); > > method can be: 1 -> bug tubes only, > 2 -> small tubes only, (highly recommended!) > 3 -> fastest tubes Steve, perhaps that is something you should put into modules/util/BrMultUtil? Also, you may want to put into packages/BrGlbPackage the use of BrBbCalHitsModule rather than BrBbRdoModule, at least until Djam renames it to BrBbRdoModule. > I haven't had the time to complete the instruction I put in > <brat_src>/scripts/calib/bb. But I'll give you here what you need > for reconstruction after the DB access is done: > > somewhere in your bratmain script: > > // ----- BB rdo module > BrBbCalHitsModule* bbHits = > new BrBbCalHitsModule("BB","BB Calibrated hit Module"); > bbHits->SetTreeOn(kFALSE); > bbHits->SetUseOldCal(kFALSE); // for backward compatibility with the old cal > bbHits->SetMaxTdc(3800); > bbHits->SetMinTdc(10); > mainModule->AddModule(bbHits); > > // ---- BB vertex module > BrBbVertexModule* bbVtx = new BrBbVertexModule("BB", "BB Rdo Module"); > bbVtx->SetTreeOn(kFALSE); > bbVtx->SetMaxTimeDiff(0.5); // (in ns) for outlier tubes > bbVtx->SetZOffBig(19.64); > bbVtx->SetZOffSmall(18.1); > bbVtx->SetZOffFastest(0); // I never use this one afterwards > mainModule->AddModule(bbVtx); These parameters should really be set per default, or read from the DB, but I guess you know that. > I insist on something: the BB calibration is now well under control > with the stuff I wrote. I encourage all the collab to use this new > stuff. Then, please do replace the old BB RDO classes with yours. A pledge to all developers: Please PLEASE remove unused classes from BRAT ASAP! Take a look in the README and TODO file for a couple of questions. BRAT is big enough as it is (~ 300 classes) and far too much of the stuff is obsolete and redundant. On Thu, 25 Oct 2001 19:54:20 -0500 (CDT) Kris Hagel <hagel@cyclotronmail.tamu.edu> wrote concerning "Re: BB vertex question": > Hello, > This concerns the BB vertex. Somehow I had missed how this was > going. Is there a reason that BrBbVertex does not inherit from > BrVertex? I made a bunch of noise about that some time ago that we > should have on BrVertex. As I looked at the BrBbVertex.h file, I > noticed that it has some extra information. But it should inherit > from BrVertex so that we have a common interface. If there is no > good reason for not inheriting from BrVertex, please change it. I second that. On Fri, 26 Oct 2001 02:59:19 +0200 (CEST) Djamel Ouerdane <ouerdane@nbi.dk> wrote concerning "Re: BB vertex question": > Hi Kris, > > Originally, when I wrote BrBbVertex, I've made it inherit from > BrVertex. But for some reasons I must confess I don't remember (3 > months ago :), there was something that created some problems and I > gave this up temporarily. In fact, we should rather revisit BrVertex > and move all the specific TPM stuff into a BrTpcVertex deriving from > BrVertex. I second that too. That is, make the following inheritance tree +---------------------------+ +---------------------------+ | BrVertex | +---| BrTpmVertex | +---------------------------+ | +---------------------------+ | ||:fPosition:BrVector3D | | | |:fVariance:BrVector3D | | ||:fTime:UInt_t |<----+ +---------------------------+ +---------------------------+ | | GetVariance():BrVector3D& | | GetPosition():BrVector3D& | | +---------------------------+ | GetTime():UInt_t | | +---------------------------+ | +---------------------------+ +---| BrBbVertex | | +---------------------------+ | | ||:fMethod: enum EMethod | | +---------------------------+ | | GetMethod(): enum EMethod | | +---------------------------+ | | +-------------+ +---| BrZdcVertex | +-------------+ All of these classes should ofcourse live in data/vertex, and have corresponding modules in modules/vertex. Now that we're on the subject of vertex stuff: The package modules/vertex/BrVertexModule should be rewritten and moved to packages/BrVertexPackage ASAP! We should also seperate out of the RDO module the vertex determination from the ZDC into a seperate module modules/vertex/BrZdcVertexModule. It should actually be fairly simple to do, since the code for that is very seperate from the rest of the RDO module. That would mean that the fZ BrVertex object of BrZdcRdo should disappear - again, causing a class version bump to BrZdcRdo (damn, I made me repeat myself - it will not happen again ... I think). This approach allows for much more flexibility than the current BrZdcRdoModule-do-it-all approach (i.e., it suffers from Fortrantitis), and will defently pay off. Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Fri Oct 26 2001 - 08:03:52 EDT