GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Bug in PndEmcMapper class: neighbour lists of PndEmcTwoCoordIndex wrong
Bug in PndEmcMapper class: neighbour lists of PndEmcTwoCoordIndex wrong [message #8830] Mon, 08 June 2009 22:19 Go to previous message
Elwin Dijck
Messages: 16
Registered: June 2009
Location: Groningen, The Netherland...
occasional visitor
From: *mxp.dsl.internl.net
Hello all,

I'm Elwin Dijck, working with PandaRoot for my bachelor's thesis at the KVI in Groningen. I think I found a bug in the PndEmcMapper class, so I'll describe the problem and how it could be fixed.

I wanted to use the neighbour sets of the PndEmcTwoCoordIndex objects stored in the PndEmcMapper class, but found that some of the PndEmcTwoCoordIndex pointers in the set returned by PndEmcTwoCoordIndex::GetNeighbours() are not actually neighbours (though they are close), as the following code would show.

Code


So I looked where these neighbour sets are initialized, which is in the constructor of the PndEmcMapper singleton class. What happens there is basically as follows:
  • First all crystals/coordinates are generated: for every valid detector ID, the corresponding two-coordinate index is generated and a PndEmcTwoCoordIndex object is stored in a std::map, indexed by the detector ID.
  • Then, for every PndEmcTwoCoordIndex in the map, the neighbours are looked up: for each of the eight possible two-coordinate indices of the neighbours, the private function PndEmcMapper::GetDetId() is called to find the detector ID corresponding to the two-coordinate index and this is used to find the neighbouring PndEmcTwoCoordIndex's in the map.

The problem is that the mapping from a detector ID (module, row, copy, crystal) to a two-coordinate index (theta, phi) and vice versa seems to be done inconsistently for the barrel part of the EMC: at line 76 of emc/EmcTools/PndEmcMapper.cxx is the following mapping, which is used during the first step of generating all PndEmcTwoCoordIndex objects:
iPhi=(11-crystal)+(copy-1)*10;
(The same can be found on line 90 (other module of the barrel), line 183 and 197 (MapperVersion 2), line 351 and 365 (MapperVersion 6), line 456 and 470 (MapperVersion 7))

Later in PndEmcMapper::GetDetId() on line 836 and 843, the following conversion back can be found for module 2, which is used during the filling of the neighbour sets of the PndEmcTwoCoordIndex objects:
copy=(iPhi-1)/10+1;
crystal=(iPhi-1)%10+1;

The problem is that in the first case the direction of counting crystal and iPhi are opposite, while in the second case the crystal and iPhi are counted in the same direction. I.e. I think the last line should be crystal = 10 - (iPhi - 1) % 10; to be consistent with the code in the constructor.

This means that the wrong PndEmcTwoCoordIndex's are found as neighbours, but because just the crystal number is inverted which is the innermost index, the found crystals will never be off by more than 10 and only in phi direction. Also, this problem only exists for modules 1 and 2 of the barrel, the indexing of the endcaps is ok as far as I know (haven't checked all MapperVersions).

I don't know which way of indexing the EMC crystals was the intended one, but in both cases it should be easy to fix in either PndEmcMapper::PndEmcMapper() or in PndEmcMapper::GetDetId().

Could someone look into this?

Best regards,
Elwin
 
Read Message
Read Message
Previous Topic: trunk doesnt compile
Next Topic: Problems compiling CADConverter on Ubuntu 9.04
Goto Forum:
  


Current Time: Sat Oct 23 13:07:08 CEST 2021

Total time taken to generate the page: 0.02349 seconds