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 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%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>.