[subexp-daq] Question on UCESB
Håkan T Johansson
f96hajo at chalmers.se
Thu Apr 4 23:12:58 CEST 2024
I think/hope you'll get away with the json in the previous mail, but for
completeness:
Cool that you found that example!
That write-up is unfortunately out of date... (Though most things should
still work, this is hopefully one of the few that does not.)
An example of such an external reader can be found here:
hbook/example/ext_data_reader.c
It now transmits the data layout in other ways instead, which is a bit
more flexible.
Cheers,
Håkan
On Thu, 4 Apr 2024, Weber, Guenter Dr. wrote:
>
> 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
>
> GSI Helmholtzzentrum für Schwerionenforschung
> Planckstrasse 1
> 64291 Darmstadt
> Germany
> 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
>
>
More information about the subexp-daq
mailing list