Skip to content

avoid relying on the collections order and maintain flexibility in RecHitMapProducer.cc #48526

@brusale

Description

@brusale

With #48517, in order to have some flexibility on which collections are passed to RecHitMapProducer.cc the input is given as a std::vector<edm::InputTag>.

void RecHitMapProducer::fillDescriptions(edm::ConfigurationDescriptions& descriptions) {
  edm::ParameterSetDescription desc;
  desc.add<std::vector<edm::InputTag>>("hits",
                                       {edm::InputTag("HGCalRecHit", "HGCEERecHits"),
                                        edm::InputTag("HGCalRecHit", "HGCHEFRecHits"),
                                        edm::InputTag("HGCalRecHit", "HGCHEBRecHits")});
  desc.add<bool>("hgcalOnly", true);
  descriptions.add("recHitMapProducer", desc);
}

However, as pointed out in #48517 (comment) this is very fragile as it relies on the correct ordering of the collections to stay in sync with the rest of the associators and validation code.

A first to circumvent this issue was made with 0c8751e but this lead to numerous differences in the validation.

Another solution might be revert back to the situation in which each collection has its own edm::EDGetTokenT.

fyi @mmusich

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions