[subexp-daq] Question on UCESB

Thu Apr 4 21:06:31 CEST 2024

P.S.

A follow-up question:

In UCESB manual there is some example code on page 65 (listing 6.2), where we find:

#define EXT_EVENT_STRUCT EXT_STR_h101
#define EXT_EVENT_STRUCT_LAYOUT EXT_STR_h101_layout
#define EXT_EVENT_STRUCT_LAYOUT_INIT EXT_STR_h101_LAYOUT_INIT

However, the jena_test.hh created by our UCESB does only have

typedef struct EXT_STR_h101_t

and

typedef struct EXT_STR_h101_onion_t.

>From where could we get _layout and LAYOUT_INIT for our test case?

Thank you very much!

Best greetings

Günter

________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Weber, Guenter Dr. <g.weber at hi-jena.gsi.de>
Gesendet: Donnerstag, 4. April 2024 20:47:19
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] Question on UCESB

Dear friends,

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:

Event           203 Type/Subtype   10    1 Size      140 Trigger  1
 SubEv ProcID     1 Type/Subtype   10    1 Size       24 Ctrl   9 Subcrate   1
 00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a
 SubEv ProcID     1 Type/Subtype   20    2 Size       84 Ctrl   9 Subcrate   1
 80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001
 00000001 00000001 00000001 00000001 00000001

Event         203 Trigger  1

.RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529
.RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388
.RAW.VULOM.SCALER[0]: 0x0001a871=108657
.RAW.VULOM.SCALER[1]: 0x00000000=0
.RAW.VULOM.SCALER[2]: 0x00000000=0
.RAW.VULOM.SCALER[3]: 0x00000000=0
.RAW.VULOM.SCALER[4]: 0x00000000=0
.RAW.VULOM.SCALER[5]: 0x00000000=0
.RAW.VULOM.SCALER[6]: 0x00000000=0
.RAW.VULOM.SCALER[7]: 0x00000000=0
.RAW.VULOM.SCALER[8]: 0x00000001=1
.RAW.VULOM.SCALER[9]: 0x00000001=1
.RAW.VULOM.SCALER[10]: 0x00000001=1
.RAW.VULOM.SCALER[11]: 0x00000001=1
.RAW.VULOM.SCALER[12]: 0x00000001=1
.RAW.VULOM.SCALER[13]: 0x00000001=1
.RAW.VULOM.SCALER[14]: 0x00000001=1
.RAW.VULOM.SCALER[15]: 0x00000001=1

(produced with "--data --dump=RAW --print")

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.

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:

import socket
import sys
import numpy as np

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = ("10.141.184.131", 8001)
print(sys.stderr, 'connecting to %s port %s' % server_address)
sock.connect(server_address)
print("Connected")
data = sock.recv(80)
print( data )
t = np.dtype('u4, u4, u8, (16)u4')  /* for our test data: trigger type, event number, timestamp, 16 scaler channels */
a = np.frombuffer(data, dtype=t)
sock.close()

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).

Thank you very much and best greetings from Jena.

Günter

----------------

Günter Weber

Helmholtz-Institut Jena
Fröbelstieg 3
07743 Jena
Germany
Phone: +49-3641-947605
www.hi-jena.de<http://www.hi-jena.de>

GSI Helmholtzzentrum für Schwerionenforschung
Planckstrasse 1
64291 Darmstadt
Germany
www.gsi.de<http://www.gsi.de>
________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Donnerstag, 4. April 2024 06:39:32
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] Question on UCESB

On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote:

>
> Dear friends,
>
>
> we now had a brief look into UCESB and UPEXPS.
>
>
> Is our intepretation correct, that *.spec-Files are used for mapping between
> the raw data within an LMD event and "interpreted" data that is then used
> for further analysis?

Yes.  The .spec files contain the data format descriptions, and also the
mappings of channel names (in the SIGNAL statements).

> If true, why is the folder SPEC containing only spec
> files for a few of the modules available in NURDLIB?

The ucesb/spec/ directory comntain files where I or users have sent me
patches/commits with those data format specifications.

> Is it just the case
> that nobody found time yet or is there a design decision behind this?

If users place / keep them elsewhere (like e.g. upexps) longterm, there is
not much I can do...  :-)

Not a design decision.  Except that the stuff in (the generic spec/
directory) should not be experiment specific.

> We are
> now ondering what is the best wyo add a spec file for the new module that we
> added to NURDLIB.

Sure!  Yes, please!

> Also, if this made sense, we could add a spec file for the
> STRUCK digitizers whcih currently does only exist within UPEXPS.

Yes.  But we also need to know where it came from, since ucesb is
publically available, and just for good form want to keep the license in
order.  I do want to make a mess like this, but to avoid issues down the
road.

> To us there it is not really clear where UCESB ends and UPEXPS begins. Could
> you explain what exactly is the purpose of both packages? What is UPEXPS
> doing that could/should not be a part of UCESB?

Generally, ucesb/ is (expect for the fast that it has some (old) example
and test directories, not experiment-specific.

upexps (or any other user repo) would contain the signal mappings for
sure.

Some .spec files would likely be better to have somewhere under
ucesb/spec/

Cheers,
Håkan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240404/9fe1f0b8/attachment-0001.html>