S4 Plans & Investigations (including followups to Wednesday's E12 review):

• Scimon shift schedule (Keith Riles)
  KR reminded everyone that the S4 scimon shift schedule is posted, and many names remain to be filled.
  
  
• Calibration plans (Mike Landry, Gaby Gonzalez, Brian O'Reilly, Patrick Sutton, Xavi Siemens)
  Mike reported that measurements needed for the S4 calibration of H1 and H2 are nearly complete. A set of calibration files usable by DMT FOM monitors and by online analysis code is expected to be ready by the end of next week. The autocalibrator at LHO is now working again, and there's a good chance that the photon calibrator will be workin on the ETMX mass, allowing a check before the run of systematics on absolute H1 calibration scale. The photon calibrator will not be operating during the run, however. Calibration injection lines will be moved to match more closely those now used on L1. Sergey Klimenko requested that the lines among the interferometers be closely matched so that fewer frequency bands are affected in the WaveBurst analysis, prefererably in the same 8 Hz band. PeterF cautioned that H1 and H2 lines should not be as close as they were in S3 because of observed coherences in their vicinity.
  Brian reported that the L1 situation is similar: nearly all measurements done, with calibration files ready next week.  In general, calibration stability looks much better than in S3. There will not be a photon calibrator available for L1. The strength of the 1151.5 Hz line will be increased to ensure good SNR for short time intervals, but the strengths of the two lower-frequency injections will be reduced. The online analyses plan to use the new GW channel DARM_ERR for which time varying calibration should be much less pronounced than for AS_Q, allowing the analyses to set their alpha/beta values to unity, for simplicity. There will be no major mid-run calibration work, but time will be used the day after the run ends to do some checks. There will be occasional, brief open-loop-gain measurements during the run.
  
  
• Timing monitoring plans (Szabi Marka, Daniel Sigg)
  Szabi has tried following up on some multi-microsecond timing jumps observed in some LLO PEM channels during the early part of E12, but has not yet pinned down the source of the problem. The size of the jumps is quite acceptable, but he would like to understand the mechanism. Brian wondered if the timing jumps had anything to do with recently observed channel hopping in the DAQ. Szabi thought not, but will follow up on an elog entry Brian mentioned. Szabi also mentioned that the atomic clocks at the sites agree well with the GPS clocks.
  
  
• Reduced data set generation (Greg Mendell, Isabel Leonor, Igor Yakushin)
  Greg reported that RDS generation went well during E12, despite some downstream problems in moving data off site. One bug was found that had led to an 800-second loss of level 3 data; it is now fixed. Isabel reported that she has collected requests for RDS data channels and downsamplings and will circulate the latest channel list next week. Some SPOB channels are still missing from the LHO data stream, but are expected to be in place soon.
  PeterF suggested creating a new level 4 RDS that would contain only DARM_ERR downsampled to 2 kHz for the stochastic group. Gaby said that the inspiral group could use such a data set but at 4 kHz. It was tentatively decided to go with a 4 kHz level 4 for both groups, but to run it by Stuart Anderson and the LDR people first. [Note added by KR: after much discussion among many parties the following week, it was decided that the drawback of keeping track of another RDS level outweighed the benefits of having the downsampled data.] It was also tentatively decided to store not only the 16 Hz state vector channel in level 3 RDS, but also the "activity" information (also 16 kHz) to avoid confusion over injections vs non-injections science mode. PeterSh is working on a proposal to incorporate all needed information into the state vector. He will circulate the proposal for comment next week.
  
  
• Hardware signal injection plans (Peter Shawhan, Vuk Mandic, Szabi Marka)
  Vuk reported that the inspiral group has analyzed their E12 hardware injections and recovered most of them, losing only some simulated to be quite distant (>10 Mpc?). The bursts injected during E12 were the same as those used in S3. There were also 100-minute stochastic injections on L1&A1 and on L1&H2. Some new pulsar injection code was tested with 10 minutes of injections on H1&L1 and a 24-hour injection on L1 only. The pulsar group is asked to check these injections, given the injection code changes since S3. PeterSh and Vuk will be sending out a formal request soon to the search groups soliciting detailed injection requests. Sukanta  mentioned that the stochastic group is working on a plan that has some long injections near the start of the run, about a 1-hour injection in the middle, with end-run injections depending on analysis outcome of the earlier injections. Sergey wondered whether playground data intervals would be used in S4, and if so, whether injections should be restricted to those intervals. After some discussion, it was concluded that such restriction would be impractical.
  
  
• PEM injection plans (Robert Schofield, Josh Dalrymple)
  Robert reported that he will be doing two sets of PEM injections during S4, the first at LHO during week one when he will be doing scimon shifts, the second at LLO the week before the LSC meeting. Each set will be 4-5 hours long. PeterF suggested that good use be made of LLO time during the LHO injections. Robert said he would talk to Doug Lormand at LLO about getting some measurements done during that time that were not completed during E12.

DMT Software Status:

• John Zweizig: Infrastructure status (hardware & software)
  John reported that there remain many DMT data dropouts at LLO. He has tried reconfiguring shared memory on DMT machines to try to reduce page swapping. Initial results show some reduction in loss, but not enough. He is now working on spreading the load among the different DMT machines. He doesn't understand why the cpus appear so loaded and suspects a newly introduced inefficiency somewhere in the DMT infrastructure. One clue: Sergey found that BurstMon was spending excessive time outside of the core process-data routine. KR stated that if these measures are not successful, then we should start pruning some monitors. He has sent a list of candidate monitors to John.
  Sergey wondered if the occasional hangs of the DMT viewer could be fixed before S4. John thought not; the mailbox communication between the DMT monitors and the DMT viewer isn't as robust as we would like. KR suggested that operators be given instructions on how to log into DMT machines and "nudge" non-responsive monitors so that they resume serving DMT viewer objects. John has a nice GUI for doing this, but it doesn't work at LLO at the moment because of some firewall problems.
  John reported that Patrick Sutton is working on a DMT viewer time stamp problem in SenseMonitor that has become apparent only recently because of the many data dropouts at LLO. Apparently SenseMonitor doesn't keep track of the dropouts when filling the DMT viewer history object. John suspects the same problem afflicts StochMon and PulsarMon, since those monitors were built on top of SenseMonitor.
  
  
• John Whelan / Mark Cenac / Brian O'Reilly: StochMon
  John reported that on their to-do list is fixing DMT trend channel names to follow the new convention and changing the way the reference PSD's are defined for the "other" interferometer. He plans to keep watch on StochMon during S4 and update references, as appropriate. He has tried comparing the Omega sensitivities calculated by StochMon during E12 with expected values from an independently written Matlab program. Because of a technical problem, the comparison isn't yet exact, but a quick n dirty comparison shows agreement at the 5% level.
  
  
• Ken Ganezer: seis_blrms
  Ken is trying to verify whether his latest seis_blrms program is finding exactly the same data dropouts as seen by the older version. He sees differences now, but the old and new versions are running on different DMT machines while looking at the same data. KR suggested running the two versions on the same DMT machine, e.g., fortress, and if they agree on dropouts, giving the latest version to John for running online during S4.
  
  
• Sergey Klimenko: BurstMon
  Sergey reported that the latest BurstMon is a week old and ran successfully during E12. Following some discussions during E12, he has implemented a version of BurstMon that does not compute hrss@50% and is thus much less cpu-intensive, but does compute the other FOMs (e.g, pixel fraction, non-stationarity). He proposed and it was agreed that the hrss version be run on each IFO up to 1 kHz and that the non-hrss version be run separately for IFO up to 2 kHz. To avoid DMT trend name conflicts and DMT viewer object name conflicts, he has appended a suffix to the non-hrss version channel names.
  
  
• Giovanni Santostasi: PulsarMon
  Giovanni reported by e-mail that he doesn't yet understand the hanging of PulsarMon and will be at LLO during the weekend to continue debugging.
  
  
• Rauha Rahkola: SuspensionMon
  Rauha is stuying E12 triggers in order to refine his thresholds. During E12 there were thousands of triggers generated, many for the "high" threshold setting. KR remarked that the high-threshold triggers should rarely be generated, since those are supposed to tell us about optics having gone haywire. Rauha agreed and will try to finalize the settings by next week. He mentioned that he doesn't yet understand the apparent slow memory leak found by John in the fall, but it appears benign enough that the program could probably run throughout S4 without needing a restart.
  
  
• Duncan Brown: InspiralMon
  Duncan ran InspiralMon successfully during the latter part of E12 and expects it to be running at the start of S4. He will be at LHO the first week of the run for scimon shifts and will finish ironing things out then, including online documentation for scimons. John will be incorporating InspiralMon into the DMT process manager lineup next week.
  

• Next detchar telecon: Friday February 18 at 1:30 p.m. EST (S4 preparations and DMT software)