[Halld-tagger] End user polarization

Tue Jun 6 10:08:13 EDT 2017

I think that we should be aiming to have the photon polarization information as part
of the event in REST. This way, it can easily be carried forward into an analysis.
However, we may also need a function that can return this information that can be
called at later stages of the analysis as well.

When we analyzed CLAS g8 data for the omega, we had a function that gave the
polarization of every photon and we carried that through the amplitude analysis
on an event-by-event basis.

Curtis
---------
Curtis A. Meyer MCS Associate Dean for Faculty and Graduate Affairs
Wean:    (412) 268-2745 Professor of Physics
Doherty: (412) 268-3090 Carnegie Mellon University
Fax:         (412) 681-0648 Pittsburgh, PA 15213
cmeyer at cmu.edu<mailto:cmeyer at cmu.edu> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.curtismeyer.com_&d=DwIFAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=lneuPoR_Y_qxqVHZY6VsYU8W43i3GcK7nXR2epWlm0Y&m=7aQTP7xOvR8g5Zv7td47Uqr6HuH-kQOElwVzxwaGh_g&s=hGKWCNzhdvpO2zvW4H677sFcq8uJFuLRWxwO-Rji4CM&e= 

On Jun 6, 2017, at 8:06 AM, dugger at jlab.org<mailto:dugger at jlab.org> wrote:

Ken,

Thanks for the information.

I do not understand why you think that the edge position is so important
for TPOL data. What am I missing? When I look at a polarization observable
I only care that I have a fair representation of the average polarization.

I do not see how TPOL would not give a fair statistical representation of
the polarization, regardless of what the instantaneous edge is doing.

Take care,
Michael

Hi Michael and all,
That sounds good to me. It would at least give the option of asking for
the polarisation of every photon in every event - even if it's coming
from a single lookup table that's been taken from the triplet
polarimiter analysis averaged over the whole beamtime. It would make
analysis easier.

It's worth considering the experience from CLAS and Mainz.

Here's the kind of function we use:

double GetPol(int plane, double edge, double Eg,   int poltype =
PSMOOTH, double lowThresh=0.2, Double highThresh=0.3)
double GetPol(int plane, double edge, int TagChan, int poltype =
PSMOOTH, double lowThresh=0.2, Double highThresh=0.3)

where:
plane      = polarisation plane (PARA=0,PERP=1)
edge       = coherent edge in GeV
Eg         = photon energy in GeV (or TagChan for faster performance)
poltype    = selects ther required column in the lookup tables.
lowThresh  = minimum pol required for events on left of edge
highThresh = minimum pol required for events on right of edge

This function returns the polarisation, or -1 if it is unknown or fails
the theshold criteria.

The lookup tables which are used by the function can be pulled in as
required - eg. on a run by run basis from a calibration database - or on
an "edge by edge" basis as described below.

In CLAS, where the peak drifted around a lot, the CBSA (Coherent Brem
Shape Analysis) was used to fit as many enhancements as possible to
cover the range of edges for each nominal setting. The parameters from
the CBSA fits were then used to generate different lookup tables for
each edge position, in 2MeV steps. In the anaysis, each scaler read from
the hodoscope (2s intervals) was used to make an enhancement and
determine the current edge position, and a lookup table was made by
interpolating between the 2 nearsest tables.
The current CBSA fit was developed (by me) specifically for this
puspose. It has been hacked, fudged and phenomenologised directly from
the equations outlined in the Timm paper, with some simplifications, and
some assumptions about the beam and collimator, to make something that
could be fitted with minuit. Sometimes it even converges! The aim was to
improve on the previous method (anb, for example), where a bunch of
dubious parameters was adjusted by hand until the user was happy that
the enhancement agreed with the data.

In Mainz, where things are very stable and more analagous to GlueX, we
generate the lookup tables dynamically using the parameters from the
CBSA fit every time the coherent edge changes by more than some
threshold amount (eg 1MeV with edge at 450MeV). I think the optimum for
GlueX in the longer term would be to do something similar, with tables
generated from TPOL results binned into edge positions. Small changes in
the edge position can make a big difference to the polarisation in those
photon energy bins - this has to be carefully handled somehow.

Regards,
Ken

On 05/06/17 18:35, dugger at jlab.org<mailto:dugger at jlab.org> wrote:
Hi,

I was thinking about event-by-event polarizations.

While TPOL can not give an event-by-event polarization, we could provide
some sort of subroutine that gives the average run polarization on an
event-by-event basis. The subroutine would take as arguments the run
number and photon energy for an event, with the return value being the
polarization (based off a polarization binning of 100 MeV).

Does this sound like the sort of thing that is desired?

My plan is to go ahead with making the code that gives the polarization
for a set of runs (provided by the end user), and then have our grad
student (Sebastian Cole) create the final code that takes into account
the
feedback we get from our fellow GlueX collaborators.

Take care,
Michael

_______________________________________________
Halld-tagger mailing list
Halld-tagger at jlab.org<mailto:Halld-tagger at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-tagger

--
=======================================================
Ken Livingston

Dept. of Physics & Astronomy,        Tel: +44 141 330 6428
University of Glasgow,               Fax: +44 141 330 5889
Glasgow G12 8QQ.
Scotland. UK.
=======================================================

_______________________________________________
Halld-tagger mailing list
Halld-tagger at jlab.org<mailto:Halld-tagger at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-tagger

_______________________________________________
Halld-tagger mailing list
Halld-tagger at jlab.org<mailto:Halld-tagger at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-tagger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-tagger/attachments/20170606/e973d921/attachment-0001.html>