Re: [BLAST_ANAWARE] new monte carlo formalism

From: Zilu Zhou (zzhou@ridgefield.oilfield.slb.com)
Date: Fri Sep 03 2004 - 10:36:18 EDT


Michael,

please do not get me wrong, we (or i should say i) did it at nikhef about
10-12 years ago. as a matter of fact, most of our nikhef publications were
based
on this monte carlo and thanks to Igor who converted my vax codes into sun.
of course in my opinion, this was the only monte carlo to go for large
acceptances,
in contrast to mceep which was only suitable for spectrometers in msr
acceptances.

actually, i felt pity for past monte carlo discussions at blast. and
i knew such a discussion would occur just like this some day at blast.
i feel encouraged to see this discussion started a little bit sooner than
i anticipated. but this is good for you to start today (or precisely
yesterday).

of course, i am now very conservative as like bitten once by a snake.
i do not want to argue with you whether this is "trivial" or that is "easy".
i believe if i could do it (even 10+ years ago), then so can you.
obviously, as i said yesterday, the devil is in doing it. it is my interest
to see you doing it right, so my discussion would be in making all the
spectra as "white" as you can, especially those relevant to the cross-section
and making all the jacobians (not just one and trivial) right when you
make the usual "short-cuts".

at the end, it is all the 18 f's in 3 dimensions for 1 beam energy and perhaps
for 3 or 4 different models, plus 2 more dimensions to make it 5-fold and with
additional vertex distributions (just to be cute) in constructing
cross-sections.
it should be kind of neat. note 1 beam energy only, this is because
Hartmuth's f's contain half mott (or one of the 2 alphas). [for your benefit]

one last comment for your benefit. it is not the mott cross-section term
which is monotonic in q^2 giving troubles, it is all the f's made the
quasi-free ridges
and dips which give troubles for the interpolation of cross-sections and
asymmetries.
in the past, i found "linear" was safer but not accurate, "spline" was more
accurate
but not safe. but hey, whichever way, by now, you can do better.

peace and success.

Zilu

At 02:31 AM 9/3/2004 -0400, Michael Kohl wrote:
>I'm one of the people advocating the discussed method. I agree with Simon
>that it is sort of "poor man's Montecarlo", however it is by far more
>efficient for the primary goals of extracting physics observables like
>e.g. G_En.
>
>About the binding energy issue (which is equivalent that deuteron
>disintegration happens only above breakup threshold):
>There is the possibility to generate the electron in the coordinates
>(W,Q^2,phi_e) instead of (omega,theta_e,phi_e). In this way one can
>require W > W_thr (= M_deut + 2.2MeV) and generate up to some W_max.
>The above coordinate transformation involves one (trivial) Jacobian.
>
>
>I have one more difficulty with the "5" dimensional phase space. In fact,
>the deuteron disintegration cross section has five dimensions though,
>however two of these dimension are trivial as they are related to the
>electron only and characterize the "leptonic" vertex, quantifiable by the
>Mott cross section and kinematic factors or "virtual photon
>flux and polarization" and exactly/analytically calculable for each
>generated electron). The "structure" of the cross section is entirely
>given by Arenhoevel's "f's", and those depend on three coordinates only.
>Therefore, only three-dimensional lookup tables are actually necessary,
>and from these it is possible to contruct cross sections for any beam
>energy. A reduction of the dimension from 5 to 3 would make the code much
>less memory-expensive.
>
>A final comment on the interpolation of the cross section: The steepest
>slopes in cross section usually occur in the Mott cross section term,
>whereas the f's show rather smooth variations. Therefore I believe that
>after a reduction of the dimensions it would be sufficient to linearly
>interpolate the grid for the f's in order to evaluate the cross section
>weights.
>
>
>
>Regards,
>
> Michael
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST