Attendance:  Barnes,  Blackburn,  Brown,  Mendell,  Anderson,  Romano,  Finn
and Sylvestre.


Report on overall status of LDAS:
---------------------------------

Kent told us that 0.0.19 has been released.  The main reason was RH 7.1 is on
the machines at LHO and LLO.    The claim is that LDAS now works on RH 6.2 and
RH 7.1.   Not much new functionality.  Some new bugs.  There seems to be a
problem with the job queue again.   They have worked out most of the thread
problem in the datacondAPI.  But there is still something up.  It will run for
an hour or so before it needs to be restarted.  They also have a problem
running jobs in parallel through the wrapperAPI.  

It will be mid to end of august before they have test back to work on.    This
means that dev is the only system for testing purposes.  This will make it
difficult for them to support external development of software with the LSC.

On the RH7.1 versus RH6.2 issue,   he suggested that everybody outside the lab
sticks with 6.2 until the lab is done with their transition.

Thread safety in the datacondAPI needs the latest gcc.  They will migrate
/ldcg to gcc 3.x.x in mide August.  At that time,  /ldcg will undergo a major
change too.


Questions of functionality needed by the search groups:
------------------------------------------------------

==> Dropouts: cannot be properly dealt with.  This is outside Kent's control
at the present time.  He is waiting for the format of the "quality"
information in the database before he can get the datacondAPI team to properly
work the problem.  There are two plans in place:  frameAPI will piece it
together into chunks in ILWD format, and the datacondAPI will then deal with
it.  Or the frameAPI sends the datacondAPI all the data and lets it query the
database to find out what it good and what is not.     But they need the
pseudo channel, and dont know when they will get that.

==> Overlaps: dealing with overlaps can be done by having a smart driver
script for jobs.  Then one can restart the jobs with the appropriate overlap.
This is very important for many searches.

==> State: datacondAPI will not be able to handle state information.  Sam
pointed out that this can be a problem for filtering,  etc.  IIR needs history
to make things continuous.  WrapperAPI fully supports state information.

==> Spectra:  frequency series structure can cause some problems with this.
They need to know the conventions asap so that they can test their database
access.   The LDCG needs this information before Aug 24 to be able to test,
etc.  


Reports from developers:
------------------------

==> Stochastic:  Warren reported that he has compiling search code.   He has
not done any real testing yet.  The last piece to fix is the database
definitions.  A long discussion went on about the nature of these tables.
Warren had been working from the DCC document which is out of date.  Kent
pointed him to the ldas web page for the latest version.    One action item
arose:  how will we handle ingestion of data from two instruments via ILWD?
Discussion to occur at the next meeting, see below.

==> Pulsar:  Greg was asked and agreed to use LAL demod to do directed search.
This brought up the discussion of storing spectra needed for this purpose in
the database.  

An issue:  these search codes operate on short time (~ 1 hour) DFT's.  They
get created once,  and then get read back into search code to use over and
over.   Greg wondered how to do this with LDAS.   After considerable
discussion,  it was agreed that the best/fastest access method would be to
build these objects once,  write them as ILWD objects and store them on disk,
then they can be accessed quickly by LDAS since they will be in native format.
This issue will need to be revisited later.

==> tfclusters:  Julien has started to write a shared object.  He is almost
finished the first stage and has been testing using standalone wrapperAPI.  He
wants to be able to look at data that is not in ILWD format soon,  and will
need to use LDAS.  This causes a problem for Kent.  

Kent will not push incomplete versions of LAL and LALWrapper onto their
machines.  They need to be able to run the previous MDC tests.   After a
considerable discussion,  it was agreed that we could push tagged versions
onto LDAS but this would only happen a couple of times a week.  Clearly this
is insufficient for development purposes.   There is therefore a need to have
instantiations of LDAS outside the Lab.   It was agreed that CIT, MIT, PSU,
UTB and UWM should discuss this.  See action item below.


Action items:
------------

==> Joe and Philip will discuss and report on ways to ingest ILWD with data
from two instruments at the next meeting.

==> Patrick is to circulate an e-mail expounding our need for LSC groups
to run LDAS.


Next meeting:
------------

The next meeting will be at 10:00 PDT on Thursday, 2 August 2001.