CIMA data loss
On Mar 7, Dorin G reported to Ken that CIMA data had been lost during a Master Class:
It all went fairly smoothly, except that some of our analysed data was lost somehow. We went from about 430 analysed events to only 180 showing up on CIMA. This made it difficult to see meaningful "humps" in the histogram. It could be that some of the students opened the wrong CIMA file; however, there was only one Nagoya so I don't know what could have happened. This is something I would check better next time.
Ken asked Dorin for more info; awaiting response. Need to learn CIMA.
On Feb 3 Rebecca J reported that the password retrieval function is not working. The cause is known: at ANL, the password retrieval function worked through an @i2u2.org email address. This needs to be changed to a @fnal address. Code is fixed; just needs to be deployed.
Cosmic data upload error
On Feb 17 Trish B reported through the Help Desk that
We are trying to upload data to the eLab, but it won't work. When trying to Register the detector ID number to the account under Registration, the detector's ID number (6679) is there, but it is not an option to select in the Upload tab.
This part was solved by Martin S: The group did not have upload privileges.
In Registration, select "Update your Research groups including passwords", find your group and press "show group info". Here you need to make sure this group has upload "yes".
Trish corrected accordingly. However, her detector did not show up as an option. Martin suggested using "Update detector ID for your group", but found that this function was not working on the new servers. Ken confirmed a problem:
I just check in mine and it only shows detector 5045. The full list still exists in my Upload page, though.
Edit seems to have fixed the problem:
I've found tbaker and pbaker and now detector 6679 is attached to both
No bugs, I could update the detector without any problems.
Investigate the "Update detector ID for your group" function to recreate.
Cosmic missing data
On Mar 4, Kevin M reported that he cannot access his past data:
I tried to access existing data from the elab server (first attempt with the updated server) and could not find any of my old data (several years
worth). Using chrome with the elab server, I was unable to find any data.
Error indicates another Java bug:
HTTP Status 500 - An exception occurred processing JSP page
/cosmic/data/cosmic-data-map.jsp at line 25
Mark reports (Mar 5):
Yesterday and today I checked data from DAQs at Fermi, GBS and GBN and I don’t see any problems. I’m using Firefox. Was this solved by using a different DAQ number or is it still current?
Need to recreate.
Cosmic reports error
On Mar 2, Mark reported that he encountered an error while running a report on e-Lab plots covering 29jan through 29feb2016 and got this exception:
HTTP Status 500 - An exception occurred processing JSP page /cosmic/reports/plots-report.jsp at line 62
On the indicated line, one of the arguments to reportLines.put() was returning null. This is presumably entry.getTupleValue() or its String casting. getTupleValue() is defined in /src/java/gov/fnal/elab/datacatalog/impl/vds/VDSCatalogEntry.java.
getTupleValue() returns null if
- no entry in the List<> has a key that matches the input key (in this case, "name"), or
- the value associated with the first matching key is itself null.
On i2u2-prod, I recreated Mark's error on Plots Report. Uploads Report and Posters Report appear to function normally; it's just Plots report that gives the error. Seems to be a Java update bug within the indicated .jsp file.
Status: Edit has stopgap fix, waiting to deploy. Want to fix underlying problem, though.
Cosmic ToF combined plotting
On Mar 2, Martin S reported through Mark that he has found errors with the combined plotting mechanism:
Martin discovered a problem in the TOF combined plotting. I haven’t used the combined plots, so I haven’t been exercising it like I have the 6 individual plots. Martin wants to use the tooltip to find the content of each bin in a plot. I’ve tried to redirect him to capture the histogram in other ways, but the bug is still there, even if he follows a different path.
I think this summarizes it:
If the sliding bin control is set to 1.25ns, the combined histogram is generated with 2ns binning. When I select 6.25ns binning, the binning in the plot seems correct.
I have not generated a golden data set where I know the answer to check whether the plots are otherwise correct, but I have been using them to measure the muon speed to 1% accuracy and the individual plots and combined plots contain the same number of events.
Need to recreate.
CIMA loading problem
On Mar 3, Shane W reported that CIMA was not loading during a Master Class. The problem seemed to have corrected itself within hours. Shane will follow up with more info later.
follow up with Shane
On Feb 12, Scott B reported
1) Pre-Test goes to an error page when students attempt to submit answers. They have to submit and the shorten the URL to go back to the basic LIGO e-Lab URL at which point they can start the e-Lab. I believe they have to do this every time they log in.
2) An pop-up error is displayed sometime when student attempt to save plot made on either collection of dated data. We could not find a pattern to the errors. Reloading and re-making a graph maybe helped (not sure if they were really consistent in reproducing graphs). Changing other graphs options one at a time to avoid to error would sometimes work but the methods were not consistent across groups. Sometimes changing the date by a day worked for one, but not others. Sometimes reducing the number of included detectors helped, but not always. Maybe it is a data volume issue?
(These errors existed and were reported before, but the Help Desk email wasn't working, so no one got them)
1) was a Java bug, fixed now; will document later
2) I can't replicate. Will wait for further complaint. Maybe it got fixed with something else.
Fixed/pending further complaint
-- Main.jgriffith - 2016-03-07