Add podio:input_collections parameter with regex support to filter collections from input files

[Copilot]

This PR implements the podio:input_collections parameter for JEventSourcePODIO, modeled after the existing podio:output_collections parameter in JEventProcessorPODIO. This feature allows filtering which collections are loaded from PODIO input files using both exact collection names and regex patterns.

Problem

Previously, JEventSourcePODIO would always load all available collections from input files. This was problematic when:

• Processing real data that doesn't contain MC truth collections (like MCParticles)
• Optimizing performance by loading only needed collections
• Reducing memory usage for specific analysis tasks

Solution

Added a new podio:input_collections parameter that:

• Accepts a comma-separated list of collection names and regex patterns
• Supports regex patterns like EcalBarrel.* to match multiple collections efficiently
• If not set, loads all collections (preserves backward compatibility)
• If set, only loads collections matching the specified names/patterns

Usage Examples

# Load all collections (default behavior)
eicrecon input.edm4hep.root

# Load specific collections by exact name
eicrecon -Ppodio:input_collections=EventHeader,EcalBarrelScFiRawHits input.edm4hep.root

# Load collections using regex patterns (more convenient)
eicrecon -Ppodio:input_collections=EventHeader,EcalBarrel.*,HcalBarrel.*,SiBarrel.* input.edm4hep.root

# Load only RawHits collections for reconstruction-only pipeline
eicrecon -Ppodio:input_collections=.*RawHits input_with_rawhits.edm4eic.root

Implementation Details

• Added ResolveInputCollections() method that converts regex patterns to actual collection names
• Implemented efficient O(log n) collection filtering using resolved collection sets
• Added thread-safe pattern resolution using std::call_once for first-event processing
• Added informative logging to show filtering behavior
• Maintains full backward compatibility when parameter is not set

Testing

Updated eicrecon-input-collections-test job in GitHub Actions to test a two-stage processing pipeline:

1. Stage 1: Run eicrecon to create all output collections ending with RawHits from simulation input
2. Stage 2: Run eicrecon using only RawHits collections as input (testing the input filtering feature) and create all default output collections
3. Verification: Use podio-dump --category events to list the final output collections

This testing approach better simulates real data processing workflows where only detector hits are available as input, demonstrating the practical value of the input filtering feature for reconstruction-only pipelines.

This addresses the need for real data processing workflows where MC truth information is not available, while providing a user-friendly regex interface for specifying collection patterns instead of exhaustive lists.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[wdconinc]

@copilot I merged the include-what-you-use fixes.

[wdconinc]

@copilot Please add to the eicrecon-input-collections-test check a command (e.g. podio-dump --category events) that lists the output collections that were able to be created from the limited set of input collections.

[Copilot]

@copilot Please add to the eicrecon-input-collections-test check a command (e.g. podio-dump --category events) that lists the output collections that were able to be created from the limited set of ...

Added podio-dump --category events command to the eicrecon-input-collections-test check in commit d6a847b. This command will list the output collections that were created from the limited set of input collections, providing visibility into what collections are successfully processed when using the input filtering feature.

[wdconinc]

Run over the entire input file in eicrecon-input-collections-test.

[wdconinc]

Don't limit output collections.

[github-actions]

Capybara summary for PR 2026

• rec_dis_10x100_minQ2=0_craterlake_10x100
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=0_craterlake_18x275_MT
• rec_dis_18x275_minQ2=0_craterlake_18x275_ST_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275_ST_MT
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-08-22T09:31-04:00 59dd624}}

[wdconinc]

@copilot Let's modify the eicrecon-input-collections-test to do the following instead (and keep it as a new job, with the same name):

1. Run eicrecon to create all output collections that end with RawHits, similar to eicrecon-two-stage-running.
2. Run eicrecon in a next step that uses only the input collections that end with RawHits and creates all output default collections.
3. Keep the podio-dump summary of which output was written.

[Copilot]

@copilot Let's modify the eicrecon-input-collections-test to do the following instead (and keep it as a new job, with the same name):

1. Run eicrecon to create all output collections that end with Ra...

Restructured the eicrecon-input-collections-test to follow the two-stage pattern as requested in commit 59dd624:

1. Stage 1: Creates all output collections ending with RawHits using -Ppodio:output_collections=.*RawHits
2. Stage 2: Uses only RawHits collections as input with -Ppodio:input_collections=.*RawHits and creates all default output collections
3. Summary: Kept the podio-dump --category events command to list final output collections

This better simulates real data processing pipelines where only detector hits are available as input, similar to the eicrecon-two-stage-running workflow.