Pandora plugin to calculate material properties of calorimeters dynamically

[SwathiSasikumar]

BEGINRELEASENOTES

• PandoraPFA uses LayeredCalorimeterData class from DD4hep to store layer-by-layer information e.g radiation length., essential for shower reconstruction and energy measurement.
• In this plugin, using another class from DD4hep, MaterialManager, LayeredCalorimeterData object is dynamically built based on the detector geometry ensuring each calorimeter layer correctly reflects its material composition.
• This plugin can be used for any calorimeter irrespective of its geometry. It is essential to have LayeredCalorimeterData information to run Pandora.
• The changes in the geometry source file ECalBarrel_NobleLiquid_InclinedTrapezoids_o1_v01_geo.cpp and xml file CLD_o4_v05.xml should also be noted to accommodate the plugin.
  ENDRELEASENOTES

[atolosadelgado]

Hi @SwathiSasikumar

Thank you for your PR! It is well-written.

I have one question: Would it be possible or advisable for the plugin to erase any previous data extension? If so, this can be done by adding a few lines I mentioned in the comments, and the detector constructor can be unstaged from the PR

Thank you for your time!

[atolosadelgado]

could you move this line after the print out "Successfully added LayeredCalorimeterData", at the end of the function?

In addition, to be discussed... do you think it is acceptable/advisable to remove any data extension attached by the detector constructor itself? If so, it can be done as follows:

    if( ! caloDetElem->extensions.empty()) {
      dd4hep::printout(PrintLevel::WARNING, LOG_SOURCE, "Removing data extensions from %s", subDetectorName.c_str());
     // delete extensions first, then clear container
     for (auto& p : caloDetElem->extensions) {
         delete p.second;
     }
      caloDetElem->extensions.clear();
    }

This also requires an additional header:

#include <DD4hep/detail/DetectorInterna.h>

This way, the plugin becomes more robust against potential cases where other data extension is hardcoded in the detector constructor (if a previous data extension exists, DD4hep crashes)

[andresailer]

Wouldn't this cause a memory leak?

      caloDetElem->extensions.clear();

[atolosadelgado]

yes, you are right, thank you for spotting it!
I changed my suggestion in the original message

[andresailer]

... do you think it is acceptable/advisable to remove any data extension attached

Actually, it is not advisable to remove all extensions. It might make sense to remove the extension of the type we add here. It might also make sense to throw an error and let the user figure out which extension they want to keep. Maybe add a flag to replace or not an existing extension.

[andresailer]

We need to add a convenience function in dd4hep to make it easier to remove specific extensions. This issue brought up here will be addressed in a later PR then.

[atolosadelgado]

do you think it would be good idea to protect against empty vectors?

// skip layer if no materials found
if( materials.empty() ) continue;

[andresailer]

I think unless rad_first == rad_last it is impossible for there to be no materials between two points? There must at least be the world volume. Or something is more wrong in the geometry than we can protect against here.