Core Minutes 12/9/2014
ScienceTools: (Jim)
See Science Tools Development Notes for details.
FSSC: (Joe) couldn't attend today but sent in the following report:
Currently working on debugging ScienceTools source builds on Yosemite using Root 5.34/24. I have managed to get the build to complete, however, I am seeing some unit test failures that I am currently working on fixing.
In general, most of the updates needed for Yosemite compatibility (that I have run into so far) have been related to problems with ROOT and Python. Once I have a more comprehensive list of problems/solutions, I will contact Jim and Heather and let them know about changes that we had to make on our end so that we both don't end up solving the same problems multiple times.
Reprocessing: (Tom G.) No news. Target for release is Feb. 2015; we can expect another backfill before then.
Hardware: (Tom) Work on the new servers continues. Some enhancements to xroot were required to support a different hardware configuration (2 cpu's + disk). Andy Hanushevsky got that done in September.
Coming events: (Richard) A Finance committee meeting is coming up (at 6:45 AM!). We have $60K left over from 2014 in computing money. I think it needs to be spent by February, but I need to check. (Tom) We might wish to purchase some storageless NFS servers — to work with GPFS. (Richard) Also on the horizon is a Cosmic Frontier Operations review — which includes Fermi — on 12/18. He'll be giving a 14-minute presentation.
Pass8: (Leon) People are starting to think seriously about making calibrations official: documenting what they're for, how they work, etc. while there are still folks with sufficient expertise to do that.
Concern about the not-so-isotropic isotropic background continues. There is a strong dependence on declination, probably because cosmic rays are not being handled correctly. Earlier it was thought that this was a Pass8-only effect, but Gulli has shown that it's existed all along. (Richard) does this mean we need new diffuse, new FT1 files? (Leon) Yes. Do we try to do this before the Pass8 release? If so, schedule (February release) is optimistic.
GR and 64-bits (Joanne) Johan quickly discovered that last week's fix to EbfWriter was not sufficient. Most runs with overlays crashed in obf (different place from the earlier crash). It seemed likely a similar kind of coding error (taking sizeof(ptr) rather than sizeof(*ptr) ) was at fault in the code generating MC events. A search of EbfWriter source turned up one more, in code that would only be traversed for relatively rare events. Yesterday I was able to confirm that the crash did happen for such an event, and that fixing the code eliminated the crash. So far, Johan has not come up with any more crashes in obf. A new GR, incorporating the latest EbfWriter tag and CalRecon tag (Philippe's work to fix a 64-bit bug in that package), is likely soon.
glastlnx07 (Heather) No recent progress. Yemi is desperate enough to push this along that he is now volunteering to help.
Mac (Joanne, sounding a bit like a broken record) No progress since last meeting; all my Fermi cycles were devoted to the Ebfwriter/obf crash. Maybe next time. Here is the intimidating table of work to be done to support RM builds via Jenkins in the Mavericks VM.
Where and how to freeze (Richard) Now that the transition to rhel6 64-bit is maybe close to completion, we need to think about what OS we ultimately freeze on. (Joanne) is hopeful that the transition from rhel6 to rhel7 will be easier since problems will tend to crop up at build time (due to new compiler) rather than run time. (Heather) is not concerned about ST. The worst of the work is likely to be in getting builds of some of the GR externals, such as gaudi and ROOT. (Richard) And G4? (Heather) would like to upgrade that anyway. The problem is finding people to verify. (Jim) Are we restricted to a particular VM technology? DM is partical to Docker. (Richard) Should be discussed with Yemi. (Tom) rhel7 support is only just beginning. He logged into a public rhel7 machine which did not seem to be fully configured.
Python strategies (Heather) had been thinking of moving to Anaconda. It would be less work and we'd have more reliable documentation on exactly what was included. It includes a number of things some people want, anyway (and plenty more). But Joe talked to Dave Davis and came back with the news that FSSC doesn't want to go that route. (Richard, Jim) Why do they care? They don't have to use Anaconda to make their distribution. (Heather) will inquire further.
Evogh has been swallowed up by eZuce. We shouldn't see any difference (same cost, same contact/support people).
|
|
minutes index
|
next
|