lietava / AliceO2

O2 software project for the ALICE experiment at CERN
GNU General Public License v3.0
0 stars 0 forks source link

Mc to digit #6

Open lietava opened 3 years ago

lietava commented 3 years ago

Is your output simply a collection of triggerInputs from detectors? I thought you should apply some logic and generate a decision?

@lietava lietava on Mar 28 • Author Contributor Yes, good question. I need to calculate trigger classes . My thoughts are following. I can do it either here in Digitizer or later in Digit to Raw transformation. In either case trigger classes are function of trigger inputs depending the CTP configuration. So we would need to create CTP configuration in GRPC ? Please, suggestions and examples.

PS other: I can not compile at the moment - it fails on GEANT4_VMC. 1.) is always branch dev able to compile ? 2.) how can I get ground state for aliBuild compilation, e.g. if I remove BUILD is it enough ?

@shahor02 shahor02 on Mar 28 Collaborator Digit->raw transformation is important for the code validation, full system test etc., but it will not be done in the routine MC productions. So, I think you should calculate the CTP response in the digitization.

In either case trigger classes are function of trigger inputs depending the CTP configuration. So we would need to create CTP configuration in GRPC ?

I guess you mean GRP object? Why not CTP-specifics objects line in Run2? I assume for the anchored MC productions the CCDB data object will be used. For the tests, you can created a dummy one in the http://ccdb-test.cern.ch:8080 (see https://github.com/AliceO2Group/AliceO2/tree/dev/CCDB if you haven't seen it yet). As an example of ccdb configuration creation you can see the ZDC macro .

@lietava lietava on Mar 29 Author Contributor The database is not implemented yet. Trigger classes calculation is implemented in Digitizer. Please, let me know if 1.) overall structure is ok 2.) if memory issues (gpl::scan/vectors usage) are ok.

shahor02 commented 3 years ago

Please, let me know if 1.) overall structure is ok 2.) if memory issues (gpl::scan/vectors usage) are ok.

So far I see only CTPDigitizer, which looks ok in terms of inputs (uses spans), but actually don't need to copy the input spans to the vector before passing them to Digitizer::process (btw, the function having span as an argument, can be directly called passing the vector reference, no need to create its span beforehand, as in https://github.com/AliceO2Group/AliceO2/blob/d890f8a426bdce8e41f5012dee9421cf8ad73d4d/Steer/DigitizerWorkflow/src/CTPDigitizerSpec.cxx#L65.