<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Dear <span>Håkan</span>,</p>
<p><br>
</p>
<p>thank you very much for the explanations.</p>
<p><br>
</p>
<p>To be independent from Bastian's legacy code we have now our tailor made unpacker for some of the LMD data. If we found a way to feed it not only with files from hard disk but also the data stream provided by UCESB, we could also use it for online analysis.
We could then adapt this unpacker to the specific structure of our experimental data.</p>
<p><br>
</p>
<p>However, as UCESB itself is (as I understand) an unpacker for LMD data, probably the better way would be to use UCESB for basic unpacking into LMD events/subevents and then as a second stage a dedicated mapper (which in an ideal world would result from the
settings of the modules in main.cfg) to interpret the data words. This is (again: as I understand it) the approach taken by Bastian. This second stage could then curate/organize the data and give it to subsequent programs in a more user-friendly data format
than plain LMD structures.</p>
<p><br>
</p>
<p>However, I see little use to invest time into the existing NUPELINE package if Bastian was basicly the only person maintaining it. Is there maybe something else 'on the market'? Or am I mistaken and there is somebody out there, who is also continuing to
use NUPELINE?</p>
<p><br>
</p>
<p>(Sorry, if this e-mail is a bit repetitive. I just want to make sure that my understanding of the situation is correct.)<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<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> Freitag, 22. März 2024 13:06<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Question on UCESB / UPEXPS</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
feel free to respond to issues separately, it was quite a bunch of <br>
questions :-) (I like!)<br>
<br>
On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> we have now checked the code for the SIS3316 module and will push a version<br>
> with some bug fixes soon.<br>
<br>
That is excellent news!<br>
<br>
> The next thing on our list is to understand how we can access and store the<br>
> data that we produce. Bastian told us the following command to write LMD<br>
> files to hard disk:<br>
> <br>
> <br>
> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl<br>
> localhost --file-open=auto=1Gi,${file}<br>
> <br>
> How does this LWROCCTRL work together with the Event Builder and UCESB which<br>
> are started by the following commands?<br>
> <br>
> ../drasi/bin/lwrocmerge \<br>
> --label=MCAL_EB \<br>
> --merge-mode=event \<br>
> --server=trans,flush=1 \<br>
> --server=stream,flush=1 \<br>
> --buf=size=800Mi \<br>
> --max-ev-size=10Mi \<br>
> --eb-master=rio4-mcal-2 \<br>
> --file-writer \<br>
> --drasi=rio4-mcal-2<br>
> <br>
> ------------------------------------<br>
<br>
lwrocctrl works by communicating with drasi instances.<br>
for the lwrocctrl --file... options, it should be an instance which has a <br>
--file-writer specified.<br>
<br>
You can run the lwrocctrl also from another machine (e.g. your PC), but <br>
then instead of 'localhost' give the name (or IP) of the machine where the <br>
instance is running.<br>
<br>
For the communication to work, both have to find a directory <br>
~/.drasi_tokens/ with one or more common files which it will do a cheap <br>
hash of. That is just some very minor protection against mistakes (users <br>
talking with the wrong machine. It is not a security measure as such.<br>
<br>
To see if an instance is willing to talk, you can try<br>
<br>
PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node]<br>
<br>
> <br>
> while :<br>
> do<br>
> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \<br>
> stream://localhost \<br>
> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001<br>
> sleep 5<br>
> done <br>
<br>
That connects to the server above (lwrocmerge) started with <br>
--server=stream.<br>
<br>
And its --server option means it will act as a kind of proxy server. I.e. <br>
other users that want data can connect to that instead of directly to the <br>
DAQ process.<br>
<br>
> Moreover, to read in the online data stream as well as the LMD files from<br>
> disk, to us it looks like Bastian used a programm called UCESB_IN which is<br>
> using a mapping that is defined within UPEXPS to interpret the content of<br>
> the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to<br>
> do a mapping of the content of the LMD events and to send out a data stream<br>
> of some of this content. Attached please find the configuration file for<br>
> UCESB_IN.<br>
<br>
The attached .cfg file looks like a setup for Bastii's nupeline, which I <br>
have very little clue about.<br>
<br>
Indeed it sure looks like it in turn uses an UCESB unpacker. With the <br>
source in upexps. That (upexps) has maintenance issues.<br>
<br>
Perhaps someone else reading this mailing list is also using unpackers <br>
from the upexps? If so, now would be a good time to speak up, because I <br>
think we need to figure out how to have something backwards compatible and <br>
maintainable for you, without being 'encouraged' to do the maintenance <br>
work that other users at GSI (R3B) refuse to do...<br>
<br>
> Here, we are not sure up to which point there is a common approach to read<br>
> experimental data and beyond that everybody is on his own.<br>
<br>
... while still sharing as much as possible with other users.<br>
<br>
> Many thanks and best greetings from Jena<br>
> Günter<br>
<br>
Cheers,<br>
Håkan</div>
</span></font></div>
</div>
</body>
</html>