[subexp-daq] Question on UCESB

Thu Apr 4 23:08:07 CEST 2024

Dear Günter,

the easiest way is probably to use the json dump from the ntuple writer.

How to get there is not very well documented...:

Example with dummy data:

   file_input/empty_file --lmd | \
     empty/empty --file=- --ntuple=STRUCT,- | \
     hbook/struct_writer - --dump=json

It can also be operated in a 'server' mode for the 'external' data:

   file_input/empty_file --lmd | \
     empty/empty --file=- --ntuple=STRUCT,SERVER

And then the dumper could be started like this:

   hbook/struct_writer localhost --dump=json

Instead of json also compact_json exist, which will produce less 
whitespace.

Cheers,
Håkan

On Thu, 4 Apr 2024, Weber, Guenter Dr. wrote:

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