> ADC values = [ADC channels]
> Energy Deposits= [????????????]
MeV ? Note that the monte-carlo truly spits out energy loss in a detector.
The ADC part is modeling done on top of that, adrian is taking care of
that. Charge is merely a conversion after that. So let's wait for
adrian modeling of MeV->Light Output (which is calculable) and then we can
convert LO to adc assuming that the gains are linear (in light output, not hv)
> where we are going. As a student, I would really like the analysis meeting
> be a place that I could learn how to do things, what is available to do
> what, rather than a one hour brush through of plots I have already seen
> in the counting bay.
We have discussed this and I think that often this has indeed been the
case. Essentially these days the working "meeting" is moved to the
counting bay. It almost occurs daily and there is definitely contact. We
should use the conference space there if there are more people.
Don't forget that the analysis meeting is there also to upate other people
of what is/has happening/ed. But If people are not there, there is no
point. Not everybody is in the counting bay at the same time but I also
think that we have too little overlap to meet regularly. I'd like to hear
other people's opinions on this.
At this moment there are simply too many issues we are facing, and
hopefully we are able to come up with solutions that will last. I do not
know of a realistic way of doing this remotely.
> Finally, since I already typed so much. WE NEED MORE COMPUTERS. last a few
> days, I literally have to beg for computers in the couting bay. It is hard
> to work on library if I don't have access to a computer. :)
I (partly) disagree. The online crunching load is not too big (total of 2
cpu spuds) with maybe 1 other spud of root sessions. So there are 6 (at
times 5) spuds on average free. I can't believe we are continuosly running
blastmc, but true we've had to recrunch a lot of data once (took < 1day)
at which time the spuds where almost unavailable. I almost always find
spuds.
At any rate, the online crunching will soon be automatized (that needs
some slow stepping...) and will run on dblast13,dblast14 (as per cc
suggestions). The other part is that we may need a few super-fast machines
if (and I think the probability is non negligible) we will have to
recrunch a lot of data. But that is a larger discussion, not for now.
>
> Chi
>
> P.S.
> Since a lot of these units are used in TBLDetRecon, following is the
> convention enforced in v3:
> Get**tdc(): returns tdc in channels
> Get**t(): retruns tdc in channels, offset corrected
> Get**time(): returns time in ns, offset corrected, time of traveling of
> light in paddle corrected
> Get**adc(): returns adc in channels
> Get**e(): returns adc in channels, pedestal subtracted
> Get**energy(): returns energy deposit, by multiplying e() by adc scale.
> whatever it means
>
> > >I don't want to sound bitter, but it is obvious that people that
> > >are working on codes should meet periodically and discuss the issues
> > >of the day. This regularly does not happen.
> > >
> > >That was the point of analysis meetings. There is where you can ask
> > >these questions and where such coordination can easily occur. E-mail
> > >communication is of course fine, but there is no point in complaining
> > >about things that could have been easily found out by discussing in
> > >person. Unless we pretend to have telepathic abilities and are able
> > >to guess what each other is doing.
> > >
> > >
> > >
> > >
> >
> >
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST