additional VCal thr grading criteria

[jstupak]

Can we please add a field to the DB to store the number of VCal threshold defect pixels per ROC? Then we should add this number to the number of bad pixels and bad bumps for the purposes of grading. NB: let's not actually make any changes until after Marco's talk.

We will then have to add this info to the xml files we upload, and upload new zip files for every module tested so far. Is there an easier way to do this than consolidated batch submit O(50) times?

[jstupak]

While you're at it, I think we want to add a few more fields as well:

• worst double column x-ray uniformity
• worst double column low rate x-ray efficiency
• worst double column high rate x-ray efficiency
• number of pXar errors

[gneeser]

John, Just want to double-check: for the worst double-column x-ray uniformity and low/high rate efficiency, is that something that you would want on a per-ROC basis with the grade being determined by the worst one, or would this just be one number on a per-module basis?

As for there being an easier way to upload the data, I'm not sure that there is. The data is entered into the mySQL after the xml is parsed by the php, so off the top of my head I don't see an easier way. I think it would be possible to put all of the information into a single zip and do the consolidated batch submit once - but I'm not sure that would end up saving time. I'll take a look and let you know if I find an easier way.

Once I do add the ability for these to be input, I will also need specific criteria for how each of these affects the grade. One step at a time though!

-Greg

[jstupak]

Hello Greg,

It doesn't really matter if they are per ROC quantities or per module. Is either option easier for you?

With 98% confidence, I can say we are just gonna reject modules if any ROC has a DC with low efficiency or uniformity. So if the worst DC for the entire module is stored or the worst DC per ROC is stored, we can still achieve this.

But If its all the same to you, I have a slight preference for keeping this a per ROC field.

[merkelp]

Hi, there is a small chance that we will be forced to use modules with one bad dcol. In that case, we do need this information per ROC.

Petra

On 2/2/16 8:59 AM, jstupak wrote:

Hello Greg,

It doesn't really matter if they are per ROC quantities or per module. Is either option easier for you?

With 98% confidence, I can say we are just gonna reject modules if any ROC has a DC with low efficiency or uniformity. So if the worst DC for the entire module is stored or the worst DC per ROC is stored, we can still achieve this.

But If its all the same to you, I have a slight preference for keeping this a per ROC field.

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

[jstupak]

And based on yesterday's meeting, rather than calling it "worst" lets call it "lowest." And then we would like to add one more field not previously discussed, the highest DC uniformity.

So to recap, the fields we are asking for are:

• Vcal threshold defects
• lowest double column x-ray uniformity
• highest double column x-ray uniformity
• lowest double column low rate x-ray efficiency
• lowest double column high rate x-ray efficiency
• number of pXar errors

Based on the comment above from Petra, only the last item should be a per-module quantitiy.

[gneeser]

I'll get started on that then. When I have the new fields implemented, I'll update the example xml on the Consolidated Batch Submit page for clarity.

[gneeser]

All, I added the capacity to upload the new fields, as well as the code to display them. I made a mock-up xml and tested it on one of the database test modules. You can see the results here: http://www.physics.purdue.edu/cmsfpix/Submission_t/summary/summaryFull.php?name=P-A-test-test Most of the fields are filled with random numbers, so don't pay too much attention to that.

The grading scheme does not yet use the new criteria. Naturally, I'll need a list of how what affects the grade before i can implement it.

If anybody has any questions, comments, or expressions of outrage, let me know.

-Greg

[drberry85]

Greg,

I think two new numbers could be handy. The number of double columns below 98% efficiency and the number of double columns below 95% efficiency. These value can be per module and not per ROC.

Doug

On Thu, Feb 4, 2016 at 3:10 PM, gneeser notifications@github.com wrote:

All, I added the capacity to upload the new fields, as well as the code to display them. I made a mock-up xml and tested it on one of the database test modules. You can see the results here:

http://www.physics.purdue.edu/cmsfpix/Submission_t/summary/summaryFull.php?name=P-A-test-test Most of the fields are filled with random numbers, so don't pay too much attention to that.

The grading scheme does not yet use the new criteria. Naturally, I'll need a list of how what affects the grade before i can implement it.

If anybody has any questions, comments, or expressions of outrage, let me know.

-Greg

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

[jstupak]

Hello Greg,

I think wrt grading we should just treat Vcal threshold defect pixels as defective pixels like those that fail the pixel alive or BB tests. So just add this number to the number of dead pixels and bad bumps and use the 1%/4% thresholds to determine the grade.

The number of tables on the full test summary page is ballooning. Can you please remind me if we are using the Unnadressable and Unmaskable pixels in the grading criteria? Maybe we could simply display the total number of these pixels per module, since we don't see many? And we are not going to use x-rays to assess BB quality, so you can remove that table from the page.

@drberry85 I think you need to be more specific. Are you referring to the lower rate, the higher rate, or both?

[drberry85]

John,

I think just looking at the highest rate will due.

Doug

On Fri, Feb 5, 2016 at 9:44 AM, jstupak notifications@github.com wrote:

Hello Greg,

I think wrt grading we should just treat Vcal threshold defect pixels as defective pixels like those that fail the pixel alive or BB tests. So just add this number to the number of dead pixels and bad bumps and use the 1%/4% thresholds to determine the grade.

The number of tables on the full test summary page is ballooning. Can you please remind me if we are using the Unnadressable and Unmaskable pixels in the grading criteria? Maybe we could simply display the total number of these pixels per module, since we don't see many? And we are not going to use x-rays to assess BB quality, so you can remove that table from the page.

@drberry85 https://github.com/drberry85 I think you need to be more specific. Are you referring to the lower rate, the higher rate, or both?

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

[gneeser]

I made some changes (still in the test version of the database):

• VCal threshold defect pixels are included in the grading
• The BB X-ray table is hidden
• Unmaskable and unaddressable pixels are displayed in the same table. I think there are maybe four modules in the database where either of those are nonzero, but they are used in the grading if they exist.
• The number of double columns below 98 and 95 percent efficiency can be set via xml upload and are displayed
• The example xml on the consolidated batch submit page has been updated with the new fields.

If you see anything I missed, let me know. If you don't, I can push all of the changes to the official version of the database.

-Greg

[jstupak]

I am 99% ready to start uploading the number of Vcal threshold defects per ROC. We should talk about this at the meeting today

[gneeser]

The updates are on the production (main) version of the website. If you catch any bugs let me know.

[jstupak]

The Vcal thr defects work. I do notice a small issue though:

http://www.physics.purdue.edu/cmsfpix/Submission_p/summary/summaryFull.php?name=M-G-2-10

ROC 11 says the biggest problem is dead pixels. Maybe this is because originally this was true and then I uploaded new data, but Vcal thr defects are the biggest problem now.

[jstupak]

Can we also please have the ability to search for modules based on the number of threshold defect pixels, like we do for dead pixels and bad bumps? We probably also want similar functionality for the new x-ray fields too. And maybe some way to separately query the 17C and -20C IV grades.

Is this asking a lot? Thanks.

[gneeser]

That's definitely doable. I'll add it to the docket.

[jstupak]

Thanks a lot!

[gneeser]

Found and fixed the issue with reporting the biggest contribution to the grade. Good catch. Let me know if you find anything else.

[drberry85]

I think this issue can be closed.