Flag merged clusters for relaxed CPE errors

Add a function "refineCluster" in SiStripClusterizer to mark SiStrip clusters as merged. Use this information StripCPEfromTrackAngle to fall back to the larger "legacy" CPE errors for these clusters. The flag lives on the high bit of the firstStrip_ private data member of the SiStripCluster. Configurable thresholds in the sensor occupancy and strip width are used to discriminate between un- and merged candidates. The cluster refiner is turned off as configured for this PR. (Note that it's also overridden by useLegacyError = cms.bool(True) in StripCPEfromTrackingAngle_cfi.)

I'm closing PR #6348, which was based on 7_2_0_pre6, in favor of this one, based on 7_3_0_pre2, though I haven't tested execution in this release.
Hi Andrea,

I'm running on Monte Carlo,
/store/relval/CMSSW_7_3_0_pre1/RelValTTbar_13/GEN-SIM/PRE_LS172_V15-v1/

Do you know if the effects of concern are modeled in these datasets? 
What does IOV mean?  I guess it must be a run interval or lumisection 
block to which a set of these conditions pertains?  So if running on 
data I'd look at the first of the following files if my run numbers were 
between those in the file names?
QualityInfoFromCabling_Run192835.txt QualityInfoFromCabling_Run195790.txt

Just to be sure I understand your concern,
nchannideal = reader->getNumberOfApvsAndStripLength(detId).first*128
will use the number of APVs that are nominally in the system, whereas
nchannideal = SiStripDetCabling_->nApvPairs(detId) * 2 * 128
may be using the number of live APVs successfully read out (in the most 
recent calibration run), which may be fewer than the nominal.  Do I have 
it right?

Bill

On 11/15/14 11:38 AM, venturia wrote:
> In RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc:
>
>> @@ -24,8 +31,18 @@ produce(edm::Event& event, const edm::EventSetup& es)  {
>>
>>    algorithm->initialize(es);
>>
>> +  edm::ESHandle<SiStripQuality> quality = 0;
>> +  SiStripDetInfoFileReader* reader = 0;
>> +  if (doRefineCluster_) {
>> +    es.get<SiStripQualityRcd>().get("", quality);
>
> Hi Bill, I am not 100% sure it can work in that way. Actually I am not
> 100% sure I am right saying that it does not work. As usual the problem
> is for those modules which miss the middle (or the first) APV pair. In
> that case the number of APVs is less than what it should be, and that is
> fine, but it does not mean that the strip number has to stop at
> 128*nAPVs . My suggestion is to look for a few modules with these
> features and check the algorithm (comparing the output with what you
> would get with your original algorithm which is fine but illegal). I
> don't know exactly which data you are using to test your code but can
> look at the summary reports of the cabling content for each IOV where
> the list of all the (partly) bad modules is printed. You can find them
> here for the cabling tag which is used since "ever":
> https://test-stripdbmonitor.web.cern.ch/test-stripdbmonitor/CondDBMonitoring/cms_orcoff_prod/CMS_COND_31X_STRIP/DBTagCollection/SiStripFedCabling/SiStripFedCabling_GR10_v1_hlt/CablingLog/
> Look at the files named QualityInfoFromCabling_Run…txt choosing the IOV
> you are interested in and look at the detailed list of modules at the
> end. By selecting those with "Fibers" patterns like 100 or 010 or 110
> you will select modules with the first, the second or the first and the
> second fibers not working. For example 369137741, 402674837, 402675376,
> 402676914, 402664582, 436244845, 436245994 … Incidentally, if/when we
> find a solution it could be useful to implement a method in
> SiStripQuality which returns this piece of information and use it
> everywhere, presently, we are using SiStripFileReader to achieve that. I
> am also wondering if we have to modify SiStripQuality to return a bad
> boolean when asked for a strip out of range. If instead we do not find a
> sensible solution we have to think about a way to move the information
> in SiStripFileReader into an ES object in the DB. Andrea , On Nov 14,
> 2014, at 17:27 , wmtford
> <notifications@github.com<mailto:notifications@github.com>> wrote: In
> RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc:
> @@ -24,8 +31,18 @@ produce(edm::Event& event, const edm::EventSetup& es)
> { algorithm->initialize(es); + edm::ESHandle<SiStripQuality> quality =
> 0; + SiStripDetInfoFileReader* reader = 0; + if (doRefineCluster_) { +
> es.get<SiStripQualityRcd>().get("", quality);
> Hi Andrea, It appears to me that to getting the total number of strips
> in a sensor could be accomplished along the lines sketched here: In
> SiStripClusterizer.h #include
> "CalibFormats/SiStripObjects/interface/SiStripDetCabling.h" #include
> "CalibTracker/Records/interface/SiStripDetCablingRcd.h" void
> beginRun(const edm::Run& run, const edm::EventSetup& es ) override;
> Declare a map(detId, Nstrips) NstripMap_; In the .cc file void
> SiStripClusterizer::beginRun(const edm::Run& run, const edm::EventSetup&
> es ) { edm::ESHandle<SiStripDetCabling> SiStripDetCabling;
> es.get<SiStripDetCablingRcd>().get( SiStripDetCabling); Loop over strip
> detIds { int Nstrips = SiStripDetCabling.nAPvPairs(detId) * 2 * 128;
> fill NstripMap_ } } (I suppose this could be under ESWatcher if it's
> worth while.) Then in the existing refineCluster function we just have
> int nchannideal = NstripMap(detId); Do you see any gotchas with this?
> (I'm assuming that EDProducer has a BeginRun().) Bill …<x-msg://157/#>
> On 11/12/14 6:26 AM, venturia wrote: In
> RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc: > @@
> -24,8 +31,18 @@ produce(edm::Event& event, const edm::EventSetup& es) {
>  > > algorithm->initialize(es); > > + edm::ESHandle<SiStripQuality>
> quality = 0; > + SiStripDetInfoFileReader* reader = 0; > + if
> (doRefineCluster_) { > + es.get<SiStripQualityRcd>().get("", quality); I
> think that combining _properly_ the information from the cabling (ES
> object) and from SiStripQuality (ES object), it should be possible to
> achieve what is now done with SiStripDetInfoFileReader and
> SiStripQuality. But I acknowledge that it may require some quiet time to
> be sure that all the cases are handled correctly. Andrea On Nov 12,
> 2014, at 14:19 , Chris Jones
> <notifications@github.com<mailto:notifications@github.com><mailto:notifications@github.com>>
> wrote: In
> RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc: @@
> -24,8 +31,18 @@ produce(edm::Event& event, const edm::EventSetup& es) {
> algorithm->initialize(es); + edm::ESHandle<SiStripQuality> quality = 0;
> + SiStripDetInfoFileReader* reader = 0; + if (doRefineCluster_) { +
> es.get<SiStripQualityRcd>().get("", quality); @slava77
> <https://github.com/slava77><https://github.com/slava77>
> <https://github.com/slava77><https://github.com/slava77<https://github.com/slava77%3E%3Chttps://github.com/slava77>>
> as I stated in the previous pull request, I believe this to be an
> illegal use of a Service since it can modify the physics results. —
> Reply to this email directly or view it on
> GitHub<https://github.com/cms-sw/cmssw/pull/6349/files#r20217700>. —
> Reply to this email directly or view it on GitHub
> <https://github.com/cms-sw/cmssw/pull/6349/files#r20217984>. — Reply to
> this email directly or view it on
> GitHub<https://github.com/cms-sw/cmssw/pull/6349/files#r20368828>.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cms-sw/cmssw/pull/6349/files#r20404056>.
>