[Halld-alpha] [EXTERNAL] Helicity in GlueX data

Wed Feb 26 16:25:40 EST 2025

Hi guys,

Next week I’ll go into the tagger with a scope and look at the signals and do whatever local tests I can.

Best,
Mark

On Feb 26, 2025, at 14:02, Peter Hurck <ppauli at jlab.org> wrote:

Hi Ken, (I put the halld-alpha list back in as it fell off the recipient list)

That is indeed bad news. This needs to be fixed asap. I hope Mark has an idea. He was saying that the signal should be there if the board works fine. So maybe that is an indication that there is an issue with the board?

Cheers,
Peter

On 26 Feb 2025, at 14:16, Ken Livingston <kenneth.livingston at glasgow.ac.uk<mailto:kenneth.livingston at glasgow.ac.uk>> wrote:

Hi Sean, and all,

Thanks. The fix works - at least it prevents it from failing with an unrecognised module.

The bad news is that there seems to be no helicity information in those recent files!
Eg.
>hd_root -PPLUGINS=HELI_online,EPICS_dump -PHELI:VERBOSE=2 -PHELI:LOG=test.log -PTT:NO_CCDB=1 -PTT:XML_FILENAME=/group/halld/Users/jrsteven/TranslationTable/tt_helicity.xml /cache/halld/RunPeriod-2025-01/rawdata/Run130365/hd_rawdata_130365_000.evio -PEVIO:NTHREADS=4 -PNTHREADS=8 -o test.root

doesn't produce any helicity find any helicity information

I've confirmed that the helicity stuff still works with the 2023 data though.
Eg.
>hd_root -PPLUGINS=HELI_online,EPICS_dump -PHELI:VERBOSE=2 -PHELI:LOG=test.log -PTT:NO_CCDB=1 -PTT:XML_FILENAME=/group/halld/Users/jrsteven/TranslationTable/tt_helicity.xml /cache/mss/halld/RunPeriod-2023-01/rawdata/Run121100/hd_rawdata_121100_000.evio -PEVIO:NTHREADS=4 -PNTHREADS=8 -o test.root

This one is fine.

I think this is the most urgent thing to get sorted. Helicity decoding is not perfect, but we know it works and can be improved. The decoder board is too much of an unknown to be relied on - even if we get it included.

Any suggestions as to why the helicity stuff would be missing in the current setup?
Is the module not included in the readout?

Cheers,
Ken

On 26/02/2025 15:22, Sean Dobbs wrote:
Hi Ken,

I just pushed a change to my branch that will skip over the helicity
decoder information, and should let you run your analysis, though
there's some additional console output that can be ignored.

Cheers,
Sean

On Wed, Feb 26, 2025 at 8:04 AM Ken Livingston
<kenneth.livingston at glasgow.ac.uk<mailto:kenneth.livingston at glasgow.ac.uk>> wrote:
Hi All,

Thanks for the summary Peter - that's very useful. I agree - we certainly want to make sure the delayed signals are still there and working....

So I've just tried, unsuccessfully, to run hd_root to generate the required log file for making helicity tables from one of the recent test runs.

I'm running on the ifarm with binaries, libraries and plugins from
/group/halld/Software/builds/Linux_Alma9-x86_64-gcc11.5.0/halld_recon/halld_recon-5.0.0/Linux_Alma9-x86_64-gcc11.5.0

Here's the result:

ifarm2401|kliv>hd_root -PPLUGINS=HELI_online,EPICS_dump -PHELI:VERBOSE=2 -PHELI:LOG=helicity_130178_000.log -PTT:NO_CCDB=1 /cache/halld/RunPeriod-2025-01/rawdata/Run130178/hd_rawdata_130178_000.evio -PEVIO:NTHREADS=4 -PNTHREADS=8 -o hd_root_130178_000.root

...
...
...
07:19:48.219  [warn] Loading plugin 'HELI_online' from '/group/halld/Software/builds/Linux_Alma9-x86_64-gcc11.5.0/halld_recon/halld_recon-5.0.0/Linux_Alma9-x86_64-gcc11.5.0/plugins/HELI_online.so<http://heli_online.so/>'
07:19:48.220  [warn] Loading plugin 'EPICS_dump' from '/group/halld/Software/builds/Linux_Alma9-x86_64-gcc11.5.0/halld_recon/halld_recon-5.0.0/Linux_Alma9-x86_64-gcc11.5.0/plugins/EPICS_dump.so<http://epics_dump.so/>'
Wed Feb 26 07:19:48 2025 # thr=140676888139008 # --- EVIO ---: No more events
loading VERSION 3
07:19:48.234  [info] Control event: Prestart - Fri Jan 10 10:22:36 2025
07:19:48.234  [info] Control event: Go - Fri Jan 10 10:27:56 2025
07:19:48.234 [error] Unknown module type (3564 = 0xdec ) encountered
----- First few words to help with debugging -----
Dumping binary: istart=0x7ff1b80063a4 iend=0x7ff1b80067ac MaxWords=32
...
...
...

hd_root is failing because there's an unknown module type (3564 = 0xdec ) - that's the new decoder module.

Any suggestions ?

Is there a build with a fix for that?
If I checkout and use Sean's branch will that help (need to do that anyway)?
Is there an hd_root flag that will tell it to skip unknown modules?

In the meantime, I'll bash on and move the helicity decoding functionality from the plugin to the factory, so the information can be pushed to the REST files.

Cheers,
Ken

On 25/02/2025 22:36, Peter Hurck wrote:

Hi all,

While I was at the lab I managed to speak to a few people. I attempt a summary of where we stand and what remains to be done but please everybody feel free to weigh in if I get something wrong.

Regarding decoder board:

Ken and Sean looked at the data coming out of the decoder board but it looks like there is some issue. It seems to output an error code instead of the desired data.
Mark has checked the board in the past. The signals should not depend on the beam being on. That was a hypothesis to explain the weird decoder board output.
Sergey is in contact with people from Hall B who also have such a decoder board. He assumes it will need some reconfiguration in the DAQ but doesn’t think he will have time for it before the run starts. This is now our highest priority.

Action items:

Sergey, please check the configuration as soon as possible
Ken, please check if the test runs we took with the decoder board also contain all the information for the “regular” analysis with delayed helicity. This would be a fallback option, if we can’t get the board to work properly.

Regarding the 2023-01 data and REST production:

Naomi wants to go ahead with the REST production asap.
Ken is working to finalise the algorithms to get the helicity information from the data stream.
Sean laid all the ground work to get the helicity information into the REST file (and even into the root tree format)
We came up with the following scheme:

The evio data (raw data) contains the delayed helicity information and from now onwards also the prompt helicity information (we want to keep both)
During reconstruction the following is written to REST files (see JANA2 compatible branch https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_tree_sdobbs-5Fhelicity-5Fjana2&d=DwIDaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=ZI6YYQT6pFOav2gNEoW6fw&m=UXKV6wYY2c_-zsj742ZR4jnnB_D8SeeFeFTl7wNy8OdDdmB0HuoKDnCX4i-ddU2l&s=TEGSkBgl7hEiUdnMRdVvaXnnGpV3ekVl9wA7L2uyI_c&e= ):

bool pattern_sync;
bool t_settle;
bool helicity;
bool pair_sync;
bool helicity_bad;

A CCDB table will be populated that contains the overall sign of the helicity which might change depending on e.g.  Wien angle or lambda half wave plate, as well as the electron beam polarisation
During an analysis launch we write above bools to the root tree
We will add a DSelector utility function that returns the helicity for each event (above helicity*overall sign from CCDB)
We will add a DSelector utility function that calculates the degree of polarisation for each beam photon

Action items:

Ken: finalise algorithms for delayed and prompt reporting
Peter: test code to make sure it works as intended and work with Alex A. to include it in last monitoring launch before REST production
Mark: provide CCDB table with correct “calibration sign” for 2023-01 data as well as estimate for degree of electron beam polarisation (not needed before REST production)
Peter: check root tree output and write utility functions (help needed from Farah to include correction for linear polarisation)

Further points regarding next run:

Derek prepared the monitoring plugin for online monitoring, still missing: real helicity

Action items:

Derek: Include real helicity in monitoring as soon as Ken is done
Peter: Work with Alex A. to include the monitoring plots in RootSpy
Peter/Mark: Write instructions for shifters

I hope I didn’t forget anything.

Thanks everybody for all your help in getting this off the ground. I have no doubt that this will be incredibly useful for the whole GlueX collaboration and enable us to do great physics beyond the alpha minus measurement.

Cheers,
Peter

_______________________________________________
Halld-alpha mailing list
Halld-alpha at jlab.org
https://mailman.jlab.org/mailman/listinfo/halld-alpha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-alpha/attachments/20250226/0e0f7ab4/attachment-0001.html>