Hi Hiro, Steve et al,
This is a change I made a long long time ago (6 months ago or so). I
believe I sent a message to the list back than.
To calm you down Hiro, this has absolutly no effect on anything, since
channels that are not used (instrumented) are not used (not set by
BrRawDataInput). Anyway, the actual number defined in BR_SI_CHAN_MAX
is irrelevant as you should always get the number of currently
avaliable channel from a geometry database (at the moment
DetectorParameters.txt), that is as
BrParameterDbManager* paramManager = BrParameterDbManager::Instance();
fParameters = (BrSiParameters*)
paramManager->GetDetectorParameters("BrSiParameters",
GetName());
Int_t nRows = fParameters->GetNoRows();
Int_t nRings = fParameters->GetNoRings();
Int_t nSingles = fParameters->GetNoModules();
(taken from BrSiRdoModule). Also, you'll use the ring/row map in the
database to figure out wether a detector is marked as active or not:
BrParameterElementManager *manager =
BrParameterElementManager::Instance();
fCalibration = static_cast<BrSiCalibration*>
(manager->Register("BrSiCalibration",
BrDetectorList::GetDetectorName(kBrSi)));
fCurrentRing = fCalibration->GetRingMap(fCurrentSingle) ;
// If the ring map says this si is bad, skip to next
if (fCurrentRing < 0 || fCurrentRing > nRings || fCurrentRing > 100) {
if (DebugLevel() > 15)
Warning("Event", "Ring map says si %d isn't on",
fCurrentSingle);
continue;
}
(taken from BrSiRdoModule). BR_SI_CHAN_MAX just indicates a size to
the ROOT I/O system.
On Fri, 27 Jul 2001 17:27:06 -0500
"Stephen J. Sanders" <ssanders@ku.edu> wrote
concerning ": Re: BR_SI_CHAN_MAX":
> Hi Hiro,
> In all fairness, although I did not make the change, I was aware of
> it. My understanding is that this indexing should eventually
> facilitate getting the Si/Tile parameters into the MySQL database.
The reason this is a constant and not a parameter, is so that BrSiDig
has a constant size and can therefore be put in a TTree.
This is obviously not the optimal solution. I'd personally prefer
something like BrMultRdo - that is a container with a nested class
representing a single channel, an instances of that in a TClonesArray.
In that way the number of channels become truely dynamic, while still
having the flexiblity of TTree's, and, I believe, actually space
saving.
There may be slight overhead, since we allocate memory for BrEvent at
each event, rather than reusing the memory allocated once. I'm not
sure how we could change that behaviour, but it seems like a thing to
do at some point (but not now).
> Regards, Steve
>
> Hironori Ito wrote:
>
> > Who the hell change this number (BR_SI_CHAN_MAX)??? It is now set
> > to 288 because the person quoted in the code as "There can be a total of
> > 288 channels from the silicon array. (6*6*8=288.)" . Who ever did
> > this. You are wayyyyyyyyyyyyy wrong.
Well, the number used to be something like 252 (36 wafers * 7 slices /
wafer), so I enlarged the number assumming all 6 rings where
instrumented with 6 wafers and each wafer had 7 slices + 1 temperature
read out, giving a total of 288 read-out channels.
Now obviously I didn't enlarge the number to allow for the full array
(to +/- 50 cm) was fully instrumented, which would probably give a
number like 576 (= 12 rings * 6 wafers / ring * (7 adc + 1 temp)
readout / wafer). I think why I didn't do that was that I was my
understanding that there was absolutly no plans to extend the Z
coverage beyond what is there now.
> > Please do not change those numbers unless you are hardware persons
> > or instructed by the hardware persons. (The fact is that there
> > can be up to 576 channels for silicon.) Anyway, DO NOT CHANGE
> > ANY hardware related number unless you are the person who are
> > setting up these detectors. Please!!!!!
Well, I changed the number (as I said a long time ago) to allow future
upgrades with out breaking the backward compatiblity (that was before
ROOT 3 schema evolution mind you), so I really don't see the harm in
that. If it has caused you some headache, could you describe in more
details what seems to be the problem, and I may have a valum for you.
> > (NOTE: Do not change 288 to 576)
Out of curiosity: How do you get that number?
Yours,
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 2b30 : Sat Jul 28 2001 - 09:35:07 EDT