Project

General

Profile

HORRIBLE BAD Instructions for setting up to swizzle.

DO NOT USE THESE INSTRUCTIONS.

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.

---------------start of edits from 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).


scp ubdaq-prod-near1:/datalocal/kirby/swizzler_v04_05_00.tgz ./
tar xzf swizzler_v04_05_00.tgz
cd swizzler_v04_05_00
source /uboone_offline/setup
export PRODUCTS=`pwd`/localProducts_larsoft_v04_05_00_e7_prof:${PRODUCTS}
setup uboonedaq_datatypes v5_00_01 -q e7:prof
setup uboonecode v04_05_00 -q e7:prof
lar -c ./localProducts_larsoft_v04_05_00_e7_prof/rawtorootconvert.fcl

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".

-------------- end of edits from Kirby --------------------------
source /uboone_offline/setup
export PRODUCTS=$PRODUCTS:/uboonenew
setup uboonedaq_datatypes v6_08_00 -qe7:debug
setup uboonecode v04_08_00 -qe7:debug
setup mrb; setup git; setup gitflow
export MRB_PROJECT=larsoft

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.

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.

LArSoft installed on the LArTF cluster.

--------------start of edits from 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.

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.

-------------end of edits from kirby --------------------

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.

Developing in LArSoft with the ubdaq-prod- installation.

--------------start of edits from 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

There are modifications that need to be made within these packages:

change the lardata/ups/product_deps to have these versions

@
parent lardata v04_04_00
defaultqual e7

fcldir product_dir job

product version
larcore v04_04_00
nutools v1_09_01
gcc v4_9_2

cetbuildtools v4_04_02
end_product_list

qualifier larcore nutools gcc notes
e7:debug e7:debug e7:debug nq
e7:opt e7:opt e7:opt nq
e7:prof e7:prof e7:prof nq
end_qualifier_list
@

change the uboonecode/ups/product_deps to have these versions

@
parent uboonecode v04_05_00
defaultqual e7

product version
larsoft v04_05_00
ubutil v01_16_00
postgresql v9_1_15
gcc v4_9_2
uboonedaq_datatypes v5_00_01 #and the matching qualifiers below

cetbuildtools v4_04_02 - only_for_build
@

For some reason I can't figure out, the uboonecode/CMakeList.txt and lardata/CMakeList.txt need to be modify with -std=c++1y
This is done by:


cet_set_compiler_flags( DIAGS CAUTIOUS
WERROR
NO_UNDEFINED
EXTRA_FLAGS -pedantic -Wno-unused-local-typedefs -std=c++1y
)

Then building with:


cd ../build_XXX
mrbsetenv
mrb i -j4

---------end kirby edits ---------------

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 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.

Thus,
source /uboone_offline/setup
export PRODUCTS=$PRODUCTS:/uboonenew
setup uboonedaq_datatypes v6_08_00 -qe7:debug
setup larsoft v04_08_00 -qe7:debug
setup mrb; setup git; setup gitflow
export MRB_PROJECT=larsoft
cd /home/user/larsoft/debug.slf6.vxx_yy_zz
source localProductsxyz/setup
mrbsetenv
mrb i -j32
.