Carleton: N. Christensen
CIT: B. Bhawal, K. Blackburn, A. Lazzarini, B. Mours, V. Sannibale, P. Shawhan, H. Yamamoto, J. Zweizig
Dublin: A. Ottewill
Florida: B. Whiting
LHO: R. Gustafson, W. Kells, M. Landry, R. McCarthy, G. Mendel, D. Ottaway, R. Schofield, R. Weiss, S. Whitcomb
LLO: S. Marka, H. Rong, P. Saulson
Michigan: K. Riles
MIT: D. Shoemaker, D. Sigg, J. Sylvestre, M. Zucker
Oregon: D. Strom
PSU: G. Gonzalez

• The E2 run will differ from E1 in its emphasis on testing operations, including data distribution and online analysis. The run is meant to help identify areas where work is needed to automate operations and involve the LSC more deeply in IFO characterization.
• This meeting is meant to give everyone an update on plans and available resources. Participants should start thinking about what special software/resources they may need for their investigations.
• Daniel Sigg has set up an official E2 web page where general information on the run can be found..
• The next meeting will be an October 24 teleconference of investigation leaders where special requests should be made. There will also be meetings at Hanford on the Monday and Tuesday before the run to get final status reports on hardware, software and analysis plans. Any last pre-run preparations can be addressed then. During the run there will be daily meetings at 8:00 a.m. of about 15 minutes and at 4:00 p.m. of about half an hour to review status and make any plans for special running configurations.
• Software that is to run in production mode in the Data Monitor Tool should be given to John no later than October 31.
• Investigating teams should report results as soon as possible after the run. The monthly detector characterization teleconferences are the natural forum. Groups should present preliminary reports no later than the February 2 teleconference and should present final reports at the March LSC meeting.
• After some discussion, it was decided that final reports should consist of presentations at the LSC meeting accompanied by written reports to be placed in the LIGO DCC. Albert proposed mandating latex and postscript files for archiving. An official LSC policy on document format will be discussed at the next executive committee meeting (Oct. 20).

• Hardware and software is in place to allow full locks of the 2-km IFO, but locked periods are quite short. It is hoped to stretch these out to a range of several minutes to half an hour by the E2 run.
• Wave front sensing is unlikely to be available for the full interferometer. It might be available for the power recycled michelson cavity or for a single arm, but this will require some work. No guarantee can be made now.
• It it believed that reliable 1-arm locking, with and without the power recycled michelson, will be available, with locked stretches approaching 2 hours (comparable to what was achieved in the April E1 run with a single arm).
• Given the expected instability of full configuration locks, most investigations would probably be best served by a mixture of configurations.  For example, those studying frequency noise propagation may prefer a simple single-arm lock. Those studying tides may want to alternate between x and y single-arm locks to study differential and common mode effects.
• An update on expected status will be given at the Oct 24 teleconference, but no final decisions are likely before the first week of November.
• Although special shifts with running conditions optimized for specific investigations can be arranged, the decision of which shifts to dedicate will probably have to wait until just before or during the run.

• There are four data types to be produced during the E2 run: 1) metadata in the form of triggers from the GDS system (e.g., DMT transients), 2) trend data (mean,min,max,rms) of every channel over each second and over each minute, 3) raw data in frames, and 4) reduced data in frames.
• Metadata tables can be viewed with the Guild program, and triggers from the E1 run exist there now. DMT software writers are strongly urged to write trigger-generating monitors to exercise the system in real-time during E2.
• The second-trend data is available in the control room for roughly one week after collection and can be viewed most usefully with the data viewer, but only on the CDS private network at the moment. Some discussion ensued on making the data viewer available offsite. The trend data will be stored in frames in the CACR archive. It is believed that the viewer is quite Solaris-specific, difficult to port to another platform. It receives its data from the network data server (nds) which is straightforward to set up elsewhere, however. Other possibilities for viewing trend data are through nds interfaces in matlab and mathematica or through the DMT.  John confirmed that the DMT can now read trend frames, and a sample root macro for viewing is available. But it lacks the convenient display tools available with the data viewer. John would welcome a volunteer to write a dedicated trend viewer.
• Greg Mendel has written software to write the entire raw data to tape for shipping to the CACR archive. Once in the archive, the data can be accessed manually through ftp (available now).
• The direct ftp method has the severe disadvantage that to obtain one channel, one must download all channels. Peter is working on a data flow manager to allow users to request specific channels for given periods of time. The manager then strips out that channel and writes it over the network to the user's local disk (requires a socket connection to be maintained). The channel stripper can process and write data about five times the original real-time data collection rate.
• Albert suggested that CDS use E2 to test writing of various flavors of framed data directly from the daq system. Daniel objected that it would be more useful and flexible to write special framed data offline.
• David Strom wondered if the fortress reduced data set writer could be run on the CACR hpss system. After some discussion it appeared that this is feasible, as long as file sizes of at least 100 MB are used. There would be about five minutes of overhead in retrieving even a small sample of data. It was suggested and seconded that a small test sample of data be available permanently on disk to allow users to excercise code before reading the entire data sample.
• Reduced data will be written from fortress at a maximum rate of about 5 MB/s. Some discussion ensued on what that reduced data should contain. One suggestion was the union of requests from investigating teams. KR asked that the Oregon group circulate a baseline proposal of channels and sampling rates for consideration before the Oct 24 teleconferences to focus that discussion. Team leaders will be asked to look over the list and request any needed changes. The nominal channel list for all data can be found here. Stan pointed out that reduced data can include information derived from various test points in the control system not written by default to raw data frames by the daq system.
• John  pointed out that recording only one fast channel (16 kHz, 2 bytes) for a full week requires about 20 GB of disk space. Stan reminded everyone that the data will not be monolithic locked data in one configuration. Most investigations will not need the full week of data.
• Albert stated that if many designer data sets are requested by teams from the CACR archive, he will need a volunteer from the LSC (e.g., a graduate student) to take care of the tape writing.
• Dave Strom asked if a list of locked sections (and more generally, of "good" sections of data) will be available after the run. Peter said that the metadatabase supports that feature, as it did for the E1 run, but DMT monitors have to provide the information. Such information should be recorded in the electronic log too.
• Peter emphasized that any relevant information to the E2 run should be made availabe on the E2 web page. Please send such information (documents, web links, etc) to Daniel.

• At the start of the E2 run, shift takers will be trained on the various tools available, including the data viewer, the diagnostic test tool, the DMT, and the DMT monitor display manager. Biplab and Hiro will be on hand to help persons wishing to use the end to end model. Alignment effects are expected to be included in the E2E by the time of the E2 run.
• Expected facilities for the run include trend writing, sub-sample writing, trigger generation, spectrum recording in the metadatabase and serving of data in the monitor display manager.
• John urged DMT software writers to get their code ready for the run and asked investigators to think about what tools will be useful to them during the run. Rai asked where one could find a list of software tools now available in the DMT. John offered to post a list on the DMT home page.
• Production level monitors that exist now or will exist by E2 include 1) transient ID (J. Sylvestre), cross-correlation monitor (A. Ottewill), timing stability (S. Marka), channel bit testing (J. Zweizig), power line (D. Sigg), data integrity (J. Zweizig), PSL monitor (J. Zweizig). Several others may be available.
• Albert wanted to ensure that whatever DMT code was used during the run be known afterward. John said he would tag that version in the CVS archive for future reference.
• In addition to fortress, two other machines, sand and stone, will be running DMT code. stone will be reserved for production monitors. fortress will mainly be used for reduced data set generation, and sand will be available for interactive sessions and not-ready-for-primetime background monitors being tested. fortress can also be used for e2e simulations and browsing of reduced data with the data viewer and the diagnostic test tool. Constraints on reduced data storage are total Raid disk space of 2 x 70 GB and a maximum AIT-2 tape recording rate of 3-5 MB/s.

• The shift schedule is in good shape, with nearly every slot filled (present shift list). One more person is needed for the last owl shift, and an expert may be needed to replace Rick Savage on the last two day shifts, if a swap for him can't be arranged (he must travel to Germany that week).
• The schedule is firm enough to no longer be called preliminary, and shift takers are encouraged to go ahead and book flights, if they have been holding off.
• An overview of shift operations and a preliminary list of duties can be found here.

Status of investigations (Keith Riles)

• All tasks have at least one volunteer, but some could probably use more help. In particular, the following tasks seem a little short-handed: correlations, Gaussianity, and data integrity check.
• Leaders have been found for most of the tasks, but some remain to be confirmed. The confirmed leaders are marked with asterisks on the investigation task list.
• Leaders must get organized quite soon to address the following:
• Subtask assignments, if needed.
• Required data channels and sampling rates (see above discussion). Since not all channels in the nominal list can be guaranteed to be connected, sensible and calibrated, the teams should make sure before the run that the channels are there. Questionable channels should be brought up at the Oct 24 telecon or with run organizers.
• Decide what analysis needs to be done both during and after the run.
• Decide whether special running conditions will be needed. If so, run organizers should be informed soon (e.g., at the next telecon).
• Decide how and where to carry out a post-run analysis (on LHO machines?, at CACR?, at a home institute?) and whether a special designer data set is appropriate.
• As mentioned above, teams should report on results in a timely way, at monthly detector characterization elecons and eventually at the March LSC meeting with presentations and written reports.