From spagnolo@le.infn.it Wed Apr 18 15:26:54 2007 Date: Thu, 22 Mar 2007 11:10:50 +0100 (CET) From: Stefania Spagnolo To: Niels Van Eldik Cc: Stefania Spagnolo , Ketevi Adikle Assamagan , Edward Moyse , Martin Woudstra Subject: RE: idhashes Hi all, I agree with the overall picture: still I would have some corrections to the table... see below: On Thu, 22 Mar 2007, Niels Van Eldik wrote: > Date: Thu, 22 Mar 2007 09:16:25 +0100 > From: Niels Van Eldik > To: Stefania Spagnolo > Cc: Ketevi Adikle Assamagan , > Stefania Spagnolo , > Edward Moyse , > Martin Woudstra > Subject: RE: idhashes > > Hi Stefania, > > No you haven't lost the mail discussion. We continued the discussion at cern. > This afternoon Ketevi, Ed and I will discuss the issue over lunch and > can hopefully come up with a uniform solution for all detectors. > > This is what we have now: > > detEl module collection station > MDT multilayer chamber chamber 1 chamber > RPC module module module BOL 2 modules; BML 4 modules > TGC module module module many modules > CSC chamber-layer chamber-layer chamber-layer 2 chamber-layers > I would say detEl module collection station MDT multilayer chamber chamber 1 chamber (i.e 2multilayers) RPC module module 1set=2modules 1 set/BOX, 2set/BMX (typically) TGC module module module many modules CSC chamber-layer chamber-layer chamber 1 chamber In the above I used: detEl = XxxReadoutElement of MuonGeoModel ---> it represents the geometry description granularity module= definition in the muonTDR (page 56): one or more detector units assembled into a mechanical structure collection= data segmentation set = definition in the muonTDR (page 57): one or more modules station is obvious (corresponds to any AMDB D-block located at a given eta x phi ) The data-collection segmentation (readout driven) has been very well described until now by the id-helpers methods with "module" in their name. > Let me know whether the table is correct. > If so I think it is unavoidable to have two hash-types: > > one for the detector elements, and one for the data collection. perfect ! > > I now also agree to use: > detectorElementHash() > dataCollectionHash() good ! To my understanding all IdHelpers methods referring to "module" should be replicated into the same one with "dataCollection" substituting "module"; The old ones (simonymous) can stay there for a while in order tot to break sharply all the muon sw. detectorElementHash() will be the new ones. > > These indeed seem to be the only unambiguous names that could be used. > > Once we agree on this, I'd propose to add, if needed, new methodes to the > IdHelpers to calculate the hashes. Furthermore I'd like to cache them in the > detector elements. > > These would get two new methods: > > detectorElementHash() > dataCollectionHash() OK. > > In the PrepRawData objects we'd stop caching the hashes, instead they'd get the > hashes from their detector-element. > I'd also propose to add the two function given above to the PrepRawData objects. > We should probably also add them to the RIO_OnTracks for transparenty (the RIO_OnTrack > base-class has a pure virtual IdentifierHash idDE() function which is a bit ambiguous for > the MDTs and ahd caused problems in the past when people assumed the detEl segmentation > and the data collection segmentation was the same). > > Let me know what you think. Perfect, let me know the outcome of your discussion; if there's anything to clarify on the geometry side you (all at cern) might give me a ring ... Cheers, Stefania > > Niels > -----Original Message----- > From: Stefania Spagnolo [mailto:Stefania.Spagnolo@le.infn.it] > Sent: Wed 3/21/2007 6:43 PM > To: Niels Van Eldik > Cc: Ketevi Adikle Assamagan; Stefania Spagnolo; Edward Moyse > Subject: Re: idhashes > > > > Hello all, > did I loose some mail or this discussion stopped here ? > Cheers, > Stefania > > > On Fri, 16 Mar 2007, Stefania Spagnolo wrote: > > > Date: Fri, 16 Mar 2007 02:04:48 +0100 (CET) > > From: Stefania Spagnolo > > To: Niels VAN ELDIK > > Cc: Ketevi A. Assamagan , > > Stefania Spagnolo , > > Edward Moyse > > Subject: Re: idhashes > > > > > > Hi all, > > sorry for not answering earlier: I'll reply to this one, which seems to > > me a good summary of the situation and I'll add what I can do on my > > side... > > > > > > On Thu, 15 Mar 2007, Niels VAN ELDIK wrote: > > > > > Date: Thu, 15 Mar 2007 15:05:35 +0100 (CET) > > > From: Niels VAN ELDIK > > > To: Ketevi A. Assamagan > > > Cc: Stefania Spagnolo , > > > Stefania Spagnolo , > > > Edward Moyse > > > Subject: Re: idhashes > > > > > > On Thu, 15 Mar 2007, Ketevi A. Assamagan wrote: > > > > > > > Niels, > > > > Sure, we can change "mudule" to "station": I have no problem with > > > > that. But that will be a pain for clients, essentially, the entire muon > > > > software and beyond. > > > > > > Is it that bad? I didn't think there were that many clients of the hashes > > > in the muon system... I'll have a look at the implications. > > > > > > > > > > > > For the MDT's a chamber consists out of two multi layers, the situation is > > > > > different for the RPCs. This has lead to quiet some confusion in the past, > > > > > I'd like to have a clearer naming scheme that is compatible with the names > > > > > used by the groups building the detector and the names used in the TDR. > > > > I'll try to give my view on RPC > > > > > > > > > > So, we should define the methods as per technology. For the MDT what is > > > > the difference between a station and a chamber? > > > > > > There is not difference. I guess we should make a list per technology and > > > based on the total decide which names are best. > > > > > > MDT: > > > > > > 1 chamber per station > > > 1 or 2 multilayers per chamber > > > multilayer = detEl > > > PRD collection = chamber > > > > OK, I fully agree > > > > > > > > > > RPC: > > > 2 chamber per station > > > multilayer = chamber > > > chamber = detEl > > > PRD collection = ? > > > > > Consider a typical BML station, it consists of a MDT chamber + 4 RPC > > modules (I'm calling module a single object fully functional and > > indipendent from the others as assembled here in Lecce): 2 are in the > > inner side of the MDT chamber (slightly overalpping in eta), the other two > > at the top (again overlapping in eta). AMDB, in the station description > > lists all 4 individual modules (object name= RPC), as a consequence -but > > also for coherence with the detector construction point of view- > > MuonGeoModel has 4 RpcReadoutElements (delEl) for such a BML. > > The prd in this station will be found in two collections, one for the two > > moodules at doubletR = 1, the other for the two modules at doubletR=2. > > This follows a readout driven approach(different than a detector > > construction view) ! Therefore to summarize in your scheme: > > > > RPC: > > 4 modules per station (typically) > > 2(BMX) or 1(BOX) moduleSet (we -rpc community- don't have a name for it; > > multilayer is not a RPC word) per station > > module = detEl > > PRD collection = moduleSet > > > > you can use the word chamber instead of module, if you like, but the > > important thing is: > > PRD granularity is moduleSet (i.e. stationEta/stationPhi/Tech/doubletR !) > > Geometry granularity is module > > > > > > > TGC: ? > > for TGC I don't know very much the situation from a detector construction > > point of view, but I know that > > > > TGC: > > Many chambers per station > > chamber = detEl > > PRD collection = chamber > > i.e. there's no difference between detector and data collection > > granularity. > > > > > > > > CSC:? > > as for TGC, I don't know the construction details, but, as I > > understood, you already came to the conclusion that > > > > CSC: > > 2 chamber-layers per stations (in a general -non staged- scenario) > > chamber-layer = detEl > > PRD collection = station > > then I don't know (but is not relevant very much) if the CSC community > > calls chamber the set of two chamber-layers or a single chamber-layer > > (maybe I uderstand from Ketevi's mail below that chamber is used as > > synonimous of chamber-layer). > > > > > > Concerning the names for these methods (to be used in MuonIdHelpers and in > > the MuonGeoModel) may I propose the following : > > > > dataCollectionHash() <-stationName/Eta/Phi/Technology (CSC) > > <-stationName/Eta/Phi/Technology (MDT) > > <-stationName/Eta/Phi/Technology/DoubletR (RPC) > > <-stationName/Eta/Phi/Technology (TGC) > > dataCollectionHash would a synominous of the current (MuonIdHelpers) > > moduleHash (which can stay there, for the moment, in order not to break > > client code) > > > > and > > detectorElementHash() <-stationName/Eta/Phi/Technology/ChamberLayer (CSC) > > <-stationName/Eta/Phi/Technology/Multilayer (MDT) > > <-stationName/Eta/Phi/Technology/DoubletR/DoubletZ (RPC) > > <-stationName/Eta/Phi/Technology/ (TGC) > > > > This naming makes clear that we want to logically distinguish the data > > granularity and the detector granularity. > > > > Finally, Ketevi, there's a tricky case for RPC: I said just above that > > > > detectorElementHash() <-stationName/Eta/Phi/Technology/DoubletR/DoubletZ > > > > In a few BMS there are 8 RPC module (BMS6), in some others 7 (BMS5): > > in BMS5 (I'll tell you later where these are in eta and phi) both in > > doubletR 1 and 2 there are 2 separate modules at doublet Z=3 and they have > > to be distinguished by the doubletPhi field. > > Even more complicated case is the BMS6 where, at doubletR 1 there's one > > module at doubletZ=1 and two separate modules at doubletZ 2 which must be > > distinguished by doubletPhi (1 and 2); in doubletR 2, there are > > 1 module at doubletZ 1, 1 at doubletZ 2 and two separate modules (to be > > distinguidhed with doubletPhi) at doubletZ=3. > > > > BMS5 are at station eta +/-2 and station phi 1-5,8 > > BMS6 are at station eta +/-4 and station phi 1-5,8 > > > > I suppose this will be not be extremely easy to handle .... > > > > Let me know if you agree or if you have any objections/remark. > > Cheers, > > Stefania > > > > > > > > > > > I'm sure about the MDTs, Stefania are the RPCs correct like this? > > > > > > Somebody has to fill in the TGC and CSC/ > > > > > > Cheers Niels > > > > > > > > > > > > > > -Ketevi. > > > > > > > > On Thu, 15 Mar 2007, Niels VAN ELDIK wrote: > > > > > > > > > Hi Ketevi, > > > > > > > > > > On Thu, 15 Mar 2007, Ketevi A. Assamagan wrote: > > > > > > > > > > > Hello Niels, > > > > > > > > > > > > Thanks for the information. I also agree that we should get the > > > > > > definition cleared up. At least for the CSC the chamber and the > > > > > > multilayer/detectorElement are the same thing. > > > > > > > > > > > > In all the cases in the MuonIDHelpers, consistently the "Module" > > > > > > refers to the station where the station is identified by > > > > > > StationName/StationEta/StationPhi/Technology. > > > > > > > > > > > > > > > > This sounds reasonable, I just don't really like the name "module", > > > > > station is more intuative. > > > > > > > > > > How would this look like for the RPCs? > > > > > The BML RPCs attached to one MDT form one 'module'? > > > > > And the two RPC 'detectors' are a multilayer? > > > > > > > > > > > A chamber or a multilayer/DetectorElement is identified by > > > > > > > > > > > > > > > > For the MDT's a chamber consists out of two multi layers, the situation is > > > > > different for the RPCs. This has lead to quiet some confusion in the past, > > > > > I'd like to have a clearer naming scheme that is compatible with the names > > > > > used by the groups building the detector and the names used in the TDR. > > > > > > > > > > > > > > > > > > > > > > > > > > StationName/StationEta/StationPhi/Technology/ChamberLayer > > > > > > > > > > > > For instance, in the initial layout, the CSC has only one > > > > > > ChamberLayer. But that will change for the LHC upgrade. > > > > > > > > > > > > > > > > That's why I'd prefer having the two hashes available. They should be used > > > > > in the right context. One is used to look up the detectorElement, the > > > > > other to query the data collections. > > > > > > > > > > > - Yes, I had implemented multilayer identifiers for only the MDT: > > > > > > that was your request. The other technologies did not seem to want it or > > > > > > did not request it, until now. > > > > > > > > > > > > > chamberHash() > > > > > > > detectorElementHash() > > > > > > > > > > > > I would change that to: > > > > > > > > > > > > moduleHash() <- stationName/Eta/Phi/Technology > > > > > > detectorElementHash() <-stationName/Eta/Phi/Technology/ChamberLayer > > > > > > > > > > > > because as I mentioned before "Chamber" and "DetectorElement" mean the > > > > > > same thing for at least the CSC. > > > > > > > > > > > > > > > > I still would prefer to not use 'module' as it is not very intuative. > > > > > I'd prefer chamber/station (maybe station is correcter for the RPC case). > > > > > > > > > > > Do we agree on the above? If yes, we can discuss time scale. > > > > > > Caching the hash is probably a good idea because Identifier -> Hash Id can > > > > > > be time-expensive operation if that is done through binary look ups. > > > > > > Regards, Ketevi. > > > > > > > > > > > > > > > > how much time would it take you to add the hashes? > > > > > The change to MuonGeoModel is very straightforward and would not break any > > > > > client code.... > > > > > > > > > > Regards, niels > > > > > > > > > > > On Thu, 15 Mar 2007, Niels VAN ELDIK wrote: > > > > > > > > > > > > > Here are the IdHelper methods: > > > > > > > > > > > > > > > > > > > > > MdtIdHelper: > > > > > > > > > > > > > > (chamber) > > > > > > > virtual int get_module_hash (const Identifier& id, > > > > > > > IdentifierHash& hash_id ) const; > > > > > > > > > > > > > > (multi layer) > > > > > > > virtual int get_multilayer_hash (const Identifier& id, > > > > > > > IdentifierHash& hash_id ) const; > > > > > > > > > > > > > > RpcIdHelper: > > > > > > > > > > > > > > virtual int get_module_hash (const Identifier& id, > > > > > > > IdentifierHash& hash_id ) const; > > > > > > > > > > > > > > I don't know whether this is chamber of multilayer. > > > > > > > > > > > > > > Ketevi, just to get you up to date: > > > > > > > > > > > > > > We are discussing the possibility of caching the hashes in the readout > > > > > > > element. Currently the detector element only returns identifyHash(). > > > > > > > The name is very confusing, it is for example not clear whether this is a > > > > > > > chamber of multilayer has. Furthermore the identifiable containers are, if > > > > > > > I remember correctly, organized per chamber and not per detectorelement. > > > > > > > Also very confusing but we have to live with that. > > > > > > > > > > > > > > What I proposed is adding two new methods to the readout elements: > > > > > > > > > > > > > > chamberHash() > > > > > > > detectorElementHash() > > > > > > > > > > > > > > The names are selfexplaining. For the MDTs and RPCs they would return a > > > > > > > different hash, for the TGCs and CSCs I'd have to look but I guess they > > > > > > > would be the same. > > > > > > > > > > > > > > The RPC multilayer hash does not seem to be implemented at the moment, it > > > > > > > would have to be added. Could you do so? > > > > > > > If the TGCs or CSCs need a similar treatment, we'd also need the > > > > > > > additional methods in the IdHelpers for them. > > > > > > > > > > > > > > The plan is to use the hashes to speed up persistency and reconstruction. > > > > > > > Currently they are not really use, but this should change in the future. > > > > > > > As such we need quick access to them, storing them in the detElements > > > > > > > would reduce the number of times we'd have to create them and keep them in > > > > > > > memory. In the current scheme they are stored in the PrepData objects... > > > > > > > > > > > > > > Let me know what you think? > > > > > > > > > > > > > > Cheers Niels > > > > > > > > > > > > > > On Thu, 15 Mar 2007, Stefania Spagnolo wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Niels, > > > > > > > > that's fine - it would be good to discuss with Ketevi also the possibility > > > > > > > > to have this feature enabled for RPC, so that also access to RPC can be > > > > > > > > done in a quicker way using hashes ... anyway: how do you compute the hash > > > > > > > > for the mdt multilayer ? > > > > > > > > Should this new features been collected for 13.0.0 ? > > > > > > > > Stefania > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 15 Mar 2007, Niels VAN ELDIK wrote: > > > > > > > > > > > > > > > > > Date: Thu, 15 Mar 2007 10:26:27 +0100 (CET) > > > > > > > > > From: Niels VAN ELDIK > > > > > > > > > To: Stefania Spagnolo > > > > > > > > > Cc: Stefania Spagnolo , > > > > > > > > > Edward Moyse > > > > > > > > > Subject: Re: idhashes > > > > > > > > > > > > > > > > > > Hi Stefania, > > > > > > > > > > > > > > > > > > On my request Ketevi extended that hashes so we have both chamber and > > > > > > > > > multilayer hashes. > > > > > > > > > > > > > > > > > > I'd say that we, for now at least would keep the identifyHash() method and > > > > > > > > > add two new methods: > > > > > > > > > > > > > > > > > > chamberHash() > > > > > > > > > > > > > > > > > > detectorElementHash() > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > Niels > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 15 Mar 2007, Stefania Spagnolo wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Niels, > > > > > > > > > > > > > > > > > > > > On Wed, 14 Mar 2007, Niels VAN ELDIK wrote: > > > > > > > > > > > > > > > > > > > > > Date: Wed, 14 Mar 2007 19:24:54 +0100 (CET) > > > > > > > > > > > From: Niels VAN ELDIK > > > > > > > > > > > To: Stefania Spagnolo > > > > > > > > > > > Cc: Stefania Spagnolo , > > > > > > > > > > > Edward Moyse > > > > > > > > > > > Subject: Re: idhashes > > > > > > > > > > > > > > > > > > > > > > hi stephania, > > > > > > > > > > > > > > > > > > > > > > I've seen the IdentifierHash identifyHash() method. I'm just not very > > > > > > > > > > > happy with the name, > > > > > > > > > > what name would you propose ? > > > > > > > > > > > > > > > > > > > > > plus I think there is a use-case for having access to > > > > > > > > > > > both chamber and multilayer hashes. > > > > > > > > > > here, I must say, I'm surprised: I though that identifierhash can be > > > > > > > > > > associated only to chambers, isn't this true ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For example in the mdt calibration we'll be using the multilayer hash. > > > > > > > > > > as I said, I'm surprised this is possible ... how would you calculate it ? > > > > > > > > > > > > > > > > > > > > > In the MdtCalibrationSvc I calculate the hash everytime a hit is > > > > > > > > > > > calibrated. If I'd be able to access it without recreation, I'd be able to > > > > > > > > > > > speed up the calibration. This seems feasable if the hashes are available > > > > > > > > > > > from the DetEl. > > > > > > > > > > > For persistency we need the chamber hash, I also could imagine that it > > > > > > > > > > > would be very usefull to have in reconstruction if one for example wants > > > > > > > > > > > to redo hit association. > > > > > > > > > > > > > > > > > > > > > > I'd propose to add the two methods to the MuonReadoutElement, that way > > > > > > > > > > > we'll always have direct access to the hashes. > > > > > > > > > > > > > > > > > > > > I agree if it can be done - it definetly would allow to speed up many > > > > > > > > > > algorithms; > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Stefania > > > > > > > > > > > > > > > > > > > > > > If the two of you agree, I'd like to propose it during the reco meeting > > > > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > > > > > > > Cheers Niels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 14 Mar 2007, Stefania Spagnolo wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Niels, Ed, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 14 Mar 2007, Niels VAN ELDIK wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Date: Wed, 14 Mar 2007 14:42:17 +0100 (CET) > > > > > > > > > > > > > From: Niels VAN ELDIK > > > > > > > > > > > > > To: Stefania Spagnolo > > > > > > > > > > > > > Cc: Edward Moyse > > > > > > > > > > > > > Subject: idhashes > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Stefania, > > > > > > > > > > > > > > > > > > > > > > > > > > Ed and I were discussing the usage of hashes in the muon spectrometer. In > > > > > > > > > > > > > particular for the MuonPrepData there seems to be the need to have access > > > > > > > > > > > > > to the idhashes of the corresponding PrepRawData collections in storegate. > > > > > > > > > > > > > It significantly increases reading in data furthermore it might speed up > > > > > > > > > > > > > reconstruction if we at least provide a hash based infrastructure. > > > > > > > > > > > > > For the MdtCalibration we more or less have it but it should be modified > > > > > > > > > > > > > to really benefit from the hashes. > > > > > > > > > > > > > > > > > > > > > > > > > > Anyway, we were thinking that one could get the hashes from the > > > > > > > > > > > > > readoutelements instead of storing (and recalculating) them in the > > > > > > > > > > > > > MuonPrepData objects. This would save space and time. > > > > > > > > > > > > > The main problem with it is that the readout elements do not cover the > > > > > > > > > > > > > same number of channels as the collections (MdtDetEl = multilayer, Mdt > > > > > > > > > > > > > PRD col = chamber). I don't know how the situation is for other > > > > > > > > > > > > > technologies, but I suspect similar problems at least with the RPCs. > > > > > > > > > > > > Yes, this is true also for RPC, preprawdata collections correspond > > > > > > > > > > > > to fields of the identifier up to doubletR, while an RpcReadoutElement is > > > > > > > > > > > > identified also by doubletZ; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It could be resolved by adding an additional method + member to the > > > > > > > > > > > > > readout element: > > > > > > > > > > > > > > > > > > > > > > > > > > IdentifierHash identifyHash() > > > > > > > > > > > > this already exists, in fact, > > > > > > > > > > > > inline IdentifierHash identifyHash() const; //from MuonReadoutElement > > > > > > > > > > > > (base of all XxxReadoutElement) ... so, even if a XxxReadoutElement does > > > > > > > > > > > > not correspond to a EDM collection, you can ask it for the hash Id of the > > > > > > > > > > > > collection it "belongs to"... > > > > > > > > > > > > > > > > > > > > > > > > would this suite your needs ? ... > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Stefania > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > maybe rename or add: > > > > > > > > > > > > > > > > > > > > > > > > > > IdentifierHash detectorElementHash() > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IdentifierHash chamberHash() (the best I can come up with, suggestion?) > > > > > > > > > > > > > > > > > > > > > > > > > > In the Prepdata objects we'd call these functions. > > > > > > > > > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers Niels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > Stefania Spagnolo > > > > > > > > > > > > Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) > > > > > > > > > > > > INFN Lecce / +39 0832 325128 (fax) > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > Stefania Spagnolo > > > > > > > > > > Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) > > > > > > > > > > INFN Lecce / +39 0832 325128 (fax) > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > Stefania Spagnolo > > > > > > > > Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) > > > > > > > > INFN Lecce / +39 0832 325128 (fax) > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > Stefania Spagnolo > > Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) > > INFN Lecce / +39 0832 325128 (fax) > > ------------------------------------------------------------------------- > > > > > > > > ------------------------------------------------------------------------- > Stefania Spagnolo > Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) > INFN Lecce / +39 0832 325128 (fax) > ------------------------------------------------------------------------- > > > > > ------------------------------------------------------------------------- Stefania Spagnolo Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) INFN Lecce / +39 0832 325128 (fax) -------------------------------------------------------------------------