[Rivet] Various things for Rivet

[cholm]

Hi Rivet'ers,

On 2017-06-03 21:10, cholm wrote:
> Hi all,
> 
> I decided to make a fork of Rivet to try to implement some things in
> core Rivet.  I've used CERN's GitLab instance, and the project can be
> found at
> 
>   https://gitlab.cern.ch/cholm/myrivet
> 
> If you can log in at CERN you should have access.
> 
> The current Mercurial tip (e371e83848e1) of the upstream repository is
> in the branch "hg-tipp".  I do the development in the branch "devel",
> and merge stuff to "master" from both of the other branches.
> 
> I've tagged the "devel" with each step were I implemented stuff.

In this branch (devel), I've prepared _all_ analyses for parallel 
execution.  That is,

- _always_ use book... member functions for objects that need to be 
accessed in finalize.
- Replace _all_ simple counter (typically double) data members with 
book'ed YODA::Counter
- Use getAnalysisObject (or it's siblings) in finalize to retrieve data 
needed.

As I've outlined previously, the strategy for late-finalisation (however 
it is done) implemented in this fork is as follows:

- Set-up the analysis handler with all needed analyses objects.
- Read in external data objects.
- Build fake event and initialize the handler (and all it's analyses 
objects) with that event.
   - This calls Analysis::init for all used analyses, and this set's up 
the needed analysis objects.
- Loop over the list of externally read objects and ask each analyses if 
it will adopt that object
   - This works by calling Analysis::updateAnalysisObject which checks if 
the path of the passed
     object is the same as one of the objects defined in Analysis::init
- Finalize the run via the handler (calling all analyses 
Analysis::finalize member function)
   - The analyses _must_
     - have declared all objects used in finalize via one of the book... 
member functions
     - declare all counters etc, via bookCounter or the like.
     - retrieve the needed analysis objects from the internal vector of 
objects via the various
       Analysis::get... member functions

To see this, do

   git clone  https://gitlab.cern.ch/cholm/myrivet
   cd myrivet
   git checkout devel


However, when preparing all the analyses for this strategy, I came up 
with another, perhaps simpler, strategy

- Set-up the analysis handler with all needed analyses objects.
- Read in external data objects.
- Loop over the list of externally read objects and ask each analyses if 
it will adopt that object
   - This works by calling Analysis::updateAnalysisObject which checks if 
the object's path starts
     with the analyses objects histogram directory (Analysis::histoDir())
- Build fake event and initialize the handler (and all it's analyses 
objects) with that event.
   - This will call Analysis::init on all analyses.  Typically, one books 
objects here.  However,
     since we have already added all our analysis objects to the 
analyses, we simple return the
     existing objects.  In this way, the internal handles to the objects 
are restored.  The analyses
     classes _must_
     - have declared all objects used in finalize via one of the book... 
member functions
     - declare all counters etc, via bookCounter or the like
     - not zero, reset, clear _any_ analysis object at this point
     - not declare two objects to have the same name (though they can be 
in different
       sub-directories and have the same name)
- Finalize the run via the handler (calling all analyses 
Analysis::finalize member function)

This strategy entails

- Fewer changes to the analyses classes
   - No need to retrieve objects in finalize
   - Simple counters must be converted from simple types to booked 
YODA::Counter's
     (this is _not_ trivial - many analyses uses simple double's to sum 
weights, for example).
- Analyses objects _must_ have unique paths

    _histo1 = bookHisto1D("h",...);
    _scat1  = bookScatter2D("h",...); // Mistake - same path

   is not OK, but

    _histo1 = bookHisto1D("h",...);
    _scat1  = bookScatter2D("sub/h",...); // OK, different path

   is fine.

I've put this strategy in the branch "alt-devel" in the above gitlab 
repository

   git clone  https://gitlab.cern.ch/cholm/myrivet
   cd myrivet
   git checkout alt-devel

The upstream repository is tracked in the branch hg-tipp.  To see the 
differences between either of the above branches and upstream, do

   git diff hg-tipp..devel # Warning - huge diff
   git diff hg-tipp..alt-devel

Yours,

-- 
Christian Holm Christensen 
-------------------------------------------------
  Niels Bohr Institute, Blegdamsvej 17, DK-2100 Copenhagen
  http://cern.ch/cholm, +4524618591