Description of the new CTP simulation code

Accessing the code

The code is in the ATLAS offline CVS repository. It can be viewed using this link. The new code is in the branch called TrigT1CTP-01-02-07-branch.

It is meant to be used with one of the recent 12.X.0 nightiles. (It needs the new trigger configuration packages.)

Additional stuff needed

The simulation uses a preliminary version of the CTP RDO object called CTP_RDO. It is placed in the TrigT1Result package in my development setup. (It is not checked into CVS.) Also the TrigT1EventAthenaPool package has to be modified to create POOL converters for this class.

Modified versions of the TrigT1Result and TrigT1EventAthenaPool packages are put into my public folder under: /afs/cern.ch/user/k/krasznaa/public/CTP/ But the packages I took as basis for these are actually quite old, so anyone wanting to do any work with the CTP simulation code should move the CTP_RDO object from these packages to his/her testing area, patching the current CVS version of these packages.

Layout of the code

The top-level algorithm of the CTP simulation is called CTPSimulation. (It's a usual Athena algorithm.)

Some of the ideas behind the simulation:

The simulation takes the vector of TrigConf::TriggerThreshold objects, and creates a LVL1CTP::ThresholdMap with it. This map creates one LVL1CTP::CTPTriggerThreshold object for each TrigConf::TriggerThreshold object. These are used to read out the multiplicities sent to the CTP in a "smart" way. The actual multiplicity sent to the CTP for a given trigger threshold can be retrieved in the code with something like this:

unsigned int multiplicity = m_thresholdMap->decision( confThreshold )->value();

Where m_thresholdMap is the LVL1CTP::ThresholdMap object created with the vector of TrigConf::TriggerThreshold objects and confThreshold is a pointer to a TrigConf::TriggerThreshold object. Filling the multiplicities in the various thresholds can be done with code much like this.

The design is very similar for the TrigConf::TriggerItem-s as well. The simulation creates a LVL1CTP::ItemMap object with the vector of TrigConf::TriggerItem-s and the prescale set of the items. It creates one LVL1CTP::CTPTriggerItem object for each TrigConf one. It is meant to be used with the proper simulation of LVL1 prescales, but it still needs some work.

For using the new CTP simulation with the full LVL1 simulation that still uses the XML based trigger configuration, the CTP sim. can be run in a legacy mode. In this mode the "UseLegacyInterface" parameter of the algorithm has to be set to true. It is important to understand, that even in this mode the simulation needs the new trigger configuration. It can only be used when the LVL1ConfigSvc service is configured with the "CreateLegacyObjects" parameter set to true. (It is important that the old and new configuration classes in memory are consistent!)

In this mode, a LVL1CTP::LegacyThresholdMap object is created by the simulation that associates trigger thresholds from the new configuration with trigger thresholds of the legacy configuration. This map is used when filling the LVL1CTP::CTPTriggerThreshold objects with multiplicities (sent accoring to the legacy configuration by the LVL1 sub-systems) in the execute() method.

According to the running mode, two methods of the CTPSimulation algorithm can be chosen from to extract the multiplicities sent to the CTP for the various thresholds. The choice between the two is made at initialization, and the correct one is called through a function pointer in the execute method.

• The CTPSimulation::extractLegacyMultiplicities() method fills the multiplicities in the LVL1CTP::CTPTriggerThreshold objects with the assumption that the multiplicities are layed out in the data sent to the CTP according to the legacy configuration. (The layout is quite criptic in some places, and to be honest I only tested that the muon multiplicities are sent correctly in this mode. Much of this code was copied from the "old" CTP simulation.)

• The CTPSimulation::extractMultiplicities() method on the other hand assumes that the multiplicities are encoded using the new trigger configuration. (Namely the information stored in the TrigConf::TriggerThreshold objects.) It should generally work, but as none of the LVL1 subsistems can read the new trigger configuration to date, it has never been tested!

When the multiplicities are extracted, the output of the CTP (DAQ and RoI) is built with the LVL1CTP::ResultBuilder class.

It calculates the PIT, TBP, TAP and TAV words of the output.

• The multiplicities in the PIT words are calculated using the information stored in the LVL1CTP::CTPTriggerThreshold objects. (The last PIT word, containing special informations not available in the simulation is not calculated.)

• The trigger words are calculated using the LVL1CTP::CTPTriggerItemNode class. The whole class actually only has one static function, but as this function is kind of stand-alone, I found it a better design to put it in a separate class. So the function takes the top TrigConf::TriggerItemNode of the trigger item in question, and the LVL1CTP::ThresholdMap object set up with the correct multiplicities. It is a recoursive function calling itself for every new TrigConf::TriggerItemNode object in the trigger item's decision tree. In the end it returns a true or false for the trigger item. At the moment the TAP and TAV words are calculated in the same way!

Be careful, that the ResultBuilder object creates new CTPSlink and CTP_RDO objects which have to be deleted by the caller function if they are not needed. But as these objects are supposed to be saved in StoreGate, they mustn't be deleted by the CTP simulation.

-- AttilaKrasznahorkay - 24 Jul 2006