change to un-addressable and un-maskable pixels requested

[jstupak]

During today's meeting, we decided we need a change to how the DB handles un-addressable and un-maskable pixels. Currently, these numbers are stored on a per-module basis. We need these stored on a per-ROC basis, a la bad bumps and dead pixels.

Then the grading criteria should also be modified. We need to assign a grade based on the worst ROC, where the worst ROC is defined as the ROC with the largest number of bad bumps + dead pixels + un-addressable pixels + un-maskable pixels.

[khan62]

I have added tables for unmaskable and unaddressable pixels per ROC, as well as added xml tags for them (same as before, just now inside the tag). For the grade, I need some clarification on what constitutes A, B, C, etc

[jstupak]

For each ROC, we should sum the number of bad electrical bumps, dead pixels, unmaskable pixels, and bad address pixels. If this sum is greater than 4% of the total number of pixels (in any ROC), then the module is a C. Else, if this sum is greater than 1%, the module is a B. Else, the module is an A.

@merkelp please confirm this.

[merkelp]

Hi Kamal,

as John said, you need to add up, for each ROC separately, the four different counts of bad pixels (bad bumps, dead pixels, address problems and mask problems), dive by 4160 (the total number of pixels in a ROC), which then translates into the ROC grade (>4% -> grade C, >1% -> grade B, <1% -> grade A). The modules grade = worst ROC grade or IV grade, whichever is worse.

Cheers, Petra

On 9/15/15 8:16 AM, jstupak wrote:

For each ROC, we should sum the number of bad electrical bumps, dead pixels, unmaskable pixels, and bad address pixels. If this sum is greater than 4% of the total number of pixels (in any ROC), then the module is a C. Else, if this sum is greater than 1%, the module is a B. Else, the module is an A.

@merkelp https://github.com/merkelp please confirm this.

— Reply to this email directly or view it on GitHub https://github.com/puhep/pudb/issues/68#issuecomment-140386589.

[merkelp]

oh, and I forgot to say that we need to find a way to also display all the grades that are different from A. So for a given module, we need to know if the IV was bad, and also if any of the ROCs were anything but an A, and if so, why. This could be a comment of the grade field?

Petra

On 9/15/15 8:16 AM, jstupak wrote:

For each ROC, we should sum the number of bad electrical bumps, dead pixels, unmaskable pixels, and bad address pixels. If this sum is greater than 4% of the total number of pixels (in any ROC), then the module is a C. Else, if this sum is greater than 1%, the module is a B. Else, the module is an A.

@merkelp https://github.com/merkelp please confirm this.

— Reply to this email directly or view it on GitHub https://github.com/puhep/pudb/issues/68#issuecomment-140386589.

[gneeser]

Solution has been partially implemented: the grade for each ROC is calculated using the four different counts and the grade of the module is worst of the grade of the worst ROC or the IV. It should be noted that this means a number of modules that had grades now have a grade of incomplete because they were missing data for address and masking problems.

[merkelp]

Thanks! Someone should probably go through those incomplete modules and see if the missing data can be uploaded.

Petra

On 9/28/15 10:13 AM, gneeser wrote:

Solution has been partially implemented: the grade for each ROC is calculated using the four different counts and the grade of the module is worst of the grade of the worst ROC or the IV. It should be noted that this means a number of modules that had grades now have a grade of incomplete because they were missing data for address and masking problems.

— Reply to this email directly or view it on GitHub https://github.com/puhep/pudb/issues/68#issuecomment-143771818.

[jstupak]

Can we just assume for the pre-production modules that there were no address decoding or un-maskable issues? Its almost true

[merkelp]

Hi John, sure, if that's the easiest way to proceed, I am fine with that.

Petra

On 9/28/15 10:27 AM, jstupak wrote:

Can we just assume for the pre-production modules that there were no address decoding or un-maskable issues? Its almost true

— Reply to this email directly or view it on GitHub https://github.com/puhep/pudb/issues/68#issuecomment-143777529.

[jstupak]

I will upload real results for a module or two, just to test that everything works. But beyond that I think this would be best.

@gneeser Can we tell the DB to treat missing address defect and mask issues as zeroes?

[gneeser]

If the missing address defect and mask address issues are null, the database will now treat them as zeroes. It will still display incomplete if bad bumps or dead pixels are null.

[gneeser]

Fulltest summary page now includes a list of any grade that was not "A", including ROC grades and IV grades. I currently have this displayed beneath the module grade. As always, let me know if you find any inconsistencies or have formatting preferences; I'm happy to oblige.

[jstupak]

looks good to me, modulo a small typo:

http://www.physics.purdue.edu/cmsfpix/Submission_p/summary/summaryFull.php?name=P-A-3-14 Grades that were not A: ROC3: B ROC4: B IV: CTimeable: Yes

[gneeser]

Good catch, changed it.

[gneeser]

The ROC grade comment now includes the biggest numerical contributor (of the four bad pixel types) to its grade, e.g. ROC7: Grade B; biggest contribution: 59 bad bumps ROC8: Grade C; biggest contribution: 117 dead pixels