Closed lantone closed 7 years ago
Can you check the xml file that was uploaded to the DB to confirm that it says 0 errors? That will tell us if it is FPIXUtils or PUDB who is at fault
i just reran uploadTest.py on the output, got this line in the xml:
<PXAR_ERRORS>594</PXAR_ERRORS>
Sounds like a DB issue to me then. Any ideas Greg?
I'll take a closer look this afternoon and let you know what I find
-Greg
Nothing is jumping out at me as incorrect at first glance... could I get the zip file for that module?
Also, have you noticed this for other modules as well, or is this the only one?
-Greg
I've only noticed it on that one, but haven't really looked at many others with that failure mode in mind. I just remake the zip when I tested it, I've asked the current shifter to check the test stand computers to see if the original zip is still there.
ok, greg i sent you the zip file via email
or not. let's try this: M-P-1-09.zip
Got the zip, I'll start debugging. Thanks!
In the zip that you attached, it reads that there are zero pxar errors:
Could there have been an error in the script?
Maybe this zip is for the "wrong" temperature? IIRC the zip gets overwritten for each test, so if the same module was tested again at a different temperature then we lost the original zip.
Do you mean that the zip at FNAL gets overwritten every time the module it tested? That's definitely the case for the PUDB at least - the mysql columns are overwritten every time new fulltest data that contains that info is submitted, so if the most recent submission had 0 pxar errors, that's what would be reported.
So the 17C results are probably over writing the -20C results... or vice versa.
On Wed, Jun 22, 2016 at 10:07 AM, gneeser notifications@github.com wrote:
Do you mean that the zip at FNAL gets overwritten every time the module it tested? That's definitely the case for the PUDB at least - the mysql columns are overwritten every time new fulltest data that contains that info is submitted, so if the most recent submission had 0 pxar errors, that's what would be reported.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/puhep/pudb/issues/189#issuecomment-227774176, or mute the thread https://github.com/notifications/unsubscribe/AElNLMQvOEwhh4A-KYgEqbbnUJHRNV7Wks5qOU-mgaJpZM4I516O .
Yes, but greg reminded of something. This can't be a 17C zip file, because it would not contain the PXAR_ERRORS field. So I have no idea what happened here.
Weird. Well, the zip that was sent to me did indeed have 0 pxar errors in the xml, and the DB seems to have correctly parsed that much - assuming that is the zip that was uploaded.
Ahhh. The zip file Jamie sent you is not the zip that was actually uploaded. From the zip:
This note is not shown anywhere on the DB page, so it must have been a different zip that was uploaded (that has been lost, unless it was on the other desktop).
Was this module tested multiple times at -20 and only uploaded once? Seems so
This still does not answer the question of what actually happened though. The -20C results (and therefore PXAR_ERRORS data) that were uploaded came from the test at 09h24m, and the corresponding moreweb results show errors.
Since the lessweb code is deterministic, and Jamie says he gets 594 errors when he reruns it on the same elCom output, I would guess the shifter did something dumb to cause this (unless we see this for other modules as well).
There are two sets of -20C results ./M-P-1-09_FPIXTest-m20C-FNAL-160617-0924_2016-06-17_09h24m_1466173471 ./M-P-1-09_FPIXTest-m20C-FNAL-160620-1231_2016-06-20_12h31m_1466443919
The test performed on the 17th has the decoding errors.
On Wed, Jun 22, 2016 at 10:33 AM, jstupak notifications@github.com wrote:
This still does not answer the question of what actually happened though. The -20C results (and therefore PXAR_ERRORS data) that were uploaded came from the test at 09h24m, and the corresponding moreweb results show errors.
Since the lessweb code is deterministic, and Jamie says he gets 594 errors when he reruns it on the same elCom output, I would guess the shifter did something dumb to cause this (unless we see this for other modules as well).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/puhep/pudb/issues/189#issuecomment-227782666, or mute the thread https://github.com/notifications/unsubscribe/AElNLOY1I_3q2IntNpFAiMxVS5PytZC4ks5qOVXNgaJpZM4I516O .
Does this mean that there actually was an error in the DB?
I think this issue is resolved. I'm going to close the issue.
Not so fast! We noticed another instance of this just now:
http://inky.physics.purdue.edu/cmsfpix//Submission_p/summary/summaryFull.php?name=M-Q-8-08
vs.
How does the DB distinguish +17 and -20 test results? the PXAR_ERROR field is in the XML for both, would later +17 results overwrite previous -20 results?
If so I can commit a quick fix for this, just let me know.
My understanding is that the latest results are the ones that will be displayed. Greg, can you confirm/deny this?
Looks like the 17C tests were run after the -20C ones.
I can confirm that only the latest results will be displayed/recorded. This is true for almost all data submitted in the xml, and where it's not true it's explicitly stated (e.g. the IV curves, etc.).
Ok then, I'll submit a fix that will remove the pXar error count from the +17 XML file.
Just as a disclaimer, be aware that pretty much any results you submit in the +17C test will override the -20C results if you submit it afterward. It's not just the pXar error count, it's also the # of bad double columns, bad bumps, ROC failure modes, etc. The database only has one entry in the MySQL for these results, and subsequent entries override previous ones.
good to know. i think the error count is the only offending item in the +17 XML, but i'll double-check.
should be fixed with 3a8e4e5
Alright then, let's keep this issue open for a while just to remind ourselves to keep an eye on it, then presumably we'll be able to close it in a few days.
Were there any other problems on this issue that you all noted?
-Greg
not that i've noticed (and i've been mostly paying attention)
Alright, I'll close the issue then. As always, let me know if you catch anything else.
Hi,
Here I see "Number of pXar errors during testing: 0":
http://inky.physics.purdue.edu/cmsfpix//Submission_p/summary/summaryFull.php?name=M-P-1-09
But here I see a different story:
http://inky.physics.purdue.edu/cmsfpix//MoReWeb/Results/REV001/R001/M-P-1-09_FPIXTest-m20C-FNAL-160617-0924_2016-06-17_09h24m_1466173471/QualificationGroup/ModuleFPIXTest_m20_1/Logfile/LogfileView/TestResult.html
Any ideas?