NOTE: 

in the process G4 hits to rdo the top sequence consists of the following 2 algorithms: 

NameAuditor          INFO About to Enter RPC_Digitizer Execute Method 
NameAuditor          INFO Just Exited RPC_Digitizer Execute Method
in the MuonDigitization package; MuonDigits are structured in data collections 
organized exactly as for the PRD.

NameAuditor          INFO About to Enter RpcDigitToRpcRDO Execute Method
NameAuditor          INFO Just Exited RpcDigitToRpcRDO Execute Method
in MuonCnv/MuonByteStreamCnvTest;
RpcDigitToRpcRDO depends on cabling+idhelper+muongeomodel?+rpcgeometry
in execute: 
1/ RPCsimuData from TrigT1RPCLogic is filled out of the Digits with internal method (fill_RPCdata);
   1a/ fill_RPCdata uses RPCgeometry to convert the identifier of a Digit into a 
       RPCsimuDigit (element of RPCsimuData) by computing a strip_code (lvl1 numbering 
       schema for the rpc strips) and a strip_position; funny enough, MuonGeoModel is used
       here to compute the strip position and correct the Digit time for the time of flight; 
2/ CMAdata from TrigT1RPCLogic are built(via their constructor) with RPCsimuData + cabling;    
3/ RPCbytestream from TrigT1RPCLogic is built(via its constructor) with CMAdata;
4/ RpcByteStreamDecoder from MuonByteStreamCnvTest is intanciated out of 
   RPCbytestream+cabling+idHelper and used to decode the RPCbytestream thus producing 
   a vector of RDO collections (RpcPad)
5/ the RpcPad (holding an identifier [extended not hash]) are added to the container 
   with an hash id cumputed from the extended one with the RpcPadIdHash class 

Later the LVL1 simulation proceed via 
NameAuditor          INFO About to Enter TrigT1RPC Execute Method
NameAuditor          INFO Just Exited TrigT1RPC Execute Method
NameAuditor          INFO About to Enter LVL1TGCTrigger::LVL1TGCTrigger Execute Method
NameAuditor          INFO Just Exited LVL1TGCTrigger::LVL1TGCTrigger Execute Method
NameAuditor          INFO About to Enter L1Muctpi Execute Method
NameAuditor          INFO Just Exited L1Muctpi Execute Method
NameAuditor          INFO About to Enter CTPSimulation Execute Method
NameAuditor          INFO Just Exited CTPSimulation Execute Method
NameAuditor          INFO About to Enter RoIBuilder Execute Method
NameAuditor          INFO Just Exited RoIBuilder Execute Method

In TrigT1RPC (execute) the procedure in 1/ and 2/ is executed (code duplication); later SectorLogic 
data are defined and used to fill the RPC data in the muCTPI 
[ctpiInRPC->setSectorLogicData(data_word,0,subsystem,logic_sector);]

It seems like the logic that determines the RPC coincidences for the production of 
cm hits with ijk=6,7 and 0 (in high pt cm) is embedded in the constructor of CMAdata, which 
in practice create CMApatterns; CMApatterns::give_trigger applies the CM majority logic.
This can be easily verified with a small debug session, for example, in the conversion from digits to rdo.
In particular, in the CMAdata constructor RPCdigits (from TrigT1RPClogic) are defined by computing all the 
identifiers, including the eta/phi view; this info is then know and retrieved via a class called RPCdecoder 
in MuonCablings/MuonCablingTools.... In practice I think that the entire logic of the LVL1 might not work 
if the coding of eta/phi in the CM id is changes to agree with the data. One way out can be the following, 
the RPCcabling (unified for data and MC) would know that data and MC have a different coding of eta and phi 
in methods like 

give_strip_id ....
    int logic_sector = SectorId + SubsystemId*32;
    unsigned short int Ixx = CMAId & 1;
    unsigned short int ep  = (CMAId >> 1) & 1;
    unsigned short int lh  = (CMAId >> 2) & 1;
    
    ep = (ep==1)? 0 : 1;

the last line is executed only if data source IS data !!!
This allows the trigger logic to correctly select the logic for eta and phi views, however 
still prd do not match digits... It appears that the corrections (at least for the pivot 
plane) are not applied coherently in digitization and rdo decoding. They certainly have an impact 
in both steps but they do not seem to compensate one for the other.

NOTICE that in muFast an emulation of the LVL1 trigger logic (via LVL1emu::start using RPCTrigFast) 
is done using CMAdata::createPatterns and later CMApatterns::give_trigger

Test on geantinos simulated in Sector5: taking in mind that 
side C dbPhi 1 (i.e. sector 7) and side A dbPhi 2 (i.e. sector 40) are affected by an infamous 
inversion in the numbering convention between MC and DATA. 
PRD match DIGITS after using RPCcabling (the code for Data) both in digitization and in reconstruction 
in all sectors 7,8,39,40 if: 
in CablingRPC  ep = (ep==1)? 0 : 1; is not executed 
in CablingRPC the correction file is not loaded 
Notice that the RDO produced differ from the one obtained by RPCcablingSim 
(checked the printout of CMApatterns)
although the ets/phi cm id schema of the old MC is kept and no miscabling (file of corrections) are used.