[Halld-tagger] End user polarization

[dugger at jlab.org]

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 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
>> 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
> https://mailman.jlab.org/mailman/listinfo/halld-tagger
>