This exercise is a small aside to reinforce the idea of module labels. It runs a job in which the same module is run three times, configured differently each time.
# ex05.fcl Ex05_module.cc
Read the .cc and .fcl files. Run the .fcl file; observe the printout and understand why it does what it does.
# Reorder the modules in the path e1. Watch the order of printout change.
# Change the path to [ label1, label2, label2 ]; ie repeat a module label; rerun the job. The duplicated module label is only run once ! Why? art presumes that modules do not have side effects and it removes redundant calculations; this may seem werid but it is a feature when your experiments software suite becomes large, and its workflow develops grows many paths.
# Run ex05Activity01.fcl. Read the code. Understand the scope and lifetime of the newly introduced variables. Understand how the static member function works.
# ex05Activoty02.fcl. This is really not for beginners. ( Skip it on your first pass through the workbook? ) Run the .fcl. Read the code. Note the difference in the with Activity01. You will see the method shown in Activity02. We are telling you about it so that you will recognize it. We recommend against it. In this very simple and controlled example it works correctly. As we consider more complex examples in using static member functions, there are race conditions to consider. If these are not dealt with correctly, it may result in subtle, difficult to diagnose incorrect behaviour. The simplest solution
Ideas to discuss
There is one accident here. art does not actually guarantee the order in which modules in an endpath are run.
# Why? art requires that all Analyzer modules be runnable in arbitrary order and that when the order is shuffled they produce the same result (up to trivial reordering of printout ).
# On the other hand, for producer modules, which can add information to the event, and for filter modules, which can change the flow of event processing, the order in which modules run is important. We discuss this later.