You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This suggestion was also brought up by @marc1uk, in reference to PR #187
Some tools (like e.g. PhaseIIADCCalibrator) have slightly different modes of operation depending on the respective use case. For example, PhaseIIADCCalibrator operates on a list of events in the EventBuilding mode, while it only expects one event per Execute step in the normal operating mode.
Currently, the different modes are realized in large if/else statement blocks that make the code a little harder to read.
As a first step, the different modes of operation could be moved to separate functions. This would already clean up the code significantly. A further step might be to move the handling of the different operation modes to a second tool and provide the main tool always with the same data format.
The text was updated successfully, but these errors were encountered:
Evidently I think this is a good idea. As a somewhat independent but very related matter, we never really addressed the situation of analysing Monte Carlo vs Detector Data. Tools such as the TimeClustering and ClusterFinder tools also have if/else sections dedicated to handling the different data sources. The risk with such factoring is that different code is being used to analyse MC and data, which may mean bugs in e.g. data handling aren't picked up because the corresponding MC code is different.
This suggestion was also brought up by @marc1uk, in reference to PR #187
Some tools (like e.g.
PhaseIIADCCalibrator
) have slightly different modes of operation depending on the respective use case. For example,PhaseIIADCCalibrator
operates on a list of events in the EventBuilding mode, while it only expects one event per Execute step in the normal operating mode.Currently, the different modes are realized in large
if/else
statement blocks that make the code a little harder to read.As a first step, the different modes of operation could be moved to separate functions. This would already clean up the code significantly. A further step might be to move the handling of the different operation modes to a second tool and provide the main tool always with the same data format.
The text was updated successfully, but these errors were encountered: