Agenda and Minutes, 7 March 2007
Agenda: Wed, 7 March 2007
Minutes
Attendance: Ed Patrick Kipp Duncan Stuart Eirini Xavi Kevin Brian Adam Igor Jolien Announcements: S5 V3 calibration has been released, Eirini will generate calibration frames in the next few days. Which search groups need a new V3 h(t) data set? The inspiral group are likely to stick with V2 for the ongoing analysis, do other groups need it urgently. Face to face: Either the Thursday or the Friday afternoon. What are the high priority items to discuss at this meeting in terms of software tools, etc. and what might go into the OSG software that is currently being designed. LSCsoft: LAL and LALApps are in the FC4 testing repo. FrameCPP is ready, but Adam is not sure how to test. Stuart suggests testing DOL against this. DMT: John is trying to recompile DMT online due to difference between 64 bit and 32 bit FrameCPP install. Caltech compilers have been upgraded to gcc 4.11 which broke some DMT things. Glue: Duncan and Igor will get together at the LSC meeting to discuss the segment database modifications. LAL/apps: No report LDAS: Pre-release appears to be running fine. Aggressive testing starting. LIGOtools: No report. Matapps: No report from Keith. Matlab 2007A is out, Stuart will inspiral at CIT so Keith can test it. LDR: No report. LDG: Will be a new release of LDG before the LSC meeting. Greg will send out a pre-release this week. This include VDT 1.6.1. For mac and solaris clients the globus is built on 4.0.4. May be some issues with the pyglobus build on OS X; Duncan and Greg will take a look at this Other business: Should we change the compression mode of the RDS? No major concerns from the DASWG side. Stuart will ask the S5 run committee. DTT cannot currently read the new compression format. What should we do with h(t) generation in S5 and S6? Greg circulated a proposal to use the LAL h(t) generation code first on the LDAS hardware using Greg's RDS scripts and so LDAS people will take over the management of h(t) generation. The post-S5 proposal is to have h (t) and RDS generation code be linked into the LDAS code base so it can use all the data integrity and other checks in LDAS. Plan is to have standalone code that can be run on the cluster for quick generation, or inside the LDAS software for online generation. As part of h(t) review the committee wants more information in the frames. At present it is pretty minimal. Might be nice to have more information in the frames, like control signals. Proposal is to have level 1 h(t) frames that have the history, DARM_CTRL, the excitation channel, the filter information, etc. Subsequent h(t) revisions could be generated from these frames, as they contain all the raw information. Xavi is resurrecting the h(t) frame format document. There would be a level 2 h(t) that only contains h(t). Xavi will circulate the proposal. Should L2 be down-sampled? Should it be high-passed and single precision? Should we store the frequency domain response function as well? Jolien commented that if Xavi is storing alpha's and gamma's it should be done in the same was as documented in the existing calibration frame format. How should we store the filters?
$Id: 070307.html,v 1.1 2007/03/14 17:27:53 patrick Exp $