Eric Church, 11/11/2014 02:12 PM
h1. Instructions for setting up to swizzle.
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.
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-xyz.fnal.gov@ as follows. Do not set up as if you were going to do DAQ readout or run control or develop uboonedaq_datatypes.
Everything on this page should work under the interchange qe6:prof <---> qe6:debug.
setup uboonedaq_datatypes v5_00_01 -qe6:prof
setup uboonecode v03_04_00 -qe6:prof
setup mrb; setup git; setup gitflow
Go run your @lar -c job.fcl@ script.
You may stop here if you care nothing about maintaining/installing or how the sausage is made.
h1. There is one important technical issue here for running LArSoft on the DAQ.
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.
h1. Next, we need LArSoft installed on the LArTF cluster.
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 v03_04_00 and a few older versions of installed LArSoft. e.g., LArSoft v02_05_01 is there -- the version that MicroBooNE's MCC5 used.
Installing LArSoft is conveniently handled by going to the FNAL scisoft server and downloading the pullProducts*.txt file to some local area on your machine at LArTF. Then, as root, run the script to install the binaries to /uboone/larsoft. (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. @chmod -R products.products /uboone/larsoft.@
h1. Developing in LArSoft with the ubdaq-prod- installation.
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.
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 prof.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:* @mrb g uboonecode; git checkout feature/ubdaq@. At some point 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.
(The above setup @uboonecode v03_04_00 -qe6:prof@ gets you the installed build that originates from feature/ubdaq, as described here, so if you don't need to add anything to this branch there's no reason to have done the git pull and git checkout feature/ubdaq.)