Project

General

Profile

Feature #24526

Request that the art team take on support for fhicl-summary

Added by Rob Kutschke 5 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
06/09/2020
Due date:
% Done:

100%

Estimated time:
Spent time:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
Duration:

Description

Mu2e has developed a fhicl utility that reads in a fhicl file and prints various levels of summaries of what the fhicl file is instructing art to do. The Mu2e fhicl code base is a set of deeply nested includes ( needed to ensure single points of maintenance) and it is sometimes difficult to understand what a job is doing. I use this tool along with fhicl-dump to figure that out.

We ask that the art team incorporate fhicl-summary into the fhicl-cpp product . We also have similar request for to fhicl-dump fhicl-getpar, which is discussed in issue #23751

The source code can be found at: https://cdcvs.fnal.gov/projects/mu2e-tools-bintools

You will need to use the readonly equivalent url. It is deployed as the ups product mu2ebintools, which is automatically setup when you setup mu2etools. See the PS for some details.

To see an example of it in use, log in to cluck or any of the mu2egpvm machines:

setup mu2e
source /cvmfs/mu2e.opensciencegrid.org/Offline/v09_04_00/SLF7/prof/Offline/setup.sh
setup mu2etools
Look a the file: /cvmfs/mu2e.opensciencegrid.org/Offline/v09_04_00/SLF7/prof/Offline/Validation/fcl/reco.fcl

This expands to over 10,000 lines with 24 trigger paths defined. The trigger_paths variable is not defined.

The tool has 3 verbosity levels:

fhicl-summary --help
fhicl-summary /cvmfs/mu2e.opensciencegrid.org/Offline/v09_04_00/SLF7/prof/Offline/Validation/fcl/reco.fcl
fhicl-summary -v /cvmfs/mu2e.opensciencegrid.org/Offline/v09_04_00/SLF7/prof/Offline/Validation/fcl/reco.fcl
fhicl-summary -vv /cvmfs/mu2e.opensciencegrid.org/Offline/v09_04_00/SLF7/prof/Offline/Validation/fcl/reco.fcl

It is this functionality that we would like to see supported by the art team, either as a standalone executable or as a command line option to art. Supporting more fine grained requests would also be great; for example just printing out the names of all of the trigger paths and nothing else.

Rob

PS. There is a weirdnesss that we currently manage in an ugly way and is a side reason why we would like the art team to pick up all of mu2ebintools. Both fhicl-summary and fhicl-getpar are built against FHICL_CPP. Both are normally used after we have setup art. So we need to ensure that we setup a version of mu2ebintools that is built against the same fcl as the version of art that is currently setup. We have an ugly fix for it that I can discuss if you would like to know about it.

fhicl-summary-v.txt (1.54 KB) fhicl-summary-v.txt Kyle Knoepfel, 06/19/2020 04:23 PM
fhicl-summary-vv.txt (22.7 KB) fhicl-summary-vv.txt Kyle Knoepfel, 06/19/2020 04:23 PM
fhicl-summary.txt (316 Bytes) fhicl-summary.txt Kyle Knoepfel, 06/19/2020 04:23 PM
config-summary.txt (183 Bytes) config-summary.txt Kyle Knoepfel, 06/19/2020 04:23 PM
config-summary-full.txt (9.22 KB) config-summary-full.txt Kyle Knoepfel, 06/19/2020 04:23 PM
config-summary-detailed.txt (1.89 KB) config-summary-detailed.txt Kyle Knoepfel, 06/19/2020 04:23 PM

Related issues

Related to fhicl-cpp - Feature #23751: fhicl-getpar executableClosed12/11/2019

History

#1 Updated by Kyle Knoepfel 5 months ago

#2 Updated by Kyle Knoepfel 5 months ago

  • Status changed from New to Feedback

Having such a facility supported by art seems very natural. The evaluation of which paths have been configured for execution depends on more than just parsing a FHiCL file: it also requires understanding how any user-specified program options may influence the configuration, as well as determining which paths have been enabled for execution, etc.

For that reason, providing a program option to art (e.g. 'art --config-summary[=verbosity-level] ...') would make the most sense.

Does this sound reasonable to you?

#3 Updated by Rob Kutschke 4 months ago

Yes. That sounds reasonable to me.

#4 Updated by Kyle Knoepfel 4 months ago

Rob, is it important that trigger_paths or end_paths values show up in the summary? Or is it simply sufficient to report which paths (or numbers of paths depending on verbosity level) have been enabled, even if the path enablement was achieved through the use of trigger_paths or end_paths?

#5 Updated by Rob Kutschke 4 months ago

If the trigger_paths and end_paths are present, show their value. If they are absent, make it clear that they are absent and also give the list of paths that will be run. That's present in the existing code.

The present code has the notion of ambiguous paths; ie a path that has both analyzer and producer modules. In your implementation, can there be ambiguous paths or will art have already thrown an exception before this information is printed?

#6 Updated by Kyle Knoepfel 4 months ago

With the --config-summary program option, the configuration summary will be emitted only after configuration pruning succeeds. Any ambiguous paths will be detected by the configuration pruner, which will throw an exception with the corresponding error message. In other words, for a summary to be printed, there can be no ambiguous paths in the configuration.

As the art developers have said before, the presence of trigger_paths and end_paths is almost never required, and I would thus like to de-emphasize them in the printout. In the end, the user should only care about which paths have been enabled and their corresponding trigger bits, which the printout will include. How those paths were enabled is only helpful for debugging. To that end, though, I will put a flag in the printout that says whether or not the selected paths were enabled by default or by explicit trigger_paths/end_paths specification.

I understand the current implementation reports the presence/value of trigger_paths and end_paths, but I'm taking the current implementation as a guide for what type of information should be reported, not as the final product. I'll let you know once I have something to show.

#7 Updated by Rob Kutschke 4 months ago

With the --config-summary program option, the configuration summary will be emitted only after configuration pruning succeeds. Any ambiguous paths will be detected by the configuration pruner, which will throw an exception with the corresponding error message. In other words, for a summary to be printed, there can be no ambiguous paths in the configuration.

Great. That's even more authoritative.

As the art developers have said before, the presence of trigger_paths and end_paths is almost never required, and I would thus like to de-emphasize them in the printout. In the end, the user should only care about which paths have been enabled and their corresponding trigger bits, which the printout will include. How those paths were enabled is only helpful for debugging. To that end, though, I will put a flag in the printout that says whether or not the selected paths were enabled by default or by explicit trigger_paths/end_paths specification.

We have a lot of old fcl files that need maintenance. One use case is to see all paths that are defined even if they are not present in trigger_paths or end_paths. We need this to guide refactoring of fcl. Will we still be able to do that?

#8 Updated by Kyle Knoepfel 4 months ago

We have a lot of old fcl files that need maintenance. One use case is to see all paths that are defined even if they are not present in trigger_paths or end_paths. We need this to guide refactoring of fcl. Will we still be able to do that?

Yes--that is true now, and it will remain so. Although the default for the mu2e executable is to suppress the report of unused paths and modules, it can be overridden. I think I would prefer the following:

  • 'mu2e --config-summary[=...] -c <fcl> ...' will summarize only the enabled components of a framework job.
  • 'mu2e --config-summary[=...] -c <fcl> --report-unused=true ...' will emit the names of unused paths and modules during configuration pruning prior to printing the summary of the enabled components.

Is this arrangement acceptable?

#9 Updated by Rob Kutschke 4 months ago

Please go ahead with that plan and I will have a look at the output.

#10 Updated by Kyle Knoepfel 4 months ago

Last question, Rob. The "-vv" option of fhicl-summary does not print the contents of the paths, just their names. Would you like the path contents to also be printed?

#11 Updated by Kyle Knoepfel 4 months ago

Rob, please see the attached files. The fhicl-summary* files correspond to the Mu2e implementation, with their corresponding verbosities. The config-summary* files are generated by the prototype art implementation. The 'detailed' verbosity corresponds to 'v' and the 'full' verbosity corresponds to 'vv'.

I notice that the spacing is off for some of the table headers in the config-summary* files. I can fix that, but before I do too much more, I want to get your sense on whether this is headed in the right direction.

Also, if the --report-unused=true command-line option is used, the following text is printed to the screen before the summary text:

The following module labels are either not assigned to any path,
or they have been assigned to ignored path(s):
'CalHelixFinder', 'CalHelixFinderDmu', 'CalSeedFit', 'CalSeedFitDem', 'CalSeedFitDep', 'CalSeedFitDmm', 'CalSeedFitDmp', 'CalTimePeakFinderMu', 'CalTrkFit', 'CalTrkFitDem', 'CalTrkFitDep', 'CalTrkFitDmm', 'CalTrkFitDmp', 'CrvDigi', 'CrvPhotons', 'CrvSiPMCharges', 'CrvWaveforms', 'DeltaFinder', 'DeltaFinderAna', 'DeltaFinderMu', 'FastCaloCrystalHitFromHit', 'FastCaloRecoDigiFromDigi', 'HelixFinderDmu', 'HelixFinderDpi', 'HelixFinderUe', 'HelixFinderUmu', 'HelixFinderUpi', 'KFFDmuM', 'KFFDmuP', 'KFFDpiM', 'KFFDpiP', 'KFFUeM', 'KFFUeP', 'KFFUmuM', 'KFFUmuP', 'KFFUpiM', 'KFFUpiP', 'KSFDmuM', 'KSFDmuP', 'KSFDpiM', 'KSFDpiP', 'KSFUeM', 'KSFUeP', 'KSFUmuM', 'KSFUmuP', 'KSFUpiM', 'KSFUpiP', 'MHDmuM', 'MHDmuP', 'MHFinalFitDeM', 'MHFinalFitDeP', 'MHFinalFitDmuM', 'MHFinalFitDmuP', 'MHFinderCprDe', 'MHFinderCprDmu', 'MHFinderDe', 'MHFinderDmu', 'MHFinderTprDe', 'MHFinderTprDmu', 'MHSeedFit', 'MHSeedFitDem', 'MHSeedFitDep', 'MHSeedFitDmm', 'MHSeedFitDmp', 'MHUeM', 'MHUeP', 'MHUmuM', 'MHUmuP', 'MergeHelixFinder', 'MergePatRec', 'MergePatRecCpr', 'MergePatRecCprDem', 'MergePatRecCprDep', 'MergePatRecDem', 'MergePatRecDep', 'MergePatRecDmm', 'MergePatRecDmp', 'MergePatRecDpp', 'MergePatRecTpr', 'MergePatRecTprDem', 'MergePatRecTprDep', 'MergePatRecUem', 'MergePatRecUep', 'MergePatRecUmm', 'MergePatRecUmp', 'NewCaloClusterFast', 'PrefetchData', 'ReadTriggerInfo', 'SflagBkgHits', 'TTCalHelixFinder', 'TTCalHelixFinderDm', 'TTCalHelixFinderUCC', 'TTCalHelixFinderUCCDe', 'TTCalHelixUCCMergerDeM', 'TTCalHelixUCCMergerDeP', 'TTCalSeedFit', 'TTCalSeedFitDmm', 'TTCalSeedFitDmp', 'TTCalSeedFitUCCDem', 'TTCalSeedFitUCCDep', 'TTCalTimePeakFinderUCC', 'TTCalTrkFit', 'TTCalTrkFitDem', 'TTCalTrkFitDep', 'TTDeltaFinder', 'TTFKSFDeM', 'TTFKSFDeP', 'TTHelixUCCMergerDeM', 'TTHelixUCCMergerDeP', 'TTKFFDeM', 'TTKFFDeP', 'TTKSFUCCDeM', 'TTKSFUCCDeP', 'TTfastHelixFinder', 'TTfastTimeClusterFinder', 'TTflagBkgHitsUCC', 'TThelixFinderUCC', 'TTmakePHUCC', 'TTmakeSHUCC', 'TTmakeSTH', 'TTtimeClusterFinderUCC', 'TimeClusterFinderDmu', 'TimeClusterFinderDpi', 'TimeClusterFinderUe', 'TimeClusterFinderUmu', 'TimeClusterFinderUpi', 'caloLHCECDCountFilter', 'caloLHCEEventPrescale', 'caloLHCEFilter', 'caloLHCEPrescale', 'caloMVAMixedCECDCountFilter', 'caloMVAMixedFilter', 'caloMixedEventPrescale', 'caloMixedPrescale', 'caloTriggerPreselect', 'cprFetchDigis', 'cprSeedUCCDeMEventPrescale', 'cprSeedUCCDeMHSFilter', 'cprSeedUCCDeMPrescale', 'cprSeedUCCDeMSDCountFilter', 'cprSeedUCCDeMTCFilter', 'cprSeedUCCDeMTSFilter', 'cprSeedUCCDePEventPrescale', 'cprSeedUCCDePHSFilter', 'cprSeedUCCDePPrescale', 'cprSeedUCCDePSDCountFilter', 'cprSeedUCCDePTCFilter', 'cprSeedUCCDePTSFilter', 'fetchCaloDigis', 'fetchDigis', 'makeSTH', 'tprFetchDigis', 'tprHelixDeMEventPrescale', 'tprHelixDeMPrescale', 'tprHelixDeMSDCountFilter', 'tprHelixDePEventPrescale', 'tprHelixDePPrescale', 'tprHelixDePSDCountFilter', 'tprSeedDeMKFFilter', 'tprSeedDePKFFilter', 'tprSeedUCCDeMEventPrescale', 'tprSeedUCCDeMHSFilter', 'tprSeedUCCDeMPrescale', 'tprSeedUCCDeMSDCountFilter', 'tprSeedUCCDeMTCFilter', 'tprSeedUCCDeMTSFilter', 'tprSeedUCCDePEventPrescale', 'tprSeedUCCDePHSFilter', 'tprSeedUCCDePPrescale', 'tprSeedUCCDePSDCountFilter', 'tprSeedUCCDePTCFilter', 'tprSeedUCCDePTSFilter', 'tprTimeClusterDeMEventPrescale', 'tprTimeClusterDeMPrescale', 'tprTimeClusterDeMSDCountFilter', 'tprTimeClusterDePEventPrescale', 'tprTimeClusterDePPrescale', 'tprTimeClusterDePSDCountFilter'

This is the text that is suppressed by the mu2e executable that is not by the art executable. I think we can probably clean the format up a bit.

Interested in your feedback, and thanks.

#12 Updated by Kyle Knoepfel 4 months ago

Rob, will you be able to provide feedback soon? I'm hoping to tag art 3.06 yet this week.

Thanks,
Kyle

#13 Updated by Rob Kutschke 4 months ago

I do not need or want the -vv option to print the content of the paths. If you would like to add a -vvv that does, feel free to do so - I can definitely see the merit in it.

#14 Updated by Kyle Knoepfel 4 months ago

Thanks, Rob. My reason for asking was that it's possible a path may include a negated module name, which would not be clear from the summary. If you think displaying that information is unnecessary, then we don't have to.

I am curious as to your thoughts regarding the printout in the files in note 11. If you think it's acceptable, then we'll call it good and tag soon. Otherwise we can do some more work. If it's easier to do things by Zoom, let me know.

#15 Updated by Rob Kutschke 4 months ago

I really like what you did with the formatting in the files in note 11. It's a big improvement over what I had. I also like the added information, such as the trigger bit info and the number of modules on each path.

I think it's ready to tag. Thanks for getting this in to this release.

#16 Updated by Kyle Knoepfel 4 months ago

  • % Done changed from 0 to 100
  • Target version set to 3.06.00
  • Assignee set to Kyle Knoepfel
  • Status changed from Feedback to Resolved
  • Category set to Infrastructure
  • Experiment Mu2e added
  • Experiment deleted (-)

This feature has been implemented with commit art:c586b20d.

#17 Updated by Kyle Knoepfel 3 months ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF