puhep / pudb

Purdue CMS FPix Database
0 stars 0 forks source link

Do all filters work? #83

Closed merkelp closed 9 years ago

merkelp commented 9 years ago

Hello, I have tried some of the filters here: http://www.physics.purdue.edu/cmsfpix/Submission_p/summary/test_list.php and don't think all of them work, or maybe I don't understand what they are supposed to do?

For example, if I set

bad ROCs >= 1

I don't get any modules. But maybe these are not the bad/dead ROCs we spot on some of the modules, but rather ROCs that have a grade other than A?

If I set

Bad Bumps per ROC (Electrical) >= 40

I don't get any modules either, and this can not be correct.

That's all I have tried for now. Could someone check that the logic behind these filters is correct?

Thanks, Petra

NickHinton commented 9 years ago

I just checked the database, and no modules have bad ROCs associated with them. The 'badrocs' field in the database is either 0 or NULL for all modules. Perhaps the implementation of the bad ROCs happened after testing modules with bad ROCs? That would require re-uploading the data for modules in question.

There should be modules showing up for the bad bumps criteria though. Modules P-A-2-22, M_LL_922, and P-A-3-42 should all show up with that search criteria. We'll have to look into that one.

khan62 commented 9 years ago

We have come to a conclusion about what is going on. First there was a syntax issue which has since been fixed, but now we realize that the queries that check per-ROC values will return a module if any ROC satisfies the criteria. Do we want an option to return only modules where every ROC satisfies the criteria?

merkelp commented 9 years ago

Hi Kamal, no, this is definitely how we want it, an OR of all the ROCs, not an AND. There will hopefully never be a module, where all ROCs have a problem.

Thanks, Petra

On 10/2/15 2:08 PM, Kamal Khan wrote:

We have come to a conclusion about what is going on. First there was a syntax issue which has since been fixed, but now we realize that the queries that check per-ROC values will return a module if any ROC satisfies the criteria. Do we want an option to return only modules where every ROC satisfies the criteria?

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

gneeser commented 9 years ago

Petra, I just wanted to point out a potential issues with how it is currently set up. If you use the "less than" or "less than or equal to" or "equal to" options for bad bumps per ROC, it will return a list of modules for which any ROC has that value. So searching for "# Dead Pixels per ROC: < 40" will return any modules that have at least one ROC with less than 40 dead pixels, rather than all ROCs having less than 40 dead pixels.

-Greg

merkelp commented 9 years ago

Hi Greg, yes, I believe that is the intended use. In the end you want to be able to find all modules with a particular issue, not the ROCs. But in this case, you will also find all the ROCs, you just need to count them by hand basically.

Thanks, Petra

On 10/8/15 2:53 PM, gneeser wrote:

Petra, I just wanted to point out a potential issues with how it is currently set up. If you use the "less than" or "less than or equal to" or "equal to" options for bad bumps per ROC, it will return a list of modules for which any ROC has that value. So searching for "# Dead Pixels per ROC: < 40" will return any modules that have at least one ROC with less than 40 dead pixels, rather than all ROCs having less than 40 dead pixels.

-Greg

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