Suggestion for new layout on http://www.physics.purdue.edu/cmsfpix/Submission_p/summary/test_list.php

[merkelp]

I have a great new proposal, and hope it's pretty easily implemented.

On http://www.physics.purdue.edu/cmsfpix/Submission_p/summary/test_list.php, instead of sorting the modules at the bottom list in the eight different sensor type columns, could we sort them into columns according to their 'next testing step' ? This way we would always immediately see the different buckets of modules without having to click all sorts of buttons.

Thanks, Petra

[lantone]

i second that, great idea petra!

what to do next with a module is currently much more on our minds than is the wafer position

[gneeser]

Nick and I are in agreement too. I'll start on that project then.

[gneeser]

I updated the Tested Modules List layout. Modules are binned by Next Testing Step and sorted by HDI name in those bins.

Would you all like any aesthetic changes, like the order of the bins or the way in which the modules are sorted? For example, I could do a reverse chronological sort so that most recently modified modules are at the top.

[merkelp]

Very nice, Greg!

I like the order of the columns. I would like the first six columns to be sorted newest first. For ready and rejected eventually it would be nice to sort by quality, which would help a lot with sorting into where which module should be installed; but it would need to be more fine grained than A, B, C. This is especially relevant for the 'ready to be mounted' modules. We should develop this in the near future. As a first approximation, one could use the absolute count of bad pixels to sort by.

Thanks, Petra

On 2/17/16 10:15 AM, gneeser wrote:

I updated the Tested Modules List layout. Modules are binned by Next Testing Step and sorted by HDI name in those bins.

Would you all like any aesthetic changes, like the order of the bins or the way in which the modules are sorted? For example, I could do a reverse chronological sort so that most recently modified modules are at the top.

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

[lantone]

I concur. Also, it would be good to include text on the page explicitly stating the sorting criteria if if’s not identical for every column.

Jamie

On Feb 17, 2016, at 10:27 AM, merkelp notifications@github.com wrote:

Very nice, Greg!

I like the order of the columns. I would like the first six columns to be sorted newest first. For ready and rejected eventually it would be nice to sort by quality, which would help a lot with sorting into where which module should be installed; but it would need to be more fine grained than A, B, C. This is especially relevant for the 'ready to be mounted' modules. We should develop this in the near future. As a first approximation, one could use the absolute count of bad pixels to sort by.

Thanks, Petra

On 2/17/16 10:15 AM, gneeser wrote:

I updated the Tested Modules List layout. Modules are binned by Next Testing Step and sorted by HDI name in those bins.

Would you all like any aesthetic changes, like the order of the bins or the way in which the modules are sorted? For example, I could do a reverse chronological sort so that most recently modified modules are at the top.

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

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

[gneeser]

For the first six columns, there are a couple of ways we could sort it by newest first, oddly enough.

The first and easiest way would be to use the Last Modified. My only qualm with that is that this field is updated any time any change is made to the module - whether that be a new test result, a new comment, or a new picture. This is fine of course if you want it to be that malleable.

The second option I can think of would be to sort each bin by when they were assigned to that bin. For example, the Full Test at -20C bin would be sorted by when the modules were assigned that step.

There are of course a couple of other ways we could qualify what "newest first" means. Which do you all think you would prefer?

-Greg

[jstupak]

Hello Greg,

Your second option sounds good to me. Alternatively, you could sort by the date they were officially assembled. Either way would be fine with me. Are they both easy for you?

[gneeser]

Both should be fairly simple. I think I'll sort it by when the Next Testing Step was assigned for now, and we can change it later if we decide to.

-Greg

[gneeser]

Upon giving it a try, sorting by the next testing step proved to be the more complicated option by quite a bit. So for the moment, I've sorted by the shipped date, which is the "official" assembly date according to what we used for Marco's plot (issue #130 ). I also feel that gives us a better indication than the date of the HDI being attached, which we used on this page before.

Sorting by the number of bad pixels for the last few columns will take a little more time.

-Greg

[gneeser]

I sorted the "Ready for Mounting" column by the total number of dead pixels, bad bumps (electrical), unmaskable pix, unaddressable pix, and VCal threshold defect pix. A couple of them were still missing the VCal threshold defect pixel counts, so I had the DB treat them as zeros. That might mess up the order a bit, but I don't see how else to approach it. If you have any ideas, I'd be happy to give it a try.

Things got a little more complicated when trying to do the same for the "Rejected" bin. As you might expect in a bin of rejected modules, a lot of modules have a lot of fields as null, which makes sorting difficult.

For the time being, modules with null dead pix or bad bump (electrical) counts are put at the bottom, being the worst (I assume). Null values in the unmaskable, unaddressable, or VCal threshold fields are treated as zeroes. However, that leads to a couple of cases where modules look good on the summary page and are sorted near the top but were in fact rejected because of VCal threshold problems.

As always, let me know if you catch any errors.

-Greg