Hi, all:
The Monte Carlo materials problem, at least, can be readily checked by someone else. Open the file blast_init.f inside of blastmc/ and check out the subroutines UGMATE and UGTMED. All of the materials used in BLAST are defined in UGMATE while all of the media are defined in UGTMED.
So what is the difference between a material and a medium? Glad you asked (well, not exactly). A material is a listing of elemental composition (and relative proportions) along with overall density for a particular substance. A medium, on the other hand, is a material along with particle propagation properties (such as maximum step size, maximum energy loss in a step, etc.) You cannot define a medium until the corresponding material has been defined, and for any single material there may be many different media. For example, the aluminum in the target walls and the aluminum in a chamber's chassis are the same material (aluminum) but different media since the max allowed step size in the target walls is very small (since the walls are so thin) while the max step size in a chamber's chassis is larger (since they are not so thin nor do we really care about particles passing through them).
Anyway, if you have bothered to read to this point, then you have probably expended the same order of magnitude of time that it would take to check these two subroutines. They are not very large and, like nearly all of blastmc/, are very well commented (pat myself on the back). Additionally, they do not further reference any other subroutines or external files. I encourage someone else to check these routines since blastmc/ (even after all of Tim's great work is setting up its skeleton) was too large of an project to put into the hands of any one person.
The Chi/Chris combination worked really well for the reconstruction since 1) they both are excellent programmers and 2) having multiple people working on it let them check each other's work. Additionally, Vitaliy and Nikolas both checked over Chi's fabulous work on dgen. However, as far as I am aware, no one else ever checked my work on blastmc/, at least not at anything but a superficial level. I wouldn't be surprised if there were one or two errors in blast_init.f and blast_proc.f. I don't think that there are any with the materials, though.
Aaron
-----Original Message-----
From: BLAST_Anaware-owner@rocko.lns.mit.edu
[mailto:BLAST_Anaware-owner@rocko.lns.mit.edu]On Behalf Of Chi Zhang
Sent: Tuesday, January 10, 2006 11:48 PM
Cc: [BLAST_ANAWARE]
Subject: Re: Analysis meeting on Wednesday 2006/01/11
Hi
I m having a pretty bad cold so would like to be excused tomorrow. but I
do have answers for a couple questions raised.
> +Verification of material budget
this is not an answer, but I have no problem betting my money on Aaron's
implemetation of the materials knowing him personally.
> +Does reconstruction of MC with all switches off reproduce input?
yes ofcourse. this is the case since the reconstruction first started
running in 2001? and has been true ever since, maybe only except a period
of time when Aaron was implementing the inversion of the 3rd order time to
distance relation. In fact up till late 2002 when WC started to give good
signals, MC was the main way to debug the reconstruction.
> +Compare reconstructed unradiated-MC with reconstructed
> radiated-MC. Can this be done for the same seed on an
> MC-event-by-event basis?
there is no need for two MC with same seed or not. the input from DGen is
logged in the ntuples under the names [tpfzq]m[lr].
flr->Draw("pwl-pml","...")
gives the deviation of recon'ed momentum from the "true" value. The energy
loss of deuteron is calibrated this way.
> +The obtained parameterizations of dp,dtheta,dz(theta,p,ID) can be
> applied event-by-event to the analysis reconstruction.
Is there a point to do this for e+-, pi+- whose energy loss is so small?
if you do it, you ll find youself parametrizing 0 anyway.
Also, in a discussoin with Nick, we came to the realization that, if the
analysis is done by comparing "reconstructed monte carlo data", then no
energy loss correction should be applied to true data because the effect
is already simulated in the Monte Carlo. if we look at the analyiss
channel by channel, we can find:
1. edel: e-loss only affect event selection NOT ANYWHERE ELSE, and can be
readily corrected.
2. epel: no comments, leave it to experts, but do not think MC or eloss
play an important role.
3. e'p: e-loss needs to be corrected before comparison to MC because the
white MC method skips reconstruction. but the e-loss correction is masked
by tracking systematic error anyway.
4. e'n: neutron is included in this discussion anyway, electrons are not
affected by e-loss anyways. it does use white MC.
5. e' inclusive, compare data with MC with e-loss folded in. do not
correct data. electron e-loss negligible anyway.
6. e'pi: both particles have negligible e-loss, MC has e-loss too, no need
to correct data.
7. e' from proton: same as 5.
When one calibrate for the kinematic correction, it also must be
recognized that some MC already have e-loss simulated and care be taken
that it is not double corrected.
Chi
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST