Meeting Notes for 29 October 2008
Present: Dan, Eric, Liz, Tom L.,Tom J. Bob
Report on CMS Java Applet Interface
What follows is Dan K's description via e-mail in regular text, along with comments from the telecon in italics.
"I've got a beta version of OGRE with the graphical analysis up at
http://leptoquark.hep.nd.edu/~ogre/ . (This is the PHP version, but all the changes are in the perl-scripts that work behind the scenes so it shouldn't take any effort to move it over to the Tomcat server in the end. This was just easier for me to work with along the way). I'd appreciate any comments you have. To use it, pick a plot (or several -- at this point the cut can't be done when there are several plots displayed, so if you pick multiple quantities to plot it will automatically plot everything on one histogram). Pick a data set with the "Data" button and optionally, pick colors and log plots. Pretty much like it's always been.
Note: in our case, we chose Total Energy (3x3), picked a color on the right, clicked the log y checkbox. To select the data, we chose muons. There were some issues with seeing the popups (e.g., some had blocked them, or didn't have Java installed).
Once you hit the "Plot" button you'll get the new stuff. A graphics page will show up along with a (small) "history" page which shows a thumbnail of the current plot. If you run your mouse around in the plot it'll show you a red (
vertical) line and a number corresponding to the value on the X-axis where the mouse is at. You can make selections several ways. A left click will select everything greater than, a right click will select everything less than, and a drag will select anything greater than the start position, and less than the end position. Also, the actual numbers are in a text box at the top, and you can enter the (integer) values directly. The current selection is high-lighted (
in grey); to clear it click outside of the axes (but within the applet area).
When you're happy with the selection, click the "Apply" button at the bottom. The page will reload with the new cuts applied to the data, and the history page will reload to show the new plot. The thumbnails on the history page are links which you can use to go back to any previous cut, and a tooltip on each thumbnail will show you what cuts were imposed on the data to make that plot. As you make cuts the history page will build up a family tree structure with the latest plot outlined in light green and all the plots that led up to it in dark green.
Suggestions: Eric suggested using yellow to show the cut, however this would not work so well if someone chose yellow as the color of the plot. Liz suggested having some instructions for selecting the cut at the bottom. Eric voiced his dislike for pop-ups and suggested that Dan might try using the approach he used with Bluestone where he works people through sequential pages for each step. Liz suggested using dynamic pages that display the different content on the same page. Eric also mentioned a technique where you could display overlays that dissolve. Eric had some problems because he had his browser set to open a new tab with each new page so the history page set the width and obscured the fuller starting window. On the Mac, we could not use the text box to set the cuts.
Caveats: I've tested this thing on Windows, Linux, and Mac. On Windows IE, FireFox, and Safari work fine (though the default security settings in IE8 throw fits about the applet being unsigned). On Linux, FireFox and konqueror work (though KDE4 has some strange issues with the applet viewer and kded). On Mac, Safari works fine, but FireFox doesn't work at all (and apparently never will). The highlighting of the selection values uses an overlay in the applet, so it can take quite a bit of processor power if you're doing a lot of it quickly. On Mac something odd is happening around the text box that seems to push the processor to 100%. I've no idea so far what's going on. The browser windows are supposed to resize themselves to hold the graphics, but that seems hit & miss at this point.
The problem with FireFox on a Mac is related to the JavaScript code in the plot window to get parameters from the Java applet and putting them in the form. Dan asked us to "View Page Source" to look at this code:
function submitForm(thisForm) {
with (thisForm) {
cutMin.value = document.select.getMin();
cutMax.value = document.select.getMax();
}
Dan is using LiveConnect for this and it is not supported in Firefox. Dan needs to find another solution for getting this.
As well, the web-site uses cookies, javascript, java applets, and pop-ups. So you'll need to allow those things in order to use it properly (I haven't yet built a proper test page -- like the one EVO uses -- in order to make sure that everything is in order before you're forwarded into the selection page).
A test page or matrix of tests is a good idea in general!
One other thing I've added, there's an "Archive" button on the graphics page, since there's this intermediate step with a displayed history it's easy to pack it up and come back later (or go back and start from a previous study). If you hit the archive button it will store everything you've done and give you a (very large, random) number. If you later click the "Restore Session" button on the main page it will ask you for the number and then go find that archive and drop you right back to where you were. (I presume that number can be easily replaced with a JSessionID from a cookie for deployment). The last button on the graphics page, "Finalize" packs up all of the work, and moves the plot, the archive, and the final root script into the results section.
The Grid will be utilized here to get the data. Presumably we could have a way to farm out these to nodes on the grid.
Liz also wanted to understand how this fits into the e-Lab paradigm of saving plots with metadata. Eric offered his method of saving plots. It may be that we might want to save in the metadata, the information about the session id so that we could easily go to a session that created the plot. We will have to have Mihael take a look at it.
Summer of Code
Google funds an REU for computer students. It pays for student to work on project. We might consider applying a student. SWIFT had one. It’s early to look at this. Code may have to be open-source. We haven’t declared any license on our code. We would have to have a mentor, and sell them on our project.
Communication on End of Year Report
Marge is eager for people to submit their contributions to this. Fred is working on the LIGO contribution and Dale reviewing, but it is basically done. CMS is done and Cosmic still needs writing.
Action Items from Last Week
Action Item: Liz will clarify if we can use Cosmic teachers to test LIGO.
Jean is doing this in Phoenix so we don’t need any teachers for LIGO testing.
Action Item: Liz will ask Marge whether we could hire a private company.
We have not paid Argonne any money since October. Marge wants to ask Mike to respond to this. We have money for 8 more machines so we probably don’t want to be using machines that we don’t own.
Moodle
Eric would like to set up test stand on one of our machiens to try out Moodle (see
http://moodle.org). It is a content management system geared to education. It might be useful for the overall framework for the ELabs main portal. Or not. It might be useful for QuarkNet site.
We already had a brief introductory tour during one telecon where Eric showed the Moodle pages for a class he taught at Bard College.
Some possible advantages are: it automatically provides for segregated of users (eg by class or for committees or working groups).
It is expected to be easy to install and maintain, and to customize. It's PHP with a MySQL database, which is common and something we are familiar with using. It has features like a wiki, glossary. It seeems to be easy to customize and to administer; It's possible to delegate to the teachers control of aspects of their own areas. People may already be familiar with it (it's in use at Notre Dame, Fred says teachers he and Dale are in contact with are using it) and school districts may use it. It provides a way to upload docuements and distribute to the group. Moodle has a big user base and big support base, so we won't have to maintain lots of code, only our customizations. If we invent something useful for us we could contribute it to Moodle and let them maintain it (if general enough)
Some possible disadvantages: Fred and Dale report they found it hard to learn at first. In particular, the mechanism for uploading documents and then placing them is awkward. It has many features, but if there are too many we don't need that might be overly confusing. The BOINC forum code with our additions (or whatever we write) can do just what we want, which might be better. It could be that Moodle sort of does things we want, but not the way we want them, and we end up messing around too much making (and maintaining) or own modifications, when just writing our own code could be simpler.
TomL made the point that he favors something that is nothing like a classroom setting, to encourage teachers and students to "think outside the box" (where the box in this case is the classroom). Eric liked the idea, but worried that it might prevent teachers from trying it, or scare them away. Some overlap with the traditional classroom structure/metaphore may be needed.
There are other Content Management Systems we might also consider: Sakai (
http://www.sakaiproject.org) is an educational CMS used and maintained by a consortium of Universities (so maybe better for college, not so much for high school?). Plone (
http://plone.org) is a more general purpose CMS which Fermilab already uses. Perhaps it's enough for our purposes?
Eric proposes to setup test instance and to try to think ahead about what we might need, and to deternube the relative weights of these advantages and disadvantages listed above (and the others we find as we go along). We could also set up tests of Sakai and/or Plone if that seems useful, but start with Moodle.
-- Main.LizQuigg - 29 Oct 2008
-- Main.EricMyers - 30 Oct 2008