Periodic Sources Session M. Alessandra Papa - Albert Einstein Institute - Golm, Germany The LSC UL group is using all (and only) of the codes that we (GEO) have developed / are developing. Thus for the E7 run the activities of the LSC UL group very much exhaust what we are planning to undertake. Should we have more time, we could do more. Glasgow’s amplitude and frequency demodulation code (R. Dupuis) Birmingham’s binary pulsars template placement code (A. Vecchio) Hough modules now in LAL (A.Sintes) What the plans are for the LSC-UL group activities and discussion / action items (M.A. Papa)
Periodic sources UL group: E7 Data Run targeted sources: Glasgow freq&l. demod code software: Glasgow freq&l. demod code see presentation by Rejan&Graham. AEI demod. code software: AEI demod. code (with or without amplitude mod - not yet sure). G. Mendell has written an LDAS wrapper for it. The input are SFTs and he can now generate SFT-frame files under LDAS. computing resources: Hannford cluster. data: - LIGO data (2 kHz band SFTs, uncalibrated). - Would like to run the same search also on GEO data. The easiest thing to do seems to provide them with reduced data-set (i.e. signal data) so that they can have LDAS produce the SFTs from it. M. Alessandra Papa - Albert Einstein Institute - Golm, Germany
Periodic sources UL group: E7 Data Run area searches: AEI hierarchical search software: AEI hierarchical search. The first version of the driver code is nearly completed. The input are SFTs, currently not frame-file-SFTs but an “easier” format. Will run under CONDOR. computing resources: our Merlin cluster has been designed specifically for this code. However, for the E7 data run we have been granted CPU time on the MEDUSA cluster at UWM. data: will analyze both GEO and LIGO data. LIGO data should be given to us in the time domain. M. Alessandra Papa - Albert Einstein Institute - Golm, Germany
Action Items get AEI frequency and amplitude demodulation code working - very nice test since it will use fake data produced independently of us (T. Creighton). finish driver code and then start “polishing” it: right now a lot of interface routines have been written in a rather crude manner, because they have to be tuned to the real noise. Now is the time to do this. Help needed. data quality issues are essentially data preparation (make the SFTs) issues: in order to produce the SFTs we need continuous stretches of ~ 40min to 1.5 hours of data. Are these stretches too long ? Shorter stretches means longer computing times. should we do some padding in order to allow for short (how short ? < 5% of duration of SFT ?) “out-of-lock” segments ? M. Alessandra Papa - Albert Einstein Institute - Golm, Germany
Action Items / Issues Even if there is data, the quality might be so bad that we should disregard it. How do we define when we should do this ? Proposal: when the variance (integral of the noise spectrum floor) during that time is more than N (3 ?) times the average value in the last M (12 ?) hours. Have to decide what N and M are. It would be useful to have these quantities computed in different frequency bands and stored. line removal is OK, actually useful, as long as only the noise is effectively removed but not a possible signal that might lie beneath. What line removal algorithms of such kind are out there ? how do we exchange data with LIGO ? For CW for E7 run we are talking about roughly GB of signal data. Network (Steve’s done some tests) ? Tapes ? Standard LSC is AIT2 tape. We use a different kind. What do we do ? For the E7 data run a temporary solution may be found. But what do we do in the long run? what is the significance of coincidences with LIGO ? Sensitivities are different: both in terms of absolute numbers and frequency bands. It’s “only” to make a statement about future analysis. Do we agree on this ? M. Alessandra Papa - Albert Einstein Institute - Golm, Germany