Hi Aaron and all,
I am not a fan of the "new formalism" despite the one hour lecture with
multiple integrals upon multiple delta functions :) but I think it could
work.
I think what Aaron did (and what I did in the white generator in DGen) is a
'white' spectra in the 5-fold phase space above the reaction threshold. Or
in more detail, electron scattering angle, electron energy transfer and
proton scattering angle in CMS frame are picked at random then all the
particles are transformed into BLAST frame. each event is physically
possible, not just a arbitrary combination of vectors in Blast LAB
frame. So I hope the deuteron binding energy constraint would not render
any of the events useless.
We (in fact Vitaliy first) also realize the role of Jacobians here. In
order to reproduce the event distributions that simulate what we observe
in experiment, we need to weight the events generated in "white" spectrum
by the product of Jacobian and cross section. Because for each individual
event, both cross section and Jacobian (I count two non-trivial Jacobians
for dee'pn, for the proton polar angle in CMS and the electron polar angle
in LAB). Zilu, please do let us know if I am missing important issues.
At this moment, genereting events in "standard" formalism in dee'pn
channel requires 5-dimensional lookup tables of cross sections and their
integrals. this makes the program very memory intense. It easily takes up
300M memory. To add Z-dependent spin angle and/or readiative
correction(which requires some perturb of beam energy)
would require even more degrees of freedom on top of these 5 dimensions.
This would make our computers constantly swapping and crawling. So I am
afraid MCEEP way of "generate events uniformly and weight each by cross
section" approach is anyway in order. The large acceptance of ours makes
it harder to implement such method.
About the smear by hand and skip reconstruction part, I am not sure.
Zilu and Simon, please correct me.
Chi
On Thu, 2 Sep 2004, Aaron Joseph Maschinot wrote:
>
> both simon and zilu have now both expressed belief that the new monte
> carlo formalism is not a good idea. i would appreciate it if others with
> similar experience would voice their opinions, too. particularly those
> who argued for the new formalism. i do not have the experience of having
> tried both possible formalisms, so i cannot comment on why is better than
> the other.
>
> as for zilu's comment, here is a little more detail about what the white
> electrodisintegration generator does. please comment on where the problem
> lies:
>
> arenhovel gives us data for the 41 structure functions in five variables:
> phi_electron, phi_proton_CMS, theta_proton_CMS, omega, and theta_electron.
> these five variables are sufficient to completely determine the entire
> cross sections. if addition, the data he gives us is over the full range
> of all of these variables for a beam energy of 0.850GeV.
>
> anyway, random "5-tuples" of these five variables are generated. for each
> such "5-tuple", it is only a matter of applying the correct kinematic
> equations to calculate the initial kinematics for the involved electron,
> proton, and neutron. (i won't write down the equations, but they exist
> and are well tested; DGen has in fact been using them since it was
> originally written). the only check you have to make on your "5-tuples"
> is that they result in enough energy and momentum transfer so as to
> breakup the deuteron (once again, this is just another equation that has
> already been worked out).
>
> i'm not sure what you meant by your comment about jacobians. for what i
> have just described, i do not need to calculate any jacobians. true, if i
> desire to generate "5-tuples" in different variables, then i might need to
> worry about this. however, these are the variables that arenhovel gives
> us his data in; we do not have data in any other sets of data.
> ultimately, no matter what we do, we're going to have to go back to these
> five variables to generate our results.
>
> please elaborate some more on why this method is flawed. i don't want to
> waste any more time on this code if it's leading to a dead-end. and for
> those of you who are in favor of the new formalism, please comment on why
> we should continue in this manner.
>
> thank you,
>
> aaron
>
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST