[Halld-offline] Beam Polarization
Sean Dobbs
s-dobbs at northwestern.edu
Tue Mar 1 10:26:16 EST 2016
I concur, with a preference for the lovely phenomenological fit method, if
it's feasible, as it's certainly easier to manage.
I'd also like to second David's point that this would be a good motivation
for extending CCDB to handle event-range-dependent constants.
---Sean
On Tue, Mar 1, 2016 at 9:13 AM Paul Mattione <pmatt at jlab.org> wrote:
> I agree with Ken’s scheme, with the following (very) minor changes:
>
> 1) CCDB table names can be much simpler: They don’t need to contain the
> run-range, since that’s inherent in the CCDB. We may not need to specify
> PARA/PERP either, since I don’t think we’ll be changing that within a run.
>
> 2) Instead of storing the coherent edge information in a text file
> (2.3.3), I think we can store it instead as it’s own CCDB table. It would
> have 2 columns: One for beginning event #, and the other for coherent edge
> position. The rows would be blocks of events, similar to Ken’s. We would
> just have to make sure the table is large enough to contain enough rows for
> very-large runs. Not ideal, but I think needing to keep track of extra
> text files is worse.
>
> - Paul
>
> On Mar 1, 2016, at 9:51 AM, Alexander Somov <somov at jlab.org> wrote:
>
> >
> > Hi,
> >
> > We measure the beam polarization with three different devices:
> > the tagger, PS hodoscope and polarimeter
> >
> > with different systematic uncertainties. It is important to keep these
> numbers in the same place (CCDB seems to be the simplest place); it can
> > be filled with numbers for different run sets after we reprocess
> > the run.
> >
> > Cheers,
> > Alex
> >
> >
> >
> > On Mon, 29 Feb 2016, Paul Mattione wrote:
> >
> >> Well, both could be useful: we could compare them for computing
> systematic uncertainties. But yes, having a standard source that everyone
> agrees on is ideal. But I don’t know how to make the determination of
> which to use, once both systems are up and running.
> >>
> >> - Paul
> >>
> >> On Feb 29, 2016, at 7:47 PM, Curtis A. Meyer <cmeyer at cmu.edu> wrote:
> >>
> >>> There should really only be a single number that is our best etimate
> from all data 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
> >>> curtis.meyer at cmu.edu http://www.curtismeyer.com/
> >>>
> >>>
> >>>
> >>>> On Feb 29, 2016, at 7:37 PM, Paul Mattione <pmatt at jlab.org> wrote:
> >>>>
> >>>> Do we want two beam polarization numbers in DBeamPhoton? One
> calculated via the fit to the tagger spectrum, and one via the triplet
> polarimeter measurements?
> >>>>
> >>>> - Paul
> >>>>
> >>>> On Feb 23, 2016, at 9:08 AM, Sean Dobbs <s-dobbs at northwestern.edu>
> wrote:
> >>>>
> >>>>> It should be easy enough to add polarization parameters to
> DBeamPhoton (which I think is what Curtis was advocating).
> >>>>>
> >>>>> Supporting beam polarization parameters that vary over the run is
> more complicated. The CCDB doesn't currently handle conditions that vary
> over less than the run. A potential solution could be to write out
> coherent peak fit parameters in EPICS variables in the data stream, such
> that a LUT for the tagger counters could be regenerated over the run.
> Parameters for the derivation could be stored in the CCDB. Hopefully all
> the hard work on the accelerator side will results in a stable enough beam
> that we won't need this level of detail for real production runs.
> >>>>>
> >>>>> Cheers,
> >>>>> Sean
> >>>>>
> >>>>> On Tue, Feb 23, 2016 at 2:50 AM Dominik Werthmueller <
> werthm at jlab.org> wrote:
> >>>>> I'm not sure we should rely on stable polarization within a run
> given the CEBAF beam stability and the extreme GlueX beam optics, surely
> Ken could comment on that in more detail. As single GlueX runs are rather
> long, I would definitely favor a finer granularity (ranges of events, for
> example). I think that a simple LUT with polarization values for all tagger
> counters is more flexible than storing parameters for a certain
> polarization parametrization that might change in the future.
> >>>>>
> >>>>> Cheers,
> >>>>> Dominik
> >>>>>
> >>>>>
> >>>>>> Am 23.02.2016 um 02:53 schrieb Justin Stevens <jrsteven at jlab.org>:
> >>>>>>
> >>>>>> It seems the simplest place to include this in our current
> framework is the CCDB, assuming the polarization is not varying much within
> a single run or range of runs. For the energy dependence of the
> polarization, we could store
> >>>>>>
> >>>>>> 1) a table with polarization values for individual energy bins (eg.
> tagger counters/columns) or
> >>>>>> 2) some parameters for a function which describes the polarization
> shape with energy
> >>>>>>
> >>>>>> The polarization direction for a run should already be in RCDB, but
> probably should be mirrored in CCDB for simplicity.
> >>>>>>
> >>>>>> -Justin
> >>>>>>
> >>>>>> On Feb 22, 2016, at 8:50 PM, Paul Mattione wrote:
> >>>>>>
> >>>>>>> Well, if we were to fit the polarization many different times
> within a run, we would need a mechanism for storing, and then looking up,
> the fit results relevant for each given range of events. Do we have a
> mechanism that can do this yet? Or am I thinking about this wrong?
> >>>>>>>
> >>>>>>> - Paul
> >>>>>>>
> >>>>>>> On Feb 22, 2016, at 8:30 PM, Curtis A. Meyer <cmeyer at cmu.edu>
> wrote:
> >>>>>>>
> >>>>>>>> Yes, but it does depend on the photon energy. E.g. how far away
> from the coherent edge are you?
> >>>>>>>> Events near the edge will have the highest degree of linear
> polarization, while those far away will
> >>>>>>>> have less. If the edge is stable, the function is pretty simple.,
> but we still need to be able to assign
> >>>>>>>> both a polarization and a polarization direction to our photons
> 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
> >>>>>>>> curtis.meyer at cmu.edu http://www.curtismeyer.com/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Feb 22, 2016, at 8:25 PM, Paul Mattione <pmatt at jlab.org>
> wrote:
> >>>>>>>>>
> >>>>>>>>> I was under the impression that, for a given beam energy, the
> polarization would be relatively constant over the course of a run.
> >>>>>>>>>
> >>>>>>>>> - Paul
> >>>>>>>>>
> >>>>>>>>> On Feb 22, 2016, at 8:22 PM, Curtis A. Meyer <cmeyer at cmu.edu>
> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Everyone,
> >>>>>>>>>>
> >>>>>>>>>> I am not sure if we have this capability yet, but as we move
> forward we are going to
> >>>>>>>>>> want the REST files to contain the photon polarization. This is
> likely a function that
> >>>>>>>>>> we have to call when we have decided what the correct photon
> is, but we should have
> >>>>>>>>>> the hooks in place to do this 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
> >>>>>>>>>> curtis.meyer at cmu.edu http://www.curtismeyer.com/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Halld-offline mailing list
> >>>>>>>>>> Halld-offline at jlab.org
> >>>>>>>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Halld-offline mailing list
> >>>>>>> Halld-offline at jlab.org
> >>>>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Halld-offline mailing list
> >>>>>> Halld-offline at jlab.org
> >>>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Halld-offline mailing list
> >>>>> Halld-offline at jlab.org
> >>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>>> _______________________________________________
> >>>>> Halld-offline mailing list
> >>>>> Halld-offline at jlab.org
> >>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>>
> >>>> _______________________________________________
> >>>> Halld-offline mailing list
> >>>> Halld-offline at jlab.org
> >>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
> >>>
> >>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160301/26607009/attachment-0002.html>
More information about the Halld-offline
mailing list