knoepfel
commented
2 years ago @gaponenko, thank you for the issue report. The art developers have discussed this, and we'd like to propose some alternative solutions. For both proposals below, we use the configuration:
# BitsPass_t.fcl file
physics: {
...
p1a: [ "f1", m1a ]
p2a: [ "f2", m2a ]
p3a: [ "f3", m3a ]
p4a: [ "f4", m4a ]
p5a: [ "f5", m5a ]
p6a: [ "f6", m6a ]
e1: [ a1 ]
e2: [ outp1a, outp2a, outp3a, outp8a ]
e4: [ outp4, outp5 ]
e5: [ outp6 ]
e6: [ outp7 ]
}Please let us know if Mu2e is willing to consider either of these options as a solution to this issue.
1. Using current functionality
The trigger/end paths used by a framework configuration are provided through the art -c BitsPass_t.fcl --summary-config=detailed command line:
knoepfel@scisoftbuild01 $ art -c BitsPass_t.fcl --config-summary=detailed
...
==================================================
Trigger paths: 6
Bit Path name Path size
--- --------- ---------
0 p1a 2
1 p2a 2
2 p3a 2
3 p4a 2
4 p5a 2
5 p6a 2
==================================================
End paths: 5
Path name Path size
--------- ---------
e1 1
e2 4
e4 2
e5 1
e6 1This output can then be parsed to yield shell variables with path names (credit to @chissg for the sed expression):
knoepfel@scisoftbuild01 $ eval "$(art -c BitsPass_t.fcl --config-summary=detailed | sed -Ene '/^Bit\b/,/^====/ s&^[[:space:]]*([[:digit:]]+)[[:space:]]+([^[:space:]]+).*&tp[\1]="\2"&p' -e '/^Path name/,$ s&^([^[:space:]]+)[[:space:]]+[[:digit:]]+&ep+=("\1")&p')"
knoepfel@scisoftbuild01 $ echo ${tp[*]}
p1a p2a p3a p4a p5a p6a
knoepfel@scisoftbuild01 $ echo ${ep[*]}
e1 e2 e4 e5 e62. Automatically create the trigger_paths and end_paths variables when necessary
It would not be difficult for us to make the configuration post-processing step insert the trigger_paths and end_paths parameters into the final configuration. For example, upon printing the full post-processed configuration above, you would see something like:
knoepfel@scisoftbuild01 $ art -c BitsPass_t.fcl --debug-config=stdout
...
physics: {
...
p1a: [ "f1", m1a ]
p2a: [ "f2", m2a ]
p3a: [ "f3", m3a ]
p4a: [ "f4", m4a ]
p5a: [ "f5", m5a ]
p6a: [ "f6", m6a ]
e1: [ a1 ]
e2: [ outp1a, outp2a, outp3a, outp8a ]
e4: [ outp4, outp5 ]
e5: [ outp6 ]
e6: [ outp7 ]
+ trigger_paths: [p1a, p2a, p3a, p4a, p5a, p6a]
+ end_paths: [e1, e2, e4, e5, e6]
}With this approach, you could do the following:
knoepfel@scisoftbuild01 $ art -c BitsPass_t.fcl --debug-config full.fcl
** Config output to file 'full.fcl' **
knoepfel@scisoftbuild01 $ program_that_requires_explicit_end_paths full.fclThat way, art's behavior does not change, but you have access to the information you require.
greenc-FNAL
gaponenko
Re: art end_paths handling
Hello,
If there is a physics.end_paths parameter defined in a job configuration file, the modules mentioned there will be run at the appropriate time. This part of logic is clear an unambiguous. If the physics.end_paths parameter is missing, one possible interpretation of the configuration is to do nothing at the end_paths step. Art is trying to be more helpful than that, and runs all possible "paths" given the job configuration.
This ticket is a feature request: I would like to make it posssible to disable the "being helpful" part, and do nothing if no explicit physics.end_paths is defined. I would like this to be a compile-time option, so we can use it when building the Mu2e version of the art main program.
Recently we had an incident where Mu2e production jobs ran and used CPU time, then did not return any outputs from the grid, even though they produced expected outputs in the interactive testing. This was tracked down to a difference in the end_paths interpretation between art and Mu2e grid scripts. A grid script uses fhicl-get to query job configuration for the physics.end_paths parameter, then iterates over the returned content to identify all output modules and figure out what files need to be passed to the data handling. Without the end_paths parameter jobs still produced outputs, but they were not found by the grid script logic.
To avoid such errors in the future, we need to make job configuration handling consistent between art and Mu2e grid scripts. Rather than adding complexity to the system by adding a lot more knowledge about the art framework to the scripts, and trying to re-implement the "being helpful" logic, I would like to simplify things and not run any end_path modules that are not explicitly requested. (I think it would make sense to apply the same logic to trigger_paths as well for consistency.)
Andrei