Pf2 stream

Solves several potential "race conditions" in code related to HCAL, Jet and Tau.
Introduces more const-correctness
convert to stream several producers (notably Jet, TauDiscriminators and PFRecHits)

The original logic and implementation are always preserved.
Minor modifications to ensure const-correctness in tau-discriminators where the method
"discriminate" has been made constant to ease const-correctness tracking


No regression expected, no regression observed even running with 4 threads.

Now reco (with no output) is 85% efficient with 6 threads and 70% efficient with 12 threads

Because of reading of MVA from files the number of opened file descriptors may easily grow beyond single user limit when running with many threads
This should disappear when MVA will be read from the DB.


In all these Producers memory usage (and more in general usage of common resources) can be optimized using GlobalContexts and RunCaches
Dear all,

the TCRecoTaus were useful at the beginning of the data-taking, in order to compare the PFlow performance.
I am not aware of anybody using TCRecoTaus in the last 2 years and the TCRecoTau code has not been adopted to present pile-up conditions. I vote for simply removing this code.

Best,


Christian

On Aug 9, 2014, at 11:16 AM, Pavel Jez wrote:

> In JetMETCorrections/TauJet/plugins/TCRecoTauDiscriminationAlgoComponent.cc:
> 
> >  }
> >  
> >  
> > -double TCRecoTauDiscriminationAlgoComponent::discriminate(const CaloTauRef& theCaloTauRef){
> > -	tcTauAlgorithm->recalculateEnergy(*theCaloTauRef);
> > -	return (tcTauAlgorithm->algoComponent());
> > +double TCRecoTauDiscriminationAlgoComponent::discriminate(const CaloTauRef& theCaloTauRef) const {
> > +        auto algoused = TCTauAlgorithm::TCAlgoUndetermined;
> > +	tcTauAlgorithm.recalculateEnergy(*theCaloTauRef, algoused);
> > +	return algoused; // is this correct???  (elsewehre is  ? 1.:0.;)
> 
> hm, interesting - this algorithm was abandoned before I joined CMS and I never spent much time studying its details. Perhaps @veelken can comment whether this return value was intentional. I can only add that this algorithm is never executed during RECO sequence and the code is kept only for legacy reasons. So resolution of this bug should in no way delay approval of this PR.
> 
> —
> Reply to this email directly or view it on GitHub.
>