Project

General

Profile

What Lynn does » History » Version 64

Joe Boyd, 12/10/2019 04:49 PM

1 1 Lynn Garren
h1. What Lynn does
2 1 Lynn Garren
3 30 Lynn Garren
{{TOC}}
4 16 Lynn Garren
5 40 Joe Boyd
h2. Build "third party" ups products as needed for art and larsoft 
6 40 Joe Boyd
7 45 Joe Boyd
<pre>
8 61 Joe Boyd
For immediate term using old methods SciSoft team will have to take care of this,  Jim A should be the one to tell 
9 49 Joe Boyd
these people this but in the future using SPACK here are some examples of people that could maybe take these pieces
10 40 Joe Boyd
11 63 Joe Boyd
  * ROOT: Philippe / Framework and software technology.
12 40 Joe Boyd
  * GENIE: Robert Hatcher / Neutrino Simulation.
13 40 Joe Boyd
  * PostGresQL, Psycopg,  SQLite, MySQL, MariaDB: Scientific Database Applications.
14 59 Joe Boyd
  * nucondb, ifbeam, ifdhc, ifdhc_config, ifdh-art, libwda, etc. (and unique dependencies): Scisoft team 
15 59 Joe Boyd
for ifdh_art, Steve White's group for DB items, Marc Mengel for ifdhc and _config
16 1 Lynn Garren
  * PyTorch, libtorch, TensorFlow, Eigen, Caffe (legacy): Algorithms for
17 1 Lynn Garren
    Reconstruction and Analysis.
18 50 Joe Boyd
19 50 Joe Boyd
  * GEANT4: Krzysztof / Physics and Detector Simulation.
20 56 Joe Boyd
Geant has 3 different releases??
21 50 Joe Boyd
The full set of G4 related products is:
22 50 Joe Boyd
g4abla
23 50 Joe Boyd
g4emlow
24 50 Joe Boyd
g4neutron
25 50 Joe Boyd
g4neutronxs
26 50 Joe Boyd
g4nucleonxs
27 50 Joe Boyd
g4nuclide
28 50 Joe Boyd
g4photon
29 50 Joe Boyd
g4pii
30 50 Joe Boyd
g4radiative
31 50 Joe Boyd
g4surface
32 50 Joe Boyd
g4tendl
33 50 Joe Boyd
geant4 -q e19:mt:prof
34 50 Joe Boyd
geant4 -q e19:prof
35 50 Joe Boyd
geant4 -q e19:qt:prof
36 60 Joe Boyd
qt (artdaq groups supplies qt)
37 1 Lynn Garren
xerces_c
38 60 Joe Boyd
39 55 Joe Boyd
40 55 Joe Boyd
Who will build cry?
41 55 Joe Boyd
42 45 Joe Boyd
</pre>
43 42 Joe Boyd
44 7 Lynn Garren
* We have a [[build-framework:|defined procedure]] that uses a number of scriptlets found in the ssibuildshims product.
45 5 Lynn Garren
* Each product has a tiny redmine repository for the build and bootstrap scripts.
46 9 Lynn Garren
** Scripts include autobuild.sh, bootstrap.sh, build_xxx.sh, and usually ups/xxx.table, where xxx is the product name.
47 9 Lynn Garren
** We sometimes need patch files.
48 9 Lynn Garren
** Other scripts are occasionally included, such as bootstrap_datasets.sh for geant4.
49 10 Lynn Garren
** We tag these repositories with the product version.
50 5 Lynn Garren
* To ensure reproducible builds, we only build from tagged releases.  In rare cases, we use a commit hash.
51 1 Lynn Garren
* We require that the source code be captured in a source code tarball for reproducible builds.
52 6 Lynn Garren
* We bootstrap and run local test builds for the supported compiler options.  This is a rapid turnaround development step.
53 14 Lynn Garren
** Whenever possible, we run unit tests as part of the build procedure and require that these tests pass.
54 6 Lynn Garren
* Once everything looks good, the source code tarball is uploaded to SciSoft.
55 12 Lynn Garren
* Also provide help to people attempting to make their own ups products.
56 5 Lynn Garren
57 48 Joe Boyd
h2.  Build art releases after they are tagged.
58 48 Joe Boyd
59 48 Joe Boyd
<pre>
60 48 Joe Boyd
SciSoft team would take this over
61 48 Joe Boyd
critic distribution includes everything
62 48 Joe Boyd
</pre>
63 1 Lynn Garren
64 1 Lynn Garren
* Kyle sends around an email to the SciSoft Team when a release is tagged.
65 1 Lynn Garren
* Update information in build-framework/CMakeLists.txt
66 1 Lynn Garren
** There are multiple branches for different product configurations
67 1 Lynn Garren
* Run cmake to get the new build configuration files.
68 1 Lynn Garren
* Check the new config files.
69 1 Lynn Garren
** Always compare against the previous release.
70 3 Lynn Garren
* If they are OK, use copyToSciSoft to install ONLY the appropriate build configuration files on SciSoft.  There are html files for each release that also need to be installed.
71 1 Lynn Garren
** canvas
72 1 Lynn Garren
** art
73 1 Lynn Garren
** gallery
74 1 Lynn Garren
** critic
75 1 Lynn Garren
* Start a Jenkins build
76 1 Lynn Garren
** https://buildmaster.fnal.gov/buildmaster/view/Art/job/critic-all/
77 1 Lynn Garren
** The build needs two iterations.  First for python 2 (the LABEL field is empty) and then a second pass with LABEL set to py3.
78 2 Lynn Garren
* Sometimes there are problems with the build.
79 2 Lynn Garren
** Investigate and fix.
80 2 Lynn Garren
** A local test build is sometimes helpful, depending on the problem.
81 2 Lynn Garren
* Once the build has completed successfully, download the tarballs locally and then upload them to SciSoft.
82 2 Lynn Garren
** Work in an empty directory
83 2 Lynn Garren
** copyFromJenkins -N -q c2 -q c7 -q e17 -q e19 critic-all
84 2 Lynn Garren
** copyToSciSoft *
85 4 Lynn Garren
86 35 Joe Boyd
h2. Update other products to use the appropriate release of art (SciSoft team or experiments, see bullet notes)
87 12 Lynn Garren
88 53 Joe Boyd
* artdaq_core (-This should go to the artdaq group -- Eric Flumerfelt-, Lynn says we just need a tag, so Scisoft team with tag from Eric)
89 12 Lynn Garren
** Owned by the artdaq group
90 12 Lynn Garren
** This product is designed to build against several different releases of art, as reflected in the generated table file.
91 12 Lynn Garren
** If the head of develop matches the latest tag, then use git flow to tag against the head of develop.  Otherwise make a release branch against the latest tag and edit product deps.
92 12 Lynn Garren
** We only edit ups/product_deps to make a new release.
93 37 Erica Snider
* ifdh_art (SciSoft)
94 12 Lynn Garren
** This is the ifdh service developed by Marc Mengel at the request of the art team.
95 12 Lynn Garren
** ifdh_art can build against several different releases of art.
96 12 Lynn Garren
** ifdh_art is updated when libwda or ifdhc is updated or if it needs to recognize a new release of art.
97 37 Erica Snider
* nutools (Robert Hatcher?)
98 12 Lynn Garren
** This product is owned by NOvA
99 12 Lynn Garren
** However, larsoft uses it extensively and sometimes makes contributions to the code.
100 22 Lynn Garren
** Any changes beyond those required by a new release of art, genie, or geant4 must be approved.
101 12 Lynn Garren
102 36 Joe Boyd
h2. Build mu distributions ( mu2e should take this over)
103 11 Lynn Garren
104 11 Lynn Garren
* The mu distribution is basically an art distribution with a few additional products.
105 12 Lynn Garren
* The distribution is built when requested.
106 11 Lynn Garren
* Found on a branch of build-framework
107 11 Lynn Garren
108 57 Joe Boyd
h2. Build nutools releases and the nu or nulite distributions.
109 57 Joe Boyd
110 57 Joe Boyd
<pre>
111 58 Joe Boyd
Erica will talk to Laura Fields about Robert Hatcher building nutools
112 64 Joe Boyd
Does NOvA build nu since they're the only user and LArSoft only does nulite???? (Alex Himmel?)
113 57 Joe Boyd
</pre>
114 1 Lynn Garren
115 1 Lynn Garren
* Both NOvA and LArSoft can drive the need for a new release of nutools.
116 11 Lynn Garren
** NOvA uses the full nu distribution.
117 11 Lynn Garren
** LArSoft now uses the nulite distribution which ignores packages that are NOvA specific.
118 29 Lynn Garren
* nutools has been split into modular components.
119 29 Lynn Garren
** This was a staged deployment.  As of nutools v3_05_00, only the CRY interface remains in nutools.
120 29 Lynn Garren
** The nutools suite now contains nusimdata, nugen, nug4, nuevdb, nurandom, and nutools.
121 29 Lynn Garren
** The build configure scripts are now generated from templates in nutools/bundle.
122 11 Lynn Garren
123 32 Joe Boyd
h2. LArSoft release management (SciSoft team plus experiment activity on patch releases)
124 28 Joe Boyd
125 29 Lynn Garren
* Note that the move to github and pull requests will change this workflow.
126 1 Lynn Garren
* Advise and collect information for each weekly release.
127 22 Lynn Garren
** I am often the first point of contact for code changes.
128 22 Lynn Garren
** Sometimes push back about proposed changes.
129 12 Lynn Garren
* Send notices that the release is about to start.
130 12 Lynn Garren
* Make a test build with larsoft and all the experiment code.
131 12 Lynn Garren
** From long experience, if there is more than one set of feature branches to merge, each set must be tested sequentially.
132 12 Lynn Garren
** While this could be done via CI, it is currently more efficient to test on woof.  Especially since overlapping feature branches must sometimes be tested.
133 12 Lynn Garren
** We do encourage anyone submitting a feature branch to run the CI themselves.
134 12 Lynn Garren
* We work on a temporary release branch.
135 12 Lynn Garren
* Once the tests are complete and successful, update the release versions for those packages which will be changing and then tag.
136 12 Lynn Garren
* The tag is merged with master, but not with develop. 
137 12 Lynn Garren
** Merging with develop before the tagged release is available on cvmfs causes all kinds of problems. 
138 12 Lynn Garren
* Build on Jenkins.  Sometimes we find problems during this step.  We move the tag if necessary when resolving problems.
139 12 Lynn Garren
* Once the build is complete, we finalize the release.
140 12 Lynn Garren
** pull the tarballs from Jenkins and upload them to SciSoft
141 12 Lynn Garren
** install the release on cvmfs
142 12 Lynn Garren
** For macOS building, we install the c2 build on /grid/fermiapp/products/larsoft
143 12 Lynn Garren
** make a cross package tag
144 12 Lynn Garren
** make release notes
145 12 Lynn Garren
** final merge with develop
146 12 Lynn Garren
** send an announcement
147 12 Lynn Garren
* The procedure is described in detail at [[larsoft:How_to_tag_and_build_a_LArSoft_vx_yy_zz_release]]
148 12 Lynn Garren
** Although it is tempting to take shortcuts, the procedure is designed to allow the release manager to recover from various problems that may arise.  Taking shortcuts removes those safeguards.
149 13 Lynn Garren
150 32 Joe Boyd
h2.  support various infrastructure products (SciSoft team)
151 15 Lynn Garren
152 15 Lynn Garren
* cetbuildtools and mrb
153 15 Lynn Garren
** both products were originally developed by me, but have significant contributions from others
154 15 Lynn Garren
** We have provided cetmodules for use within spack and are contemplating a move across the board from cetbuildtools to cetmodules.  Details need to be considered.
155 15 Lynn Garren
* larreltools
156 1 Lynn Garren
** Replaces laradmin
157 16 Lynn Garren
** Contains scripts used to build regular and patch releases of larsoft
158 15 Lynn Garren
* larutils
159 15 Lynn Garren
** The larsoft build scripts used on Jenkins reside in larutils
160 15 Lynn Garren
* artutilscripts
161 15 Lynn Garren
** The build scripts used when building art, nutools, etc. on Jenkins reside in artutilscripts. 
162 18 Lynn Garren
** This is also where buildFW, pullProducts, copyFromJenkins, copyToSciSoft, etc. are found.
163 15 Lynn Garren
* laradmin
164 15 Lynn Garren
** This is now only of archival interest
165 15 Lynn Garren
** It contains the record of various larsoft migrations.
166 15 Lynn Garren
167 21 Lynn Garren
h2. SciSoft
168 21 Lynn Garren
169 21 Lynn Garren
* approve requests for read-write access
170 21 Lynn Garren
** The possibility exists for someone to accidentally remove or overwrite products.
171 21 Lynn Garren
** For this reason, we use nfs4 groups to limit read-write access to necessary directories.
172 21 Lynn Garren
** Some members of the SciSoft team have read-write access to all of SciSoft.
173 21 Lynn Garren
* copy files to pnfs for archiving
174 21 Lynn Garren
** There is a procedure, but it is slow and not automatic.
175 21 Lynn Garren
176 13 Lynn Garren
h2. spack
177 13 Lynn Garren
178 13 Lynn Garren
* I attempt to help with the spack development, but this takes a back seat to the other efforts.
179 19 Lynn Garren
180 54 Joe Boyd
h2. heppdt (mu2e will take this over, Kutschke)
181 19 Lynn Garren
182 19 Lynn Garren
* This is a legacy product that was spun off as a C++ replacement for part of the original stdhep.
183 19 Lynn Garren
* It is still in use by mu2e.
184 20 Lynn Garren
185 23 Lynn Garren
h2. Mailing lists
186 23 Lynn Garren
187 23 Lynn Garren
* owner/manager of several mailing lists
188 23 Lynn Garren
** many are unused and can be retired
189 23 Lynn Garren
190 32 Joe Boyd
h2. CLHEP maintenance and support (someone at CERN)
191 20 Lynn Garren
192 20 Lynn Garren
* I have been the main point person for CLHEP bug fixes.
193 20 Lynn Garren
* Support will be passed to CERN.
194 24 Lynn Garren
195 25 Lynn Garren
h2. system management
196 24 Lynn Garren
197 26 Lynn Garren
* Still provide backup support for oink.  Rare that I do anything.
198 25 Lynn Garren
* detsim.fnal.gov
199 25 Lynn Garren
** Now supported by CCD