[Halld-tagger] End user polarization

Tue Jun 6 10:40:49 EDT 2017

Curtis,

Yes. We had a function for g8b data (as described in Ken's email) that
would give a polarization estimate for every photon.

For g8b, the function gave the estimated polarization for a given photon
energy (within the resolution of the tagger) within the scalar interval
associated with the event. For TPOL, we can not give the polarization for
short time scales. Instead, we could give the polarization within the run
associated with the event (with an energy resolution based on a binning
scheme of 100 or 200 MeV).

It sounds like people would be interested in having a function like the
one Ken gave for g8b.

Take care,
Michael

> 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=_X8d9cIPQI6K08og9VrvuQ&m=PBKCm57T50-hojFUT1n9-H9Udv7i4Jb1UkXqjJ-wTGE&s=CrWmAmzHhQXE8W2DSbEIjiKqlvcVAHV8pY_cIhW3enk&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
>
>