Hi, guys,
First of all, let me sum up the convention used for the moment following
Aaron's example:
distances = [cm]
times = [ns]
TDC values = [respective TDC units](channels)
angles = [rad]
magnetic field = [kG]
energies = [GeV]
ADC values = [ADC channels]
Energy Deposits= [????????????]
I think we are pretty strict in using rad instead of deg simply
because it is the units used by C/C++ libraries. Functions are provided
to retrive track parameters in deg.
Adrian made a point. the ADC units is still undetermined. if I read
blast.sc_cal. it has a scale of 50fC/channel. but it still have to be
calibrated like the TDC scales if we are going to take them seriously.
blastmc inherits cm from Geant and by sharing a blast.geom, BlastLib gets
cm for length. using mm will cause a lot of *10 at the set up of geometry
objects, and seems C=30cm/ns is a popular choice. :)
Finally, reconstruction uses -PI/2 to 3/2PI for azimuthal angle. since
this is pretty mush the only thing that would work for phi fitting.
I think Chris is right. on the issue of BlastLib developement, all key
players have been in constant contact all the time. Aaron is available
whenever Chris and I have question with the geometry and Chris and I talk
almost on daily bases, in the counting bay, with a event display running.
it prooved to be very effective and we found and solved a lot of problems
that way.
So far, time to distance codes provided by Doug and Tong interface with
the rest of the library in an almost seamless manner. I do not see needs
to modify them from my point of view. If experts like Doug and Aaron
think it should be changed, then let s change it.
However, I would like to see the analysis meeting to be more detail
oriented than just presentations of results to the "rest" of collaboration.
presentation of results should be promoted to operation meeting or
something alike, so that higher management level knows where we stand and
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.
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. :)
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
On Fri, 27 Jun 2003, Chris Crawford wrote:
> hi tancredi,
> i hope you don't have to be bitter. chi and i have been doing the
> major development for BlastLib2, and have been in constant
> communication, and usually in accord. also aaron has been discussing
> the geometry with me all along, and most issues have been resolved in a
> timely manner.
> i am still under the impression that the analysis meetings have been
> meant to present analysis results to the rest of the collaboration, and
> divy up remaining tasks. we have been getting together in 'working
> meetings', usually in the counting bay, to resolve these trivial
> compatibility issues, and to review the performance of the
> reconstruction. plus, most of our development is now done at bates,
> where we can communicate in person.
> ps. the version 3 geometry is almost ready to be merged in. i just
> have left to convert the ~150 geometry graphics calls in nsed, and then
> do a finaly debugging. (of course it will only work with new wc
> calibrations).
> --chris
>
> Tancredi Botto wrote:
>
> >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