o2-ctp-proxy for counters

[lietava]

Hi @shahor02 , from example dcs-config-proxy: https://github.com/AliceO2Group/AliceO2/blob/dev/Detectors/DCS/testWorkflow/src/dcs-config-proxy.cxx I created by trials and errors ctp-proxy: https://github.com/lietava/AliceO2/blob/ctpdev/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx I generate zeromq messages by simple python server: https://github.com/lietava/AliceO2/blob/ctpdev/Detectors/CTP/workflowScalers/py/pub_server.py and ctp-proxy can see them although with some errors.

So my understanding of the final solution is that: 1.) python code will publish counters as 2 part zeromq messages 2.) ctpproxy resend them as dpl messages 3.) ctpproxy filter them and save Run scalers to CCDB Please, let me know your general and technical comments. Cheers, Roman. cc: @mbombara and @mvalarh and @mvala) Happy New Year to all of you.

[shahor02]

Hi @lietava

Happy New Year! Looks fine, what are errors you mentioned? The dcs-config-proxy is a general purpose utility, if you use your version for the ctp scalers only, you can probably avoid the https://github.com/lietava/AliceO2/blob/8a62880e65944373b66682e1bad784237491896d/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L60, since for you the origin is CTP only. Also, do you need the acknowledgment? In case of dcs proxy this was a specific requirement of the DCS team, in general, we don't do this.

[lietava]

Hi @shahor02 , I removed acknowledgement. For the error, please, have a look at ctp-proxy.log. For the moment I am using very simple publisher: zmq publisher In the next step I will need to use structure specified by protobuf. Can I produce header file inside o2 or I need to supply it manually ? Cheers, Roman.

[shahor02]

Hi @lietava The error

[149050:internal-dpl-injected-dummy-sink]: [17:41:00][ERROR] DataHeader::splitPayloadParts invalid
[149050:internal-dpl-injected-dummy-sink]: [17:41:00][ERROR] inconsistent number of inputs extracted

means that you format incorrectly the header of the message you inject into the DPL. Could you show your code?

[lietava]

Hi @shahor02 , here is ctp-proxy.cxx and zmq generator (but it should not depend on it ?): zmq pub

[shahor02]

Hi @lietava I see that you are sending only the header, while every O2 message is made of 2 parts: header and payload. I guess you don't need to send separately the file name and the file, this was requirement for the DCS. Since you have only 1 type of payload, you can probably send just the file. In these case you should use these lines: https://github.com/AliceO2Group/AliceO2/blob/378ec234a2ed6ccae8ac64b1cd5fcfe00ab05bae/Detectors/DCS/testWorkflow/src/dcs-config-proxy.cxx#L87 (adapting the DataDescription as you did in your code)

https://github.com/AliceO2Group/AliceO2/blob/378ec234a2ed6ccae8ac64b1cd5fcfe00ab05bae/Detectors/DCS/testWorkflow/src/dcs-config-proxy.cxx#L89-L102

https://github.com/AliceO2Group/AliceO2/blob/378ec234a2ed6ccae8ac64b1cd5fcfe00ab05bae/Detectors/DCS/testWorkflow/src/dcs-config-proxy.cxx#L111-L117

https://github.com/AliceO2Group/AliceO2/blob/378ec234a2ed6ccae8ac64b1cd5fcfe00ab05bae/Detectors/DCS/testWorkflow/src/dcs-config-proxy.cxx#L125-L128

Also, since you are serving the CTP only, you probably can get rid of getDataOriginFromFilename function and simply use o2::header::DataOrigin gDataOriginCTP.

[lietava]

Hi @shahor02 , thanks a lot , I think I fixed it. Now next question: how to use protobuf in o2: should I produce data header outside the o2 and just add it or can I do it in o2 ?

[shahor02]

Hi @lietava Sorry, I've never used protobuf, better ask @ktf

[ktf]

We do not support protobuf at the moment. I think it was discussed in the past, but we decided against it due to lack of usecase. What would it be in this case, compared to a flat struct or a some ROOT serialised object?

[lietava]

I think the simplest solution is I generate header file locally and include it to o2 by hand. Data structure should not change often. Do you see any problem with that ?

[shahor02]

This is surely possible. The alternative would be to use some container supported by the bare root, e.g. std::unordered_map<string, std::uint64_t> if this is appropriate for the scalers.

[lietava]

This is surely possible. The alternative would be to use some container supported by the bare root, e.g. std::unordered_map<string, std::uint64_t> if this is appropriate for the scalers.

Please, explain alternative a bit more. The protobuf structure is actually simple:

message CntsReply { double timestamp = 1; // epoch time repeated fixed32 cnts = 2 [packed=true]; //34 outcnts counters } //16+18*32+460

[shahor02]

OK, this is indeed better to implement via a specific header file cloned to CTF and O2 code. Note that for time we are using long

[lietava]

@shahor02 : what do you mean by "Note that for time we are using long" ? fixed32 = long ?

[shahor02]

64 bit long

[lietava]

@ktf @shahor02 I just realised I do not know how to do it. I explain. In ctp-proxy.cxx in line https://github.com/lietava/AliceO2/blob/3212fa33d927b0018294c061ee2b9e4f8a08032b/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L52 I get parts which is 2 part message.

How can I interpreted parts.at(1) with the header produced by protobuf (protoc) ? Is it possible in o2 ? ctpd.pb.h.txt

[lietava]

I need to create CntsReply object and call one of its methods with argument parts.at(1) ?

[shahor02]

Hi @lietava As I wrote, since your proxy will serve only CTP, you don't the "name" part on the input, in the DCS proxy it is used only to decide the DataOrigon for the output. Sorry, I am not familiar with protobuf, but if you know how to convert your input object to CntsReply, you should do:

const auto* inputObj = (<YourInputObject*) parts.At(1)->GetData(); 
CntsReply outObj = createFromInputObj(inputObj);

hdrF.tfCounter = *timesliceId; // this also
hdrF.payloadSerializationMethod = o2::header::gSerializationMethodNone;
hdrF.splitPayloadParts = 1;
hdrF.splitPayloadIndex = 0;
hdrF.payloadSize = sizeof(CntsReply);
hdrF.firstTForbit = 0; // this should be irrelevant for DCS
auto fmqFactory = device.GetChannel(channel).Transport();

o2::header::Stack headerStackF{hdrF, DataProcessingHeader{*timesliceId, 1}};
auto hdMessageF = fmqFactory->CreateMessage(headerStackF.size(), fair::mq::Alignment{64});
auto plMessageF = fmqFactory->CreateMessage(hdrF.payloadSize, fair::mq::Alignment{64});
memcpy(hdMessageF->GetData(), headerStackF.data(), headerStackF.size());
memcpy(plMessageF->GetData(), &outObj, hdrF.payloadSize);

FairMQParts outParts;
outParts.AddPart(std::move(hdMessageF));
outParts.AddPart(std::move(plMessageF));
sendOnChannel(device, outParts, channel);

Cheers, Ruben

[lietava]

We do not support protobuf at the moment. I think it was discussed in the past, but we decided against it due to lack of usecase. What would it be in this case, compared to a flat struct or a some ROOT serialised object?

HI @ktf , does it mean that I can not include files required by protobuf header file, e.g. please, see proto buf header ?

[lietava]

HI @shahor02 , I have three unrelated things: 1.) as I understand from @ktf protobuf is not supported by o2, therefore we change publishing to single string which I parse. I need to test it. But this should be transparent for rest of the code. 2.) I do not understand your comment "As I wrote, since your proxy will serve only CTP, you don't the "name" part on the input" - I mean I can not connect it with the part of the code, sorry. 3.) I'd like to understand how the trigger class mask is transferred from ctp readout to aod - question not related to this issue. Maybe we can have a short chat tomorrow or other day ?

[shahor02]

Hi @lietava

(2) this comment referred to the version where you were using the getDataOriginFromFilename method to determine the detector type. I see you have already eliminated this. But I don't understand why do you need to send to the proxy 2 parts: what is the function of the https://github.com/lietava/AliceO2/blob/16f78cefac051e1a8804dbe7c1ae9ed5e20e073c/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L54-L57 ? In the DCS proxy it was used to pass the name of the file sent in the 2nd part. In your case, it is not used at all. BTW, instead of https://github.com/lietava/AliceO2/blob/16f78cefac051e1a8804dbe7c1ae9ed5e20e073c/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L58-L60 you can do simply

o2::header::DataHeader hdrF("CTP_COUNTERS", o2::header::gDataOriginCTP, 0);

For (3): do you really mean AOD (I think it is not done yet) or CTP? Anyway, we can chat tomorrow afternoon, say ~3pm.

[lietava]

ok 3 pm , please, send zoom.

[shahor02]

OK, https://cern.zoom.us/j/8211096370?pwd=M0xzMStUUXczQmVGeUhUZFhSZWFQUT09 ?

[lietava]

Thanks. I am there.

[lietava]

HI @shahor02 , thanks for chat. Next question: do you have some example of the code for receiving the o2 messages created by ctp-proxy (for Marek CTP QC) ?

[shahor02]

Hi @lietava

You can pipe o2-dcs-config-consumer-test-workflow --detector CTP to your proxy, see the example under the https://github.com/AliceO2Group/AliceO2/tree/dev/Detectors/DCS/testWorkflow#dcs-config-proxy