Project

General

Profile

Swizzle » History » Version 22

Eric Church, 05/14/2015 10:23 PM

1 16 Michael Kirby
h1. Instructions for setting up to swizzle.
2 1 Eric Church
3 1 Eric Church
When you swizzle -- that is, convert from the DAQ binary to ART ROOT data format -- you want to read the binary data with the guaranteed-same code with which you wrote it. That is the reason for the existence in the first place of uboonedaq_datatypes. It's its own ups package against which we set up and build for both the DAQ running and the swizzling. 
4 1 Eric Church
5 18 Michael Kirby
---------------start of edits from Kirby-------------------------
6 18 Michael Kirby
7 17 Michael Kirby
If all you want is to run with a LArSoft -- particularly, the uboonecode build -- that was built against this version of uboonedaq_datatypes you can do that as described in this section. We have installed this version for v5_00_01. So, set up on @ubdaq-prod-near1.fnal.gov@ as follows. Do not set up as if you were going to do DAQ readout or run control or develop uboonedaq_datatypes. These instructions will allow you to swizzle in larsoft v04_05_00 files that were generated with uboonedaq_datatypes v05_00_01 (which as of May 11, 2015 are the only binary *.ubdaq files that have been recorded).
8 17 Michael Kirby
9 17 Michael Kirby
@
10 17 Michael Kirby
scp ubdaq-prod-near1:/datalocal/kirby/swizzler_v04_05_00.tgz ./
11 17 Michael Kirby
tar xzf swizzler_v04_05_00.tgz
12 17 Michael Kirby
cd swizzler_v04_05_00
13 17 Michael Kirby
source /uboone_offline/setup
14 17 Michael Kirby
export PRODUCTS=`pwd`/localProducts_larsoft_v04_05_00_e7_prof:${PRODUCTS}
15 17 Michael Kirby
setup uboonedaq_datatypes v5_00_01 -q e7:prof
16 17 Michael Kirby
setup uboonecode v04_05_00 -q e7:prof
17 17 Michael Kirby
lar -c ./localProducts_larsoft_v04_05_00_e7_prof/rawtorootconvert.fcl
18 17 Michael Kirby
@
19 17 Michael Kirby
20 17 Michael Kirby
You will need to modify the rawtorootconvert.fcl to point at your binary ubdaq file, and possibly modify that output file name. Note that %ifb takes the input file basename and then tacks on additional information, in the case of the provided fcl file "_swizzled_v04_05_00.root".
21 17 Michael Kirby
22 17 Michael Kirby
-------------- end of edits from Kirby --------------------------
23 21 Eric Church
@source /uboone_offline/setup
24 21 Eric Church
export PRODUCTS=$PRODUCTS:/uboonenew
25 21 Eric Church
setup uboonedaq_datatypes v6_08_00 -qe7:debug
26 21 Eric Church
setup uboonecode v04_08_00 -qe7:debug                    
27 1 Eric Church
setup mrb; setup git; setup gitflow
28 2 Eric Church
export MRB_PROJECT=larsoft@
29 1 Eric Church
Go run your @lar -c job.fcl@ script. 
30 6 Eric Church
31 1 Eric Church
You may stop here if you care nothing about maintaining/installing or how the sausage is made. 
32 2 Eric Church
33 1 Eric Church
h1. There is one important technical issue here for running LArSoft on the DAQ.
34 1 Eric Church
35 1 Eric Church
That is, LArSoft runs gcc4.9.1 and boost 1.59, and the DAQ uses gcc4.7, boost1.55. We begin by making a vx_yy_zz version of uboonedaq_datatypes with these new qualifiers. Go to the quickstart page for uboonedaq_datatypes at the top of the DAQ wiki and jump to the bottom of those instructionns to see how we do that, if interested.
36 2 Eric Church
37 17 Michael Kirby
h1. LArSoft installed on the LArTF cluster.
38 1 Eric Church
39 17 Michael Kirby
--------------start of edits from Kirby -------------------
40 1 Eric Church
41 17 Michael Kirby
The uboonedaq_datatypes is now installed on both the online cluster and in the /grid/fermiapp/products/uboone/ area and so we are not limited to development on the online cluster. As well, the offline area has moved from /uboone/larsoft/ to /uboone_offline/ area. That area has had larsoft v04_05_00 and v04_06_00 installed as of May 11, 2015. You can see the manifest of the larsoft installs by looking at MANIFEST files in /uboone_offline/.  Starting with v04_08_00, we are hoping that uboonecode will have a dependency against uboonedaq_datatypes built into it so that it will be configured correctly without doing so by hand.
42 1 Eric Church
43 17 Michael Kirby
Installing LArSoft is conveniently handled by going to the FNAL scisoft server and downloading the http://scisoft.fnal.gov/scisoft/bundles/tools/pullProducts file to some local area on your machine at LArTF. Then, as uid products, run the script to install the binaries to /uboone_offline/. (No need to build from source, since we're on SLF6.) pullProducts will know to update to a new vx_yy_zz directory, if indeed you're keen to do this.
44 17 Michael Kirby
45 17 Michael Kirby
-------------end of edits from kirby --------------------
46 17 Michael Kirby
47 21 Eric Church
The DAQ does not want to move up versions of LArSoft -- maybe ever -- but certainly not often. ups makes this doable, however, if it does become necessary. ubdaq-prod-evb:/uboone/larsoft currently holds v04_08_00 and a few older versions of installed LArSoft. e.g., LArSoft v04_06_03_01 is there -- the version that MicroBooNE's MCC6 used.
48 17 Michael Kirby
49 16 Michael Kirby
h1. Developing in LArSoft with the ubdaq-prod- installation.
50 1 Eric Church
51 16 Michael Kirby
--------------start of edits from Kirby -------------------
52 16 Michael Kirby
53 16 Michael Kirby
For now though, to develop against the uboonedaq_datatypes that are in installed online and offline, If we want to develop LArSoft, we must, in the usual way, form a release area on ubdaq-prod-evb at /home/user/larsoft. Setup as at the top of this page. Then do a @mrb newDev v04_05_00 -T prof.slf6.v04_05_00@, as usual. In srcs pull the code and importantly, *switch to the branch that knows how to build against uboonedaq_datatypes. Do:* @mrb g -b feature/ubdaq uboonecode; mrg g -b feature/davidc1_daqheader lardata@
54 16 Michael Kirby
55 16 Michael Kirby
There are modifications that need to be made within these packages:
56 16 Michael Kirby
57 19 Michael Kirby
change the lardata/ups/product_deps to have these versions
58 19 Michael Kirby
59 19 Michael Kirby
@
60 1 Eric Church
parent  lardata v04_04_00
61 1 Eric Church
defaultqual     e7
62 19 Michael Kirby
63 16 Michael Kirby
fcldir product_dir job
64 19 Michael Kirby
65 16 Michael Kirby
product         version
66 1 Eric Church
larcore         v04_04_00
67 16 Michael Kirby
nutools         v1_09_01
68 16 Michael Kirby
gcc             v4_9_2
69 16 Michael Kirby
70 19 Michael Kirby
cetbuildtools   v4_04_02
71 16 Michael Kirby
end_product_list
72 1 Eric Church
73 1 Eric Church
qualifier       larcore         nutools         gcc     notes
74 1 Eric Church
e7:debug        e7:debug        e7:debug        -nq-
75 1 Eric Church
e7:opt          e7:opt          e7:opt          -nq-
76 16 Michael Kirby
e7:prof         e7:prof         e7:prof         -nq-
77 16 Michael Kirby
end_qualifier_list
78 19 Michael Kirby
@
79 16 Michael Kirby
80 19 Michael Kirby
change the uboonecode/ups/product_deps to have these versions
81 19 Michael Kirby
82 19 Michael Kirby
@
83 16 Michael Kirby
parent uboonecode v04_05_00
84 16 Michael Kirby
defaultqual e7
85 16 Michael Kirby
86 1 Eric Church
product          version
87 1 Eric Church
larsoft         v04_05_00
88 1 Eric Church
ubutil          v01_16_00
89 1 Eric Church
postgresql      v9_1_15
90 1 Eric Church
gcc        v4_9_2
91 16 Michael Kirby
uboonedaq_datatypes v5_00_01 #and the matching qualifiers below
92 16 Michael Kirby
93 16 Michael Kirby
cetbuildtools    v4_04_02    -    only_for_build
94 19 Michael Kirby
@
95 16 Michael Kirby
96 19 Michael Kirby
For some reason I can't figure out, the uboonecode/CMakeList.txt and lardata/CMakeList.txt need to be modify with -std=c++1y
97 19 Michael Kirby
This is done by:
98 19 Michael Kirby
99 19 Michael Kirby
@
100 1 Eric Church
cet_set_compiler_flags( DIAGS CAUTIOUS
101 1 Eric Church
  WERROR
102 1 Eric Church
  NO_UNDEFINED
103 1 Eric Church
  EXTRA_FLAGS -pedantic -Wno-unused-local-typedefs -std=c++1y
104 1 Eric Church
)
105 19 Michael Kirby
@
106 19 Michael Kirby
107 19 Michael Kirby
Then building with:
108 19 Michael Kirby
109 19 Michael Kirby
@
110 19 Michael Kirby
cd ../build_XXX
111 19 Michael Kirby
mrbsetenv
112 19 Michael Kirby
mrb i -j4
113 19 Michael Kirby
@
114 16 Michael Kirby
115 16 Michael Kirby
---------end kirby edits ---------------
116 11 Eric Church
117 15 Eric Church
The issue now is getting the uboonecode repository's @uboonecode/uboone/RawData/utils/LArRawInput*@ files to compile/link against our uboonedaq_datatypes and not the data structures that are hand-copied there. That unsavory manner is how uboonecode's develop branch works currently.
118 5 Eric Church
119 22 Eric Church
If we want to develop LArSoft, we must, in the usual way, form a release area on ubdaq-prod-evb at /home/user/larsoft. Setup as at the top of this page. Then do a @mrb newDev vxx_yy_zz -T debug.slf6.vxx_yy_zz@, as usual. In srcs pull the code and importantly, *switch to the branch that knows how to build against uboonedaq_datatypes. Do:* @mrb g uboonecode; git checkout feature/ubdaq@. At some point maybe we will merge this branch into uboonecode's develop. However, doing that commits us to having uboonedaq_datatypes installed for all of LArSoft. It requires a push to /grid/fermiapp/products and a push to cvmfs, and as yet, we aren't ready to commit to that. Also, it can be argued swizzling and thus the dependence on uboonedaq_datatypes should be confined to the ubdaq-prod machines. For now, we work in feature/ubdaq. 
120 22 Eric Church
121 22 Eric Church
Thus,
122 22 Eric Church
@source /uboone_offline/setup
123 22 Eric Church
export PRODUCTS=$PRODUCTS:/uboonenew
124 22 Eric Church
setup uboonedaq_datatypes v6_08_00 -qe7:debug
125 22 Eric Church
setup larsoft v04_08_00 -qe7:debug                    
126 22 Eric Church
setup mrb; setup git; setup gitflow
127 22 Eric Church
export MRB_PROJECT=larsoft
128 22 Eric Church
cd /home/user/larsoft/debug.slf6.vxx_yy_zz@ and 
129 22 Eric Church
source localProductsxyz/setup
130 22 Eric Church
mrbsetenv
131 22 Eric Church
mrb i -j32@.