Skip to content

Add theta-energy calibration parameters - #51

Open
Jullianwatts wants to merge 3 commits into
key4hep:mainfrom
Jullianwatts:maia/theta-energy
Open

Add theta-energy calibration parameters#51
Jullianwatts wants to merge 3 commits into
key4hep:mainfrom
Jullianwatts:maia/theta-energy

Conversation

@Jullianwatts

Copy link
Copy Markdown

This adds ten Gaudi properties to DDPandoraPFANewAlgorithm so a steering file
can hand Pandora a 2D (theta, energy) energy-correction table:

ElectromagneticThetaEnergyCorrection{Enabled, PluginName, ThetaBinEdges, EnergyBinEdges, ScaleFactors}
HadronicThetaEnergyCorrection{Enabled, PluginName, ThetaBinEdges, EnergyBinEdges, ScaleFactors}

Both correction plugins are registered in registerUserComponents() whether or
not a table is supplied. With no table they take the empty overload, which is
the identity, so nothing changes for any existing configuration.
validateThetaEnergyCorrectionSettings() runs at initialize() and fails the job
with the actual sizes it saw if a table has the wrong shape, so a bad table
dies loudly at startup instead of silently miscalibrating.

This is a port of what DDMarlinPandora already did in the Marlin era, so it is
not MuonCollider-specific — any detector using LCContent's nonlinearity
corrections (CLD, ALLEGRO) can use the same properties.

Depends on the LCContent change that adds the three-argument
RegisterNonLinearityEnergyCorrection overload (link to follow once that PR is
open) — this PR cannot compile against LCContent master until that lands,
which is why it's a draft.

Tested: a null test on MAIA reconstruction — same digi input reconstructed
with and without this change loaded, no table supplied, 20 events. Output was bit-identical: every collection name, every collection size, every cluster and PFO energy, largest energy difference exactly 0.0.

Adds ten settings that hand a 2D (theta, energy) table to the LCContent
correction plugin, one set for the EM branch and one for hadronic. This
is the port of what DDMarlinPandora did in v2.11.

Both plugin names get registered whether or not you give it a table, so a
Pandora settings XML naming them always works. With no table they just
multiply by 1.

The table size is checked at startup and the error says what sizes it
actually saw. Getting that wrong is the easiest way to break this, and
without the check you get a vague failure from deep inside Pandora.
@tmadlener

Copy link
Copy Markdown
Member

Configuring this with what are essentially 10 lists of numbers that have to be consistent will be a fun exercise in the future. Can we make this a bit harder to mis-configure? I suppose the maps drop out of some tool in a different format? Can we come up with some format that either directly reads that (if the tool is portable enough) or make the tool write one thing only and then read that back in here?

Could be a root file with a 2D histogram that we then just decompose here, or a single json file with the necessary arrays in one place.

Otherwise config files will just become rows of weird numbers that will be hard to trace back to their origin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants