Functions
art/art/test/Integration/product-aggregation/CMakeLists.txt File Reference

Functions

 art_dictionary (NO_INSTALL) simple_plugin(EventGenerator"module"NO_INSTALL) simple_plugin(ParticleSimulator"module"NO_INSTALL) simple_plugin(Reconstruction"module"NO_INSTALL) simple_plugin(CheckMoreProducts"module"NO_INSTALL USE_BOOST_UNIT) simple_plugin(CheckProducts"module"NO_INSTALL USE_BOOST_UNIT) simple_plugin(AssembleProducts"module"NO_INSTALL) simple_plugin(AssembleMoreProducts"module"NO_INSTALL USE_BOOST_UNIT) simple_plugin(AssembleMoreProductsRobust"module"NO_INSTALL USE_BOOST_UNIT) set(NUM_THREADS 1 2 4 8) set(INDEX 0) foreach(ITHREAD $
 
 list (APPEND PARG_SUFFIXES ${INDEX}) math(EXPR INDEX"$
 
 endforeach () cet_test(Stage1_EventGeneration_w HANDBUILT TEST_EXEC art PARG_THREADS--threads $
 

Function Documentation

art_dictionary ( NO_INSTALL  )

Definition at line 1 of file CMakeLists.txt.

16  : EVENT GENERATION - Simulate 200 events, with 50 events
17 # per output file. This stage creates 4 output files.
18 #
19 # Stage 2: PARTICLE SIMULATION - Typically, this would be the Geant
20 # stage. For this test, we simply assign energies to the particles
21 # generated in stage 1. This stage creates 4 output files.
22 #
23 # Stage 3: EVENT RECONSTRUCTION - In this stage, we would simulate
24 # detector response, etc. For simplicity, we require that the event
25 # have a particle with energy of 50 (arbitrary units) or higher.
26 # This stage creates 8 output files, switching to a new file after
27 # 20 events have been written to the file.
28 #
29 # --- TEST PATH 1 ---
30 #
31 # Stage 4: OUTPUT-FILE CONCATENATION - We simply combine all of the
32 # files from Stage 3 so that the Stage-5 analysis will not require
33 # any custom product aggregation. This stage creates 1 output file,
34 # with all Event products dropped.
35 #
36 # Stage 5: PHYSICS ANALYSIS - We fetch the Run and SubRun products
37 # and check that their aggregated ranges and values (as
38 # automatically performed by the framework) are correct.
39 #
40 # --- TEST PATH 2 ---
41 #
42 # Stage 4: ASSEMBLE PRODUCTS - The purpose of this stage is to test
43 # the SummedValue<T> class. We do this by taking SubRun products:
44 # 1. From an earlier module of the same process, and
45 # 2. From an input file.
46 # We aggregate the products 'by hand' using the SummedValue<T> class,
47 # and then 'put' two new products onto the SubRun once the ranges of
48 # the dependent products are consistent. Since these new products
49 # are not 'put' during each begin/endSubRun call, dummy products
50 # will be inserted into the SubRuns tree. Aggregating these dummy
51 # products with the one product that is 'put' will be tested in
52 # Stage 5. This stage creates 1 output file, with all Event products
53 # dropped.
54 #
55 # Stage 5: PHYSICS ANALYSIS - Now, we make the same types of checks
56 # we made in PATH 1, Stage 5, except we also check that the new
57 # products 'put' in Stage 4 are correctly aggregated--i.e.
58 # aggregating the 'put' product with the dummy products should
59 # result in the same value as just the 'put' product. There are no
60 # outputs with this stage.`
61 #
62 # N.B. This series of tests is fragile in that it relies on consistent
63 # random-number generation--i.e. the numbers as produced by a
64 # generator for a given distribution are always the same for the
65 # same C++ code. Different compiler implementations may do
66 # things differently -- i.e. we might need to adjust this set
67 # of tests whenever we adopt clang in addition to gcc.
68 #
69 # PATH 1 product schematic
70 #
71 # Product | PROCESS NAME
72 # creation |
73 # location | eventGen particleSim reco concat checkProducts
74 # ========================================================================================
75 # beginRun | Geometry------------------------------------------->
76 # |
77 # beginSubRun | CalibConstants-------------------->
78 # |
79 # event | GenParticles-------------------------------------------x (dropped)
80 # | particleEnergies----------------------x (dropped)
81 # |
82 # endSubRun | nParticles---------------------------------------------------------->
83 # | TrackEfficiency------------------->
84 # |
85 # endRun | nPOTs--------------------------------------------------------------->
86 #
87 #
88 # PATH 2 product schematic
89 #
90 # Product | PROCESS NAME
91 # creation |
92 # location | eventGen particleSim reco userAssembled checkProducts
93 # =================================================================================================
94 # beginRun | Geometry-------------------------------------------------->
95 # |
96 # beginSubRun | CalibConstants--------------------------->
97 # | TrkEffValue------------>
98 # |
99 # event | GenParticles---------------------------------------------x (dropped)
100 # | particleEnergies------------------------x (dropped)
101 # |
102 # endSubRun | nParticles----------------------------------------------------------------->
103 # | TrackEfficiency-------------------------->
104 # | seenParticles---------->
105 # | ParticleRatio---------->
106 # endRun | nPOTs---------------------------------------------------------------------->
107 
108 set(NUM_THREADS 1 2 4 8)
109 # Need something more complicated if the number of elements in
110 # NUM_THREADS exceeds 10.
111 set(INDEX 0)
112 foreach(ITHREAD ${NUM_THREADS})
number
thus any information present in the drop and needed by the server needs to be added into the ErrorObject that will cross the client server boundary MessageLogger h uses the MessageDrop in the LogDebug macro to learn the value of debugEnabled If debugEnabled is set to then the effect of LogDebug is to immediately return MessageSender cc gets the instance of MessageDrop to find out the moduleName and the runEvent It then places these into the ErrorObject it is forming to pass over to the server This is how the correct event number
Definition: Design_and_maintenance.txt:160
something
InputTag FHiCL entries must follow the or[label, instance, process_name] FHiCL entries FHiCL entries must follow the or[label, instance, process_name] FHiCL entries something
Definition: ParameterSet_get_artInputTag_t-ref.txt:24
of
another_number of
Definition: to_indented_string_annotated_test-ref.txt:6
the
another_number the
Definition: to_indented_string_annotated_test-ref.txt:6
foreach
foreach(ename ${exe_list}) add_executable($
Definition: CMakeLists.txt:33
in
This add method has three it adds this message xid and id to the appropriate and it updates the dynamic information in counts The sequence is as the static apppropriate and timespan will be in the mapped CountAndLimit and there will be no need to recompute them If this xid is not yet in see if the category is in limits if the appropriate counts struct can be formed by using the precedence rules above to combine the limit and interval found in limits along with the severityLimits and severityIntervals arrays found in the ELlimitsTable Along the way the limits map for this category is filled in
Definition: Design_and_maintenance.txt:460
endforeach ( )

Definition at line 115 of file CMakeLists.txt.

119  {NUM_THREADS}
list ( APPEND PARG_SUFFIXES ${INDEX}  )

Definition at line 113 of file CMakeLists.txt.

113  {INDEX})
114  math(EXPR INDEX "${INDEX}+1")
Generated by   doxygen 1.8.11