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.
Bill,

in the MC the cabling is ideal and all the bad components are in the bad channel records. In the data part of the bad components are in the cabling as “missing pieces”. Therefore you need the real data to test your algorithm.ù
IOV means interval of validity and, in case of the cabling, is the first run number starting from which the cabling is valid. Therefore you have to choose the IOV with the largest run number smaller than the run you are analyzing.
what you wrote about nApvPairs should be correct: what it may not be correct is that when you get, let’s say, one APV pair, then the correct thing to do is to loop from 0 to 255 and check for the individual strips. It may be that you have to loop from 256 to 512 because the missing pair is the first.
I don’t have a suggestion from the top of my head now and I should look at the code of the cabling object to check if there is anything you can use to overcome this. Maybe looping what are called “connections” and check if they are valid (or if the pointer is not-null) and from that understand the pattern of the missing APVs. But I do not remember if the following simple rule apply to all the modules, both 2 and 3 APV pair modules:
connections[0] : strips 1-255
connections[1] : strips 256-511
connections[2] : strips 512-767
                                                             Andrea

Il giorno 16/nov/2014, alle ore 04:02, wmtford <notifications@github.com<mailto:notifications@github.com>> ha scritto:


In RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc<http://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, 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
…<x-msg://2/#>
On 11/15/14 11:38 AM, venturia wrote: In RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc<http://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><mailto:notifications@github.com>> wrote: In RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc<http://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<http://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><mailto:notifications@github.com>> wrote: In RecoLocalTracker/SiStripClusterizer/plugins/SiStripClusterizer.cc<http://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>> <https://github.com/slava77><https://github.com/slava77<https://github.com/slava77%3E%3Chttps://github.com/slava77<https://github.com/slava77%3E%3Chttps://github.com/slava77%3Chttps://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>.

—
Reply to this email directly or view it on GitHub<https://github.com/cms-sw/cmssw/pull/6349/files#r20406815>.