<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear friends,</p>
<p><br>
</p>
<p>we now (think that we have) understoof how *.spec-Files work. For a minimum setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out own UCESB example. The output of an event looks like this:</p>
<p><br>
</p>
<p></p>
<div><span style="font-size:10pt">Event 203 Type/Subtype 10 1 Size 140 Trigger 1</span><br>
<span style="font-size:10pt"> SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1</span><br>
<span style="font-size:10pt"> 00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a</span><br>
<span style="font-size:10pt"> SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1</span><br>
<span style="font-size:10pt"> 80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000</span><br>
<span style="font-size:10pt"> 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001</span><br>
<span style="font-size:10pt"> 00000001 00000001 00000001 00000001 00000001</span><br>
<br>
<span style="font-size:10pt">Event 203 Trigger 1</span><br>
<br>
<span style="font-size:10pt">.RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529</span><br>
<span style="font-size:10pt">.RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[0]: 0x0001a871=108657</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[1]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[2]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[3]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[4]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[5]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[6]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[7]: 0x00000000=0</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[8]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[9]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[10]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[11]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[12]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[13]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[14]: 0x00000001=1</span><br>
<span style="font-size:10pt">.RAW.VULOM.SCALER[15]: 0x00000001=1</span></div>
<div><br>
</div>
<div>(produced with "--data --dump=RAW --print")</div>
<div><br>
</div>
<div>We now would like to take the easisest possible route to transport the RAW data to Pyhton, where our main analysis is living. Unfortunately, ext_data_client.h and the code behind it does not really feel inviting to be converted into Python. Is there any
other way to generate a data stream from UCESB? So far, we had only success with writing the data into a ROOT file and then using uproot in Pyhton to read the file. But this is no solution for online analysis where we would need a data stream.</div>
<div><br>
</div>
<div>We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), but we felt a bit overwhelmed. Idealy, we could access the data stream from UCESB with such a simple Python code:</div>
<div><br>
</div>
<div>
<div><span style="font-size:10pt">import socket</span><br>
<span style="font-size:10pt">import sys</span><br>
<span style="font-size:10pt">import numpy as np</span><br>
<br>
<span style="font-size:10pt">sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)</span><br>
<span style="font-size:10pt">server_address = ("10.141.184.131", 8001)</span><br>
<span style="font-size:10pt">print(sys.stderr, 'connecting to %s port %s' % server_address)</span><br>
<span style="font-size:10pt">sock.connect(server_address)</span><br>
<span style="font-size:10pt">print("Connected")</span><br>
<span style="font-size:10pt">data = sock.recv(80</span><span style="font-size:10pt">)</span><br>
<span style="font-size:10pt">print( data )</span><br>
<span style="font-size:10pt">t = np.dtype('u4, u4, u8, (16)u4') /* for our test data: trigger type, event number, timestamp, 16 scaler channels */</span><br>
<span style="font-size:10pt">a = np.frombuffer(data, dtype=t)</span><br>
<span style="font-size:10pt">sock.close()</span></div>
<div><br>
</div>
<div>However, of course just get 'a magic word' from UCESB as we have not implemented the correct protocoll to acccess the data. In an idea case, we would be able to avoid implementing this protocoll (or find an easy way to do it).</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Thank you very much and best greetings from Jena.</div>
<div><br>
</div>
<div><br>
</div>
<div>Günter<br>
</div>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<p></p>
<p><br>
</p>
<p><br>
</p>
<div id="x_Signature">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt">----------------<br>
<br>
Günter Weber<br>
<br>
Helmholtz-Institut Jena<br>
Fröbelstieg 3<br>
07743 Jena<br>
Germany<br>
Phone: +49-3641-947605<br>
<a href="http://www.hi-jena.de" id="LPNoLP"><font size="2">www.hi-jena.de</font></a><br>
<br>
GSI Helmholtzzentrum für Schwerionenforschung<br>
Planckstrasse 1<br>
64291 Darmstadt<br>
Germany<br>
</span></font><a href="http://www.gsi.de" id="LPNoLP"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><font size="2">www.gsi.de</font></span></font></a></div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Donnerstag, 4. April 2024 06:39:32<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Question on UCESB</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> we now had a brief look into UCESB and UPEXPS.<br>
> <br>
> <br>
> Is our intepretation correct, that *.spec-Files are used for mapping between<br>
> the raw data within an LMD event and "interpreted" data that is then used<br>
> for further analysis?<br>
<br>
Yes. The .spec files contain the data format descriptions, and also the <br>
mappings of channel names (in the SIGNAL statements).<br>
<br>
> If true, why is the folder SPEC containing only spec<br>
> files for a few of the modules available in NURDLIB?<br>
<br>
The ucesb/spec/ directory comntain files where I or users have sent me <br>
patches/commits with those data format specifications.<br>
<br>
> Is it just the case<br>
> that nobody found time yet or is there a design decision behind this?<br>
<br>
If users place / keep them elsewhere (like e.g. upexps) longterm, there is <br>
not much I can do... :-)<br>
<br>
Not a design decision. Except that the stuff in (the generic spec/ <br>
directory) should not be experiment specific.<br>
<br>
> We are<br>
> now ondering what is the best wyo add a spec file for the new module that we<br>
> added to NURDLIB.<br>
<br>
Sure! Yes, please!<br>
<br>
> Also, if this made sense, we could add a spec file for the<br>
> STRUCK digitizers whcih currently does only exist within UPEXPS.<br>
<br>
Yes. But we also need to know where it came from, since ucesb is <br>
publically available, and just for good form want to keep the license in <br>
order. I do want to make a mess like this, but to avoid issues down the <br>
road.<br>
<br>
> To us there it is not really clear where UCESB ends and UPEXPS begins. Could<br>
> you explain what exactly is the purpose of both packages? What is UPEXPS<br>
> doing that could/should not be a part of UCESB?<br>
<br>
Generally, ucesb/ is (expect for the fast that it has some (old) example <br>
and test directories, not experiment-specific.<br>
<br>
upexps (or any other user repo) would contain the signal mappings for <br>
sure.<br>
<br>
Some .spec files would likely be better to have somewhere under <br>
ucesb/spec/<br>
<br>
Cheers,<br>
Håkan</div>
</span></font>
</body>
</html>