Subject:
Re: muon digit containers
From:
Steven Goldfarb <Steven.Goldfarb@cern.ch>
Date:
Fri, 16 Nov 2001 15:40:24 +0100
To:
David Adams <dladams@bnl.gov>
CC:
Steven Goldfarb <goldfarb@mail.cern.ch>, Torre Wenaus <torre@wenaus.com>, RD Schaffer <R.D.Schaffer@cern.ch>

David,

Sorry for the lag time.  I was back on the States for our review and am
now catching up slowly with e-mail.

David Adams wrote:


> I have implemented the MDT digit container without persistency. The code
> is committed to CVS and is linked from the design page. I would like to
> start working on the persistency which includes the following:
> 1. reading and writing raw data
> 2. reading zebra
> 3. reading and writing objectivity
> 4. reading and writing root
> My guess is that it would be easiest and most useful to start with
> zebra. What do you think?


Yes.  I think the first task should be to be able to read in the
Physics TDR data (via Zebra) in the same manner it is done for the existing
model.  That way, we can compare the two models with the same data.

I intend to soon make a complete copy of (at least a large portion of) the
TDR data in an Objectivity federation.  But, a little debugging remains.
Following that, we can make the comparison using the same Objy source.


> In any case, I understand that I will need to add a converter. Where
> should we put this code? I see many possibilities:
> 1. the MuonDigitContainer package
> 2. a separate package for each persistency type holding converters
> for all muon digit containers (MuonDigitContainerCnvZebra)
> 3. a combined package holding muon digit converters for all
> persistency types (MuonDigitContainerCnv)
> 4. a separate package for each persistency type holding all muon
> converters (MuonCnvZebra)
> 5. a combined package holding all muon converters for all
> persistency types (MuonCnv)
> I think it is sensible to separate persistency types leaving options 2
> and 4. The former minimizes dependencies but the latter reduces the
> total number of packages. I am inclined to favor option 2 but I will put
> the code wherever you feel is appropriate.


In the existing model, we have placed the Objy DDL in separate packages
(MuonEventObjyDDL and MuonDetDescrObjyDDL).  These evolve separately
from the C++ software and, for technical reasons, are better off in their
own packages.  We were considering placing the convertors (your option 2
above) in a separate package, as well, but RD suggested this may not be
the way to go.  I will CC him here to ask his recommendation.  In my
opinion, option 2 makes the most sense.

Steve

-- ======================================================================== Steven Goldfarb University of Michigan / ATLAS Experiment Address: CERN-EP, 1211 Geneve 23, Suisse CERN Office: Bat 40-3-D08 Phone: +41.22.767.1226 <Steven.Goldfarb@cern.ch> Fax: +41.22.767.8350 <http://home.cern.ch/goldfarb/> ========================================================================