<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi All,<br>
<br>
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....<br>
<br>
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. <br>
<br>
I'm running on the ifarm with binaries, libraries and plugins from <br>
/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<br>
<br>
Here's the result:<br>
<br>
<font face="monospace">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<br>
<br>
...<br>
...<br>
...<br>
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'<br>
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'<br>
Wed Feb 26 07:19:48 2025 # thr=140676888139008 # --- EVIO ---: No
more events<br>
loading VERSION 3<br>
07:19:48.234 [info] Control event: Prestart - Fri Jan 10 10:22:36
2025<br>
07:19:48.234 [info] Control event: Go - Fri Jan 10 10:27:56 2025<br>
07:19:48.234 [error] Unknown module type (3564 = 0xdec )
encountered<br>
----- First few words to help with debugging -----<br>
Dumping binary: istart=0x7ff1b80063a4 iend=0x7ff1b80067ac
MaxWords=32<br>
...<br>
...<br>
...<br>
<br>
</font><br>
hd_root is failing because there's an unknown module type (3564 =
0xdec ) - that's the new decoder module.<br>
<br>
Any suggestions ?<br>
<br>
Is there a build with a fix for that?<br>
If I checkout and use Sean's branch will that help (need to do that
anyway)?<br>
Is there an hd_root flag that will tell it to skip unknown modules?<br>
<br>
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.<br>
<br>
Cheers,<br>
Ken<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 25/02/2025 22:36, Peter Hurck wrote:<br>
</div>
<blockquote type="cite" cite="mid:DA16AD92-7A48-400E-8AEB-670EBD8C1AA2@jlab.org">
Hi all,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regarding decoder board:</div>
<div>
<ul class="MailOutline">
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<div>Action items:</div>
<div>
<ul class="MailOutline">
<li>Sergey, please check the configuration as soon as
possible </li>
<li>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.</li>
</ul>
</div>
<div><br>
</div>
</div>
<div>Regarding the 2023-01 data and REST production:</div>
<div>
<ul class="MailOutline">
<li>Naomi wants to go ahead with the REST production asap.</li>
<li>Ken is working to finalise the algorithms to get the
helicity information from the data stream.</li>
<li>Sean laid all the ground work to get the helicity
information into the REST file (and even into the root tree
format)</li>
<li>We came up with the following scheme:</li>
<ul class="MailOutline">
<li>The evio data (raw data) contains the delayed helicity
information and from now onwards also the prompt helicity
information (we want to keep both)</li>
<li>During reconstruction the following is written to REST
files (see JANA2 compatible branch <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_tree_sdobbs-5Fhelicity-5Fjana2&d=DwMDaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=EmrYJC65LptHy9XGAdWBAPWDiOjRm45yxjbBZdRxbc4&m=syArXEhO-vp3PKyMu7kHQOEmxak4SJD8aBIkxDhdNEdI6VXEVyYI-Fz4WKfCb0_c&s=6iCDodzU5uBjVAn5A0KaatVyE5Jp9PBNVkx6vAukE2c&e=" originalsrc="https://github.com/JeffersonLab/halld_recon/tree/sdobbs_helicity_jana2" moz-do-not-send="true">https://github.com/JeffersonLab/halld_recon/tree/sdobbs_helicity_jana2</a>):</li>
<ul class="MailOutline">
<li>bool pattern_sync;</li>
<li>bool t_settle;</li>
<li>bool helicity;</li>
<li>bool pair_sync;</li>
<li>bool helicity_bad; </li>
</ul>
<li>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</li>
<li>During an analysis launch we write above bools to the
root tree</li>
<li>We will add a DSelector utility function that returns
the helicity for each event (above helicity*overall sign
from CCDB)</li>
<li>We will add a DSelector utility function that calculates
the degree of polarisation for each beam photon</li>
</ul>
</ul>
<div>Action items:</div>
</div>
<div>
<ul class="MailOutline">
<li>Ken: finalise algorithms for delayed and prompt reporting</li>
<li>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</li>
<li>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)</li>
<li>Peter: check root tree output and write utility functions
(help needed from Farah to include correction for linear
polarisation)</li>
</ul>
<div><br>
</div>
</div>
<div>Further points regarding next run:</div>
<div>
<ul class="MailOutline">
<li>Derek prepared the monitoring plugin for online
monitoring, still missing: real helicity</li>
</ul>
<div>Action items:</div>
</div>
<div>
<ul class="MailOutline">
<li>Derek: Include real helicity in monitoring as soon as Ken
is done</li>
<li>Peter: Work with Alex A. to include the monitoring plots
in RootSpy</li>
<li>Peter/Mark: Write instructions for shifters</li>
</ul>
<div><br>
</div>
</div>
<div>I hope I didn’t forget anything.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Peter</div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
<br>
</body>
</html>