<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I think that we should be aiming to have the photon polarization information as part
<div class="">of the event in REST. This way, it can easily be carried forward into an analysis.</div>
<div class="">However, we may also need a function that can return this information that can be</div>
<div class="">called at later stages of the analysis as well. </div>
<div class=""><br class="">
</div>
<div class="">When we analyzed CLAS g8 data for the omega, we had a function that gave the</div>
<div class="">polarization of every photon and we carried that through the amplitude analysis </div>
<div class="">on an event-by-event basis.</div>
<div class=""><br class="">
</div>
<div class="">Curtis</div>
<div class="">
<div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">
---------</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">
Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre;"> </span>MCS Associate Dean for Faculty and Graduate Affairs<br class="">
Wean: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre;"> </span>
Professor of Physics<br class="">
Doherty: (412) 268-3090<span class="Apple-tab-span" style="white-space: pre;"> </span>
Carnegie Mellon University<br class="">
Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre;">
</span>Pittsburgh, PA 15213<br class="">
<a href="mailto:cmeyer@cmu.edu" class="">cmeyer@cmu.edu</a><span class="Apple-tab-span" style="white-space: pre;">
</span>http://www.curtismeyer.com/</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 6, 2017, at 8:06 AM, <a href="mailto:dugger@jlab.org" class="">
dugger@jlab.org</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Ken,<br class="">
<br class="">
Thanks for the information.<br class="">
<br class="">
I do not understand why you think that the edge position is so important<br class="">
for TPOL data. What am I missing? When I look at a polarization observable<br class="">
I only care that I have a fair representation of the average polarization.<br class="">
<br class="">
I do not see how TPOL would not give a fair statistical representation of<br class="">
the polarization, regardless of what the instantaneous edge is doing.<br class="">
<br class="">
Take care,<br class="">
Michael<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">Hi Michael and all,<br class="">
That sounds good to me. It would at least give the option of asking for<br class="">
the polarisation of every photon in every event - even if it's coming<br class="">
from a single lookup table that's been taken from the triplet<br class="">
polarimiter analysis averaged over the whole beamtime. It would make<br class="">
analysis easier.<br class="">
<br class="">
It's worth considering the experience from CLAS and Mainz.<br class="">
<br class="">
Here's the kind of function we use:<br class="">
<br class="">
double GetPol(int plane, double edge, double Eg, int poltype =<br class="">
PSMOOTH, double lowThresh=0.2, Double highThresh=0.3)<br class="">
double GetPol(int plane, double edge, int TagChan, int poltype =<br class="">
PSMOOTH, double lowThresh=0.2, Double highThresh=0.3)<br class="">
<br class="">
where:<br class="">
plane = polarisation plane (PARA=0,PERP=1)<br class="">
edge = coherent edge in GeV<br class="">
Eg = photon energy in GeV (or TagChan for faster performance)<br class="">
poltype = selects ther required column in the lookup tables.<br class="">
lowThresh = minimum pol required for events on left of edge<br class="">
highThresh = minimum pol required for events on right of edge<br class="">
<br class="">
This function returns the polarisation, or -1 if it is unknown or fails<br class="">
the theshold criteria.<br class="">
<br class="">
The lookup tables which are used by the function can be pulled in as<br class="">
required - eg. on a run by run basis from a calibration database - or on<br class="">
an "edge by edge" basis as described below.<br class="">
<br class="">
In CLAS, where the peak drifted around a lot, the CBSA (Coherent Brem<br class="">
Shape Analysis) was used to fit as many enhancements as possible to<br class="">
cover the range of edges for each nominal setting. The parameters from<br class="">
the CBSA fits were then used to generate different lookup tables for<br class="">
each edge position, in 2MeV steps. In the anaysis, each scaler read from<br class="">
the hodoscope (2s intervals) was used to make an enhancement and<br class="">
determine the current edge position, and a lookup table was made by<br class="">
interpolating between the 2 nearsest tables.<br class="">
The current CBSA fit was developed (by me) specifically for this<br class="">
puspose. It has been hacked, fudged and phenomenologised directly from<br class="">
the equations outlined in the Timm paper, with some simplifications, and<br class="">
some assumptions about the beam and collimator, to make something that<br class="">
could be fitted with minuit. Sometimes it even converges! The aim was to<br class="">
improve on the previous method (anb, for example), where a bunch of<br class="">
dubious parameters was adjusted by hand until the user was happy that<br class="">
the enhancement agreed with the data.<br class="">
<br class="">
In Mainz, where things are very stable and more analagous to GlueX, we<br class="">
generate the lookup tables dynamically using the parameters from the<br class="">
CBSA fit every time the coherent edge changes by more than some<br class="">
threshold amount (eg 1MeV with edge at 450MeV). I think the optimum for<br class="">
GlueX in the longer term would be to do something similar, with tables<br class="">
generated from TPOL results binned into edge positions. Small changes in<br class="">
the edge position can make a big difference to the polarisation in those<br class="">
photon energy bins - this has to be carefully handled somehow.<br class="">
<br class="">
Regards,<br class="">
Ken<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On 05/06/17 18:35, <a href="mailto:dugger@jlab.org" class="">dugger@jlab.org</a> wrote:<br class="">
<blockquote type="cite" class="">Hi,<br class="">
<br class="">
I was thinking about event-by-event polarizations.<br class="">
<br class="">
While TPOL can not give an event-by-event polarization, we could provide<br class="">
some sort of subroutine that gives the average run polarization on an<br class="">
event-by-event basis. The subroutine would take as arguments the run<br class="">
number and photon energy for an event, with the return value being the<br class="">
polarization (based off a polarization binning of 100 MeV).<br class="">
<br class="">
Does this sound like the sort of thing that is desired?<br class="">
<br class="">
My plan is to go ahead with making the code that gives the polarization<br class="">
for a set of runs (provided by the end user), and then have our grad<br class="">
student (Sebastian Cole) create the final code that takes into account<br class="">
the<br class="">
feedback we get from our fellow GlueX collaborators.<br class="">
<br class="">
Take care,<br class="">
Michael<br class="">
<br class="">
_______________________________________________<br class="">
Halld-tagger mailing list<br class="">
<a href="mailto:Halld-tagger@jlab.org" class="">Halld-tagger@jlab.org</a><br class="">
https://mailman.jlab.org/mailman/listinfo/halld-tagger<br class="">
</blockquote>
<br class="">
<br class="">
--<br class="">
=======================================================<br class="">
Ken Livingston<br class="">
<br class="">
Dept. of Physics & Astronomy, Tel: +44 141 330 6428<br class="">
University of Glasgow, Fax: +44 141 330 5889<br class="">
Glasgow G12 8QQ.<br class="">
Scotland. UK.<br class="">
=======================================================<br class="">
<br class="">
_______________________________________________<br class="">
Halld-tagger mailing list<br class="">
<a href="mailto:Halld-tagger@jlab.org" class="">Halld-tagger@jlab.org</a><br class="">
https://mailman.jlab.org/mailman/listinfo/halld-tagger<br class="">
<br class="">
</blockquote>
<br class="">
<br class="">
_______________________________________________<br class="">
Halld-tagger mailing list<br class="">
<a href="mailto:Halld-tagger@jlab.org" class="">Halld-tagger@jlab.org</a><br class="">
https://mailman.jlab.org/mailman/listinfo/halld-tagger<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>