Skip to content

Reorganize classes inside the ActsObjectDecoration package

Carlo Varni requested to merge cvarni/athena:TrackParticleAnalysis into main

Changing the classes according to the following rules (that should be common rules for all ACTS packages):

  • Class names: algorithms must end with Alg, tools must end with Tool
  • Default values for all Read and Write Handle Keys should be always empty to avoid user misconfigurations at JO level
  • JO configuration functions should be named Acts{class name}Cfg

/cc @pibutti

I have also modified the way we handle decoration moving to WriteDecorHandleKey. In this case I'm obliged to override their key value in the initialize method to properly match the to-be-decorated key

A side note concerning the WriteDecorHandleKeys for @akraszna and @ssnyder . I've noticed that setting these keys in this way:

SG::ReadHandleKey<xAOD::TrackParticleContainer> m_trackParticlesKey {this, "TrackParticleKey", "DEFAULT_VALUE", "Input track particle collection"};
SG::WriteDecorHandleKey<xAOD::TrackParticleContainer> m_measurementRegionKey{this, "MeasurementRegionKey", m_trackParticlesKey,"measurement_region"};

sets the default decoration key to 'DEFAULT_VALUE.measurement_region' and setting a different value for TrackParticleKey in the JO does not automatically modify the decoration name, which remain to the default value. I believe this is because the key name is evaluated in the constructor. Is my understanding correct?

Would it be more sensible to have some logic in the initialize method of the decor key? e.g.:

  1. checks the to-be-decorated key has been initialized
  2. gets the to-be-decorated key value
  3. updates accordingly the decor key name?
  4. initialize the decor key
Edited by Carlo Varni

Merge request reports

Loading