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.
The consequences (only for P10ih and P10ij data):

  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.