Meeting Notes for 9 January 2008

Present: Eric, Bob, Mihael, Liz, , Tom J., Nick
Absent: Mike W. Randy, Dan K., K. Whelan, Joao,Tom L.

Announcement

Mihael will be alternating between working on SWIFT one week and ELabs the next.

Refactored Code

Testing in General

We had a problem that the changes on production to get the cpld changes in actually broke running an analysis from a saved plot because the extra parameter did not exist for these and was inconsistent with the new version of the TR. NIck did not realize this so it started a long discussion of the best way of testing. It actually is what we wrote up in our procedures( NewReleaseProcess ) and in previous minutes, but we did not follow them. One of us stated: "Untested code is non-working code". Eric emphasized the importance of having long-term testing of a new branch. He mentioned two types of testing:

• Automatic regression testing like JMeter
• Hands-on

There is a good book on using SVN. The section Eric pointed out was: http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns

Action Item: Mihael will document from the SVN book and model it with www12 and www18.

Testing Refactored Code

Mihael noted problems with a race condition for some analyses.

MIhael made some changes last night that fixed the problem with rerunning from a saved plot that came up when we added clpd code.

Now we can do the testing. Put the testing procedure on the wiki. VDS all looks good, but the SWIFT stuff is shaky (grid stuff).

Shower tended to require a lot of memory and cause an out of memory problem (not a memory leak). File can be a 40 Mbyte file. Is there a more efficient way to do this? The user needs to limit his results so it does not get so big. It kills the machine the analysis is running on. Mihael is thinking about it. Some ideas for solving this are:

• Presorting the events files in multiple ways before you display it. You wouldn’t have it all in memory.
• Capturing the out of memory exception and giving a meaningful error message.
• More memory on the machines. 18 is going to be the front-end server. It will have double the memory.
• (Eric) Perhaps this is an opportunity to implement levels for users as they do for LIGO in the beginner level, we give them a warning. For intermediate, we enlarge this. This is the hardest to implement now since we don't have levels for Cosmic e-Lab users.

Bob, Tom and Nick put their heads together to decide the criteria for moving the refactored code into production. CriteriaAcceptRefactoredCode

Nick: Flux is the only study that provides the same result as production. Nick will type up what he found. It may be some weirdness in the workflows between SWIFT and production.

Touching Data Files when Metadata changed

In production, whenever a geometry file is updated that affects data files for which we have metadata, we updated the metadata to reflect the latest changes (e.g., stacked/unstacked). Mihael did not implement this in the refactored code. There was a discussion whether he should. Later communications between Nick and Mihael cleared up some of the misunderstandings of the benefits of this.

Temperature and Flux Plots

Nick reported on his work on www13 to use the data that can be collected from the DAQs to plot the flux vs. temperature and flux vs. air pressure. Nick was unable to get the modified TR to load so instead he changed the existing TR. This meant that it broke all of the other studies to get this to work for the modified TR. Eric mentioned that he wanted to do some similar plots and thought we should think about the general issue of how to handle any time-dependent data files. Nick had thought about this and has written up his ideas in the CosmicElabExtraVariables section of the wiki.

Failing Nodes

We may have strategies to handle failing nodes. We have really just been using www14 for the analyses.

-- Main.LizQuigg - 15 Jan 2008