The goal is to convert larsoft data products into larlite.

This is done using the LiteMaker module found in the uboonecode repository.

1. setup a uboonecode environment
2. have larlite built and setup

By default LiteMaker is not built (because LArLite is not part of the default LArSoft environment). So we need to tell the build environment to build it. This involves modifying the CMakeList.txt (which configures what is to built in a given folder).

In your uboonecode repository,

1. go to uboonecode/uboone/

2. open CMakeLists.txt

3. Uncomment this line:

   add_subdirectory(LiteMaker)
   

   What does this do? It tells cmake to include the LiteMaker folder as part of the build.

4. We've changed the build setup. We have to rebuild using mrb (and we'll also tell it to install the build)

   mrb i -j10
   

   Note: make sure you setup larlite above. The build configuration in LiteMaker assumes the presence of LARLITE environment variables to find larlite headers and libraries.

OK. We now have a build of uboonecode with LiteScanner ready to go. How do we convert? LiteMaker is a LarSoft EDAnalyzer, so do the usual, we add it to the list of modules for the lar exectuable to run using a fcl file.

Now, there is a lot of data products stuffed into a LArSof art file for better or for worse. Often, you only care about a certain data product. So LiteMaker needs to be told what it should convert so that your files aren't filled with unwanted stuff. Also, a design choice is to be able to strip one set of data products into file A, another into file B, another into file C... This allows one to grab a set of products into A. But then realize you also want B and have larlite combine those files together. Or one makes all the products, but transfers only those useful at the moment. This comes at the cost of the user have to keep track of what files have what and what files go together.

Anyway, you'll find in the uboone/LiteMaker directory a 'job' directory. It contains the fcl parameter sets that define an analyzer to extract a set of products. This directory has the following in it:

[ tmw@uboonegpvm03 job ]$ ls
CMakeLists.txt  litedata  litemaker_base.fcl  litembass  litemc  scanner_util.fcl

'litedata' and 'litemc' has the fcl files for DATA and MC products, respectively. Let's look at the data ones.

[ tmw@uboonegpvm03 job ]$ cd litedata/
[ tmw@uboonegpvm03 litedata ]$ ls
CMakeLists.txt                    litedatamin_opdigit.fcl  litedatamin_reco2d_cc.fcl            litedatamin_reco3d_pandoraCosmic.fcl  litemindata_opdigit.fcl
larlite_maker_datamin.fcl         litedatamin_opreco.fcl   litedatamin_reco3d_kalmanhit.fcl    litedatamin_reco3d_pandoraNu.fcl
larlite_maker_datamin_opreco.fcl  litedatamin_reco2d.fcl   litedatamin_reco3d_kalmanhitcc.fcl  litedatamin_wire.fcl

The fcl file that can drive (i.e. the one you run with lar -c) with "complete" set of data products is in 'larlite_maker_datamin.fcl'. The other ones setup an instance of a LiteMaker analyzer for a given data product. These analyzers are used by larlite_maker_datamin.fcl.

Let's copy larlite_maker_datamin.fcl to some work directory so we can change it.

As of version v05_08_00_02 this file does not work out of the box.

We have to comment out the following lines:

...
#physics.analyzers.cluster3d.stream:   "cluster3d"
...
#physics.analyzers.cctrack.stream:     "cctrack"
...
#physics.analyzers.cluster3d.out_filename:     "larlite_cluster3d.root"
...
#physics.analyzers.cctrack.out_filename:       "larlite_cctrack.root" 
...

We also have to fix the following lines form

services.user.DetectorClocksService.TrigModuleName: "daq"
services.user.DetectorClocksService.InheritClockConfig: false

to:

services.DetectorClocksService.TrigModuleName: "daq"
services.DetectorClocksService.InheritClockConfig: false

Then we can run this by

lar -c larlite_maker_datamin.fcl -s [input larsoft file]

Note that by default, the deconvolved wire products are not converted. You'll get a whole set of larlite files.

See this.

So what is the point of LiteMaker, well, we are transferring data from one framework to another. This means translating the LArSoft data type into the LArLite data type. This isn't one-to-one. Mostly, in the LArLite version, all the LArSoft crap inherited from art is being stripped off. This computer can't read our minds as to how to do this, so we need a conversion tool. This is LiteMaker.

Where do we hide the dirty work of the conversion? This is important. If a new LArSoft data product is created (by you) but you want it in larlite, then you'll have to know how to tell LiteMaker how to convert.

The bodies are buried here:

uboonecode/uboone/LiteMaker/ScannerAlgo.template.h

OK, this is the core of conversion. But how about the framework? Let's start with the module, Litemaker_module.cc.

We have a template function

/// Templated data scanner function                                                                                                                                  
template<class T> void ScanData(const art::Event& evt, const size_t name_index);

where T is the different LArLite data products. These get called in the Liatemaker::analyze function.

But what is it doing? It is calling a member class in LiteMaker, ScanAlgo,

::larlite::ScannerAlgo fAlg;

which itself has a bunch of template functions:

/// Core method: convert LArSoft data product (dh) to LArLite (lite_dh)                                                                                            
template <class T>
void ScanData(art::Handle<std::vector<T> > const &dh, ::larlite::event_base* lite_dh);

Why? Maybe we are separating the conversion algorithms from the LiteMaker analyzer? I don't know. Anyway, the implementation of these algorithms are in ScannerAlgo.template.h

So when LiteMaker wants to convert, for example, the MC truth information:

case ::larlite::data::kMCTruth:
    ScanData<simb::MCTruth>(e,j); break;

we call the algo in LiteMaker::ScanData via

fAlg.ScanData(dh,lite_data);

which is using the implentation in ScannerAlgo.template.h

You might see errors like this:

 [100%] Linking CXX shared library ../../lib/libuboonecode_uboone_LiteMaker.so
 CMakeFiles/uboonecode_uboone_LiteMaker.dir/ScannerAlgo.cxx.o: In function `void  
     larlite::ScannerAlgo::ScanData<MuCS::MuCSRecoData>(art::Handle<std::vector<MuCS::MuCSRecoData, 
     std::allocator<MuCS::MuCSRecoData> > > const&, larlite::event_base*)':
 /uboone/app/users/tmw/dev/v05_08_00_02_supera/srcs/uboonecode/uboone/LiteMaker/ScannerAlgo.template.h:603:
 undefined reference to `larlite::mucsreco::mucsreco(float, float, float, float, float, float, float, float, float, int, int)'

When cmake is at the 'linking' stage it is telling an executable or library of functions where to find the function and variable names the library uses. When we get an undefined reference, it can't find those functions, nor the libraries for them. In this case, the LiteMaker library can't find the larlite version of the data product (here MuCS data). This probably means your larlite is out-dated. Go to your larlite folder, do git pull, then rebuild.