dear cz, as
> 3rd. I think the booking of spin information should be otherway arround.
> instead of the 6 bits, we should parse them in our program and book
> pe/pz/pzz with maybe another flag for 1-state/2-state transition. It takes
> three floats for both the sign and magnitude, instead of 6 integers and
> 3 (or 6 polarization is different for different states). It saves torage
> and most importantly, it is more intuitive when doing analysis. Correct me
> if I am wrong.
you are not wrong of course. Either way, we should make a decision at some
point. Frankly, my goal is to a have a simulation of polarized data soon
for all the running conditions: copper, plexiglass, inbending field, exit
foils, everything. It seems that adrian is close to it which is good. We
could share results.
I don't care how the spin bits are handled right now, we'll be practical
first. We can always make the decision later. To help debug our experiment
and understand our asymmetries (0 or not) we also need root histograms of
expected asymmetry in L/R sectors vs various variables. We have a theory
curve vs e- angle (ideal kinematics). But we can compare data also to the
average asym as a function of vertex position, tof number and so forth and
for that you need the montecarlo to do the averaging.
About spin bits data/mc:
The state 1-6 info is in principle a check of the data, assuming of course
we have "readback " of the injected states. Right now we "write" I inject
1, 3 or else, so of course it is not much of a check.
Using the 6 states for H/D is also the most flexible thing to do in terms
of polarization schemes. You'll never go wrong. You'll never need to plug
in "pzz=-1 or -2" or "pz=0.5" in the codes. Note that in the data these
bits are written at the input register, which only accepts 0 or 1, and
hence you can't use a single bit to define the tensor pol. The same scheme
is then also used in our charge script, which handles scalers and of
course must take spin info from the experiment status bits.
True this is a bit brittle (we had a sign error until 2 days ago as you
have to keep track of various sign/array-indexing conventions, albeit this
was not a critical mistake), but it is the way it is done. It works now,
so I'd not worry about it. However you will not fix it by using the 3 mc
variables (pe,pz,pzz) in reconstruction. Actually, you can only add
problems later on because your value for the polarization will depend on
the coding, as a function of time, while the state1-6 bits depend only on
the H/D physics.
Bottom line:
_ state1-state6 is more "linear" according to me, I prefer it (one vote)
_ pe,..pzz is fractionally more economic
_ we will decide about it one day. This can't be weeks of work! but not 5
mins either: if we use state1-6 it'll have to go to the mc input file
- for now, you guys do whatever you want/prefer. I really don't care. I
only want to see the plots vs the data.
> 4th. It would take me a few days to implement and debug a polarized e-p
> into DGen. But before that, I have to say I am a little confused by epel.
> There seems to be 3 epel: one in fortran and two in C/C++. It would take
> me some time to read the makefiles to single out the one in action and
> understand how to call it from DGen.
I think adrian answered this already.
About adrian's question:
adrian: make sure your (mc) option is switched when you run your lrn.C
Just make a mylrn.C and see what's going on. Use rawgets to see that
the mc info is indeed written in the coda file you feed to the lr scripts
Then it should be easy to understand why it is not written to the lr file.
Then we'll hand merge your changes to the online lrn.C
If the problem is with the library (you think) and you can't solve it, let
me have it.
> Chi
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST