BSMDE 2010 mapping problem and solution

All the details of the mapping problem can be found in this ticket.  This page is a summary of the problem, solution, and the implementation.

During Run 10 a problem with the BSMD mapping was discovered (details here).  It was decided to continue taking data with the 2 fibers swapped for future running, and simply correct the mapping in the DB to reflect the hardware configuration before production.  The mapping for the BSMD phi plane (BSMDP) was corrected (completely swapped 2 fibers in the DB) before produvtion to match the Run 10 hardware configuration, so there were no problems with BSMDP mapping in production. 

Problem:

The correction to the BSMD eta plane (BSMDE) mapping, however, was incomplete and did not swap the 2 fibers in the DB completely.  Ahmed found this mapping problem in "Phase I" of the 200GeV QM production (production series P10ij).  All Run 10 data produced in the P10ih and P10ij production series have this BSMDE mapping issue. 

Solution:

a)  For "Phase II"  of the Run 10 data production in the P10ik production series an updated DBV was used to include the correct mapping  for both the BSMDE and BSMDP planes.  This data should be analyzed as usual, with no need for a patch.

b)  In an effort to recover the data produced with the BSMDE mapping problem (P10ih and P10ij) a patch was included in the SL10k and future libraries to correctly swap the BSMDE channels as an afterburner using StEmcDecoder. 

Implementation:

The implementation of part b) of the solution above is similar to the patch for previous tower mapping problems.  The software patch includes 3 libraries StEmcDecoder, StEmcADCtoEMaker, StEmcRawMaker.

1. StEmcDecoder will use the non-corrected map by default, although it is possible to know the correction that should be applied for each channel using the method
   
   StEmcDecoder::GetSmdBugCorrectionShift(int id_old, int& shift)
   
   where id_old is the non-correct software id and shift is the shift that should be applied to the id. In this case:
   
    id_corrected = id_old + shift
    
2. StBemcRaw (in StEmcRawMaker) was updated with a method
   
   StBemcRaw::smdMapBug(bool)
   
   That enables (true) or disables (false) the on-the-fly correction. The default options are:
   
   for StEmcRawMaker -> false (map correction IS NOT applied for P10ih or P10ij PRODUCTION)
   for StEmcADCtoEMaker ->true (map correction IS applied for USER ANALYSIS of P10ih or P10ij produced MuDsts)
   
   IMPORTANT: If you run your analysis with StEmcADCtoEMaker The StEmcRawHits in StEmcCollection will be automatically have the map FIXED!!!! This is not the case if you use StEmcRawMaker or StMuEmcCollection for analysis.
   

1. muDST data is saved with the non-corrected software id
   
   If you read muDST data directly, without running ADCtoEMaker you need to correct the ids by hand. The following code is an example how to do that correction. You need to use StEmcDecoder to get the correct id
   
   

   //////////////////////////////////////////////////////////////////////////////////////////////////////////
   StEmcDecoder* decoder = new StEmcDecoder(date, time); // date and time correspond to the event timestamp
   StMuEmcCollection* muEmc = muMk->muDst()->muEmcCollection(); // get the MuEmcCollection from muDST
   
   //...................  BSMDE  ....................

   	
   
   nh=muEmc->getNSmdHits(det);
   if(det == BSMDE) {
   	for(Int_t j=0;j<nh;j++)	{
   		StMuEmcHit* hit=muEmc->getSmdHit(j,det);
           	ID = hit->getId();
           	ADC = hit->getAdc();
           	CAP = hit->getCalType();
          		int shift = 0;    
       		decoder->GetSmdBugCorrectionShift(ID,shift);
       		newID = ID + shift;      // newID is correct softID for this hit
   		if(newID < 0) continue;  // mask lost channels
   	
   		// user code starts here
   

   	} }
   //////////////////////////////////////////////////////////////////////////////////////////////////////////
   
   

   
   
2. StEmcCollection (StEvent format) after you run StEmcADCtoEMaker at analysis level is created with correct software id.
   
3. Lost Channels  :  There are 498 strips which are masked by the patch (correct softID returned by decoder is -2e4) because the correct hits for that channel are not saved in the muDst at all, due to the mapping in the DB used during production.
4. Database :  Entries are not yet uploaded for Run 10 BSMD data, but the intention is that they will be uploaded with the correct softId mapping so no patch will be needed to get the DB.

 

 

BTOW map problem and solution

If you are not familiar with the map problem follow this discussion in the emc-list. Basically, bacause of swapped fiber optics or swapped signal cables some of the towers are not in the software_id position they are supposed to be. This corresponds to more or less 100 swaps (most in the west side) that corresponds to about 200 towers.

Some of the swapped towers could be fixed because they originated from swapped signal cables. When the swap happened at fiber optics level they were left as they are because the fibers are difficult to access and are frigile. In this case, and for previous runs, a software patch was made in order to recover the swapped towers.

The list of swapped towers can be found here:

• for 2005 data
• for 2006 data (note that the commented lines correspond to towers that were fixed in hardware)

The software patch is implemented in 3 libraries: StDaqLib (StEmcDecoder), StEmcRawMaker and StEmcADCtoEMaker and the idea is the following

1. for 2006 (and future) data StEmcDecoder will have the correct map and all database and productions will be done correctly. In this case the patch is invisible for the user.
    
2. for 2004/2005 data, because of the large amount of tables in database and because of the many productions that were done, the patch in StEmcDecoder, is turned OFF by default. This was done because changing the database and old productions is too much trouble at this point. In this case, the patch works in the following way:
    
   1. StEmcDecoder will use the non-corrected map by default, although it is possible to know the correction that should be applied for each tower using the method
      
      StEmcDecoder::GetTowerBugCorrectionShift(int id_old, int& shift)
      
      where id_old is the non-correct software id and shift is the shift that should be applied to the id. In this case:
      
       id_corrected = id_old + shift
       
   2. StBemcRaw (in StEmcRawMaker) was updated with a method
      
      StBemcRaw::towerMapBug(bool)
      
      That enables (true) or disables (false) the on-the-fly correction. The default options are:
      
      for StEmcRawMaker -> false (map correction IS NOT applied for PRODUCTION)
      for StEmcADCtoEMaker ->true (map correction IS applied for USER ANALYSIS)
      
      IMPORTANT: If you run your analysis with StEmcADCtoEMaker The StEmcRawHits in StEmcCollection will be automatically have the map FIXED!!!! This is not the case if you use StEmcRawMaker or StMuEmcCollection for analysis.
      
      

1. muDST data is saved with the non-corrected software id
   
   If you read muDST data directly, without running ADCtoEMaker you need to correct the ids by hand. The following code is an example how to do that correction. You need to use StEmcDecoder to get the correct id
   
   

   //////////////////////////////////////////////////////////////////////////////////////////////////////////
   StEmcDecoder* decoder = new StEmcDecoder(date, time); // date and time correspond to the event timestamp
   StMuEmcCollection* emc = muMk->muDst()->muEmcCollection(); // get the MuEmcCollection from muDST
   
   //...................  B T O W   ....................

   for (int idOld = 1; idOld <= 4800 ; idOld++) 
   {
       int rawAdc= emc->getTowerADC(idOld);
       int shift = 0;    
       decoder->GetTowerBugCorrectionShift(idOld,shift);
       idNew = idOld + shift;
   
       // user code starts here
   

   }
   //////////////////////////////////////////////////////////////////////////////////////////////////////////
   
   

2. Database is saved with non-corrected software id
   
3. StEmcCollection (StEvent format) after you run StEmcADCtoEMaker at analysis level is created with correct software id.
   
4. StBemcTables. To enable the tower map bug, use the flag kTRUE in StBemcTables constructor. See examples bellow
   

   // This method returns values for NON-CORRECTED IDs (old ids, as the tables are saved in DB)
   tables = new StBemcTables(); 
   float pedestal, rms;
   tables->getPedestal(BTOW, idOld, 0, pedestal, rms);
   
   // This method returns values for CORRECTED IDs
   tables = new StBemcTables(kTRUE); // Use kTRUE to enable the BTOW map correction in StBemcTables. Default is kFALSE
   float pedestal, rms;
   tables->getPedestal(BTOW, idNew, 0, pedestal, rms);

Marcia's BPRS mapping page

This page was written by Marcia Maria de Moura in January 2005 and ported into Drupal in October 2007

We are interested in determine in which sequence the measurements of the pre-shower "cells" come into the DAQ system.

The path from the detector to the DAQ system is not so trivial. There are many connections and they are all tagged but, sometimes, in order to allow a better assembly of the system, the final sequence in which the data from the cells is sent to DAQ is not an ordinary one.

In order to ilustrate better what is the mapping for the pre-shower, we show the correlation of some connections and also the correlation with the towers.

In figure 1 we show part of the barrel EMC corresponding to three modules. The modules are presented from η=0 to η=1. The coloured boxes are the towers. The four rows correspond to a photomultiplier box (PMB). One PMB corresponds to one entire module plus two halves of neighbor modules on each side of the central one. In the left side of the figure there is the legend for the series of conectors ST1,ST2,ST3 and ST4 for the towers. In the figure it is shown how this connectors are related to the towers.

Figure 1 - Correlation of PMT connectors and towers' positions. For a larger view, click on figure.

In figure 2 we show an example of numbering for towers for the PMB 11W (W stands for west). This numbering is the one used for analysis and we call it software id. By analogy, we aplly the same numbering for the pre-shower cells. For the complete numbering of towers and pre-shower cells, see EMC distribution.

Figure 2 - Example of tower numbering for PMB 11W

In the case of the pre-shower cells, the light is not send to the same photomultiplier tubes as the ones for towers, but to sets of Multi-Anode Photomultipliers (MPMT). There are five sets of MPMT's in each PMB and the conecctors for that are identified by MP1, MP2, MP3 MP4 and MP5. In figure 3 we show the correlation of MPX connections to the pre-shower cells, also for PMB 11W. The distribution looks similar but actually the rows are different from figure 2. In the right side of the figure is indicated which is the correspondence in rows with the figure 2. From Vladimir Petrov we obtained how the MPX connectors are related to some eletronics ids (FEE number, SCA number and SCA channel) which are correlated to the muxwire number. The muxwire number is the one that determines the sequence of data to DAQ. In figure 3 it is shown the muxwire, just below the software id.

From all the eletronics parameters above, the algorythm to associate the software id with the data from DAQ was determined, and is in the StEmcDecoder. In previous attempts. some information about the electronics ids was not updated, which caused to a wrong mapping in the first place. One parameter of the algorythm, an offset (PsdOffset_tmp[40])was wrongly determined. The electronics ids information has been updated and the algorythm has been corrected. In table 1 and 2 we show the values of some parameters for PMB 11W. They are analogous to other PMB's and the only thing that changes is the software id, but the distribution in position is the same. Among the many parameters in table 1 and 2, the updated offset values that are used in the StEmcDecoder are displayed.

Of course there are aditional parameters in the algorythm but there is no meaning in explaining all of it here. For more details, go to StEmcDecoder STAR Computing software guide.

The following image has the power supply number, module, and channel for PMT box 11 on both east and west.