[Rivet] Various things for Rivet

[cholm]

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.

The changes I did in this fork

- Only use available FastJet plugins.  That is, if an analysis is run 
that uses are  plugin that isn't available on the target system it will 
cause an exception to be thrown.  I know Andy dislike this way of doing 
things.  However, some systems may not have all FastJet plugins 
available (and one cannot force that from third-party) so the 
alternative is to _not_ build and install Rivet - a shame.

- More elaborate Doxygen documentation and build and install of the same 
by default.  For example, I enable source browsing, inheritance 
diagrams, etc.  See for example

   http://cern.ch/cholm/myrivet

- Added more known particle names.

- Allow finalization of analyses from externally read analysis objects.  
This is a change to AnalysisHandler and Analysis.  Analysis get the 
protected member function updateAnalysisObject which will set the 
internal (shared) pointer in _analysisobjects.  The list of contained 
analysis objects is search and if the path matches the path of the 
passed object then the pointer is replaced.  AnalysisHandler get the 
member function finalize(const std::vector<AnalysisObject*>&) which will 
loop over the passed objects and call updateAnalysisObject for each 
known analysis. If it finds the "special" objects "/_EVTCOUNT" and 
"/_XSEC" then internal data members are set according the found values.  
After having updated all analysis objects in all analyses, we call the 
standard finalize to have the analyses do the finalization.

The point of this change is to postpone finalisation of analyses to some 
later point.  For example, one may run many Rivet jobs, store the 
un-finalised objects, merge them, and then run the final step on the 
merged output.  The next-to-next change is really why this came about.

- Added the programs rivet-runner and rivet-merger (and work-horse 
classes Merger and Runner).  The first application is a generalisation 
of the standard rivet application, but allows us to run through the 
input events with out finalisation.  It also allows to read in merged 
objects and run the finalisation step only.  The rivet-merger 
application is more or less like yodamerger except that it allows 
reading from standard input and other such things.  The motivation for 
these applications really come in the next change.

- Parallelisation of Rivet Runs.  This isn't really a code change in an 
off it self.  Instead it relies on the two previous changes to allow us 
to run Rivet jobs in parallel, merge outputs, and then finalise the 
analyses.  The steps and reasoning are described in the 
README-parallel.md file in the above GitLab repository.

The only caveat of the parallisation is that analysis developers need to 
a tiny bit of work for their analyses to be ready for this.  In the 
final step, when finalising on the merged analysis objects, we do the 
following sequence:

   Add analyses - same as in the individual runs
   Initialize analyses - so we have the same set-up as in the individual 
runs
   Read in merged analysis objects
   Propagate merged analysis objects to each Analysis::_analysisobjects 
container
   Finalize

However, since the analyses most likely have internal members pointing 
to the analysis objects, these need to be update before we can finalise. 
  The simplest solution is for each analysis - in their finalisation 
method - to retrieve needed analysis objects using one of the 
getAnalysisObject member functions.  Clearly, if an analysis has an 
empty finalize member function, nothing needs to be done.

I hope some of these changes are to your liking and that you will 
include them up-stream.

Yours,


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