Hi Aaron,
so I guess I need to reply to this one. in short, the
[chg(0,0) + chg(1,0) + chg(0,1) + chg(1,1) + chg(0,2) + chg(1,2)]
part is the total of useful charge. the definition of useful is: target
defined, spin bits are in one of the 1/6, 3/4, 2/5 pairs. these part of
the charge is relevant in terms of asymmetry.
the part:
[chg(0,4) + chg(1,4)]
does not impose the above constraint. therefore the extra 0.5C per run.
Presumably this 0.5C comes from the instances when target switches from
one state to another. 0.5C out of the two three hundred C per run reflects
the "efficiency".
Sorry it is confusing, the thought led me to such a definition was:
anyway one can add the "useful" charges up to get the total, so making
chg(0,4) a copy of the sum does not contain more information, while making
it the total charge gives some false satisefaction of non-degeneracy.
relevant code is in TBLEpicsRecon.cc line 513 to 577. the procedure
adopted is:
s1=s2=0;
if (target defined) s1=state_1, s2=state_2;
if (helicity defined)
charge_matrix[helicity][s1][s2] += current*dt
in the end, charge_matrix[helicity][0][0] go into chg(0,4) and chg(1,4)
and charge_matrix[helicity][i][j] go into one of chg(0,0) and so on.
Chi
On Mon, 8 Nov 2004, Aaron Joseph Maschinot wrote:
>
> in the 'chg' ntuple inside of the 'flr' files, does anyone know why the
> entries for the total charge in each helicity state do not equal exactly
> the sum of the charges in the respective target states? they always are
> about 0.5C off for each run that i've looked at.
>
> in other words, why is the following true:
>
> [chg(0,4) + chg(1,4)]
> - [chg(0,0) + chg(1,0) + chg(0,1) + chg(1,1) + chg(0,2) + chg(1,2)]
> = 0.5C
>
> shouldn't they be equal? is this due to roundoff error? am i messing up
> somewhere? if they are different, which one is the "right" one?
>
> thanks,
>
> aaron
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST