GSI Forum: Bugs, Fixes, Releases » Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC

Show: Today's Messages :: Polls :: Message Navigator

Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC [message #17933]

Fri, 20 February 2015 17:10

Ermias
Messages: 8
Registered: November 2013
Location: IPN, Orsay

occasional visitor

From: 134.158.197*

Dear all,

While doing simulations on electrons, I noticed a localized efficiency loss for electrons at around theta~22^deg. After
digging around a bit, I was able to pinpoint that it was due to electrons in this location not being associated to *any* cluster,
even though there is a valid reconstructed cluster sitting near the electron's projection. I first started to notice this problem
in oct.14 release. Even though the efficiency drop with oct.14 was localized in a relatively smaller zone (~1degree window),
the effect on the signal I was simulating was significant (~10%) because the electrons for this signal peak around 20^deg in theta.
However with the current development version (26841) the loss in efficiency is striking (see attached figure,
left panel, count of all electrons vs electrons with eid vs. theta ). The efficiency loss is there for positrons too.

I looked at the change in the EMC association code and the only significant change that happened between apr.13 release
and current trunk is the addition of the following conditions before starting the cluster association:

  if ( (emcModule<3) && (helix->GetZ()>150.)  ) continue; // not consider tracks after emc barrel for BARREL
  if ( (emcModule==3) && (helix->GetZ()<165.) ) continue; // consider tracks only from last gem plane for FWD
  if ( (emcModule==4) && (helix->GetZ()>-30.) ) continue; // consider tracks only ending at the back of STT for BKW

at L47 of PndPidEmcInfo.cxx. I assume these lines are there for a reason (would appreciate to hear from
EMC experts why...), but I was able to recover most of the loss in efficiency by commenting them out (right panel).
Could it be that the actual cut values are not correctly set?

What fix do EMC experts suggest? Maybe its a known issue and people are working on it, but for "mass" simulation,
would it be advisable to just go back and patch oct.14 version? or wait until a new release that includes fixes? What
would be the approximate time scale for the next release, if it is okay to ask?

Thanks in advance!

Ermias.

index.php?t=getfile&id=8289&private=0

Attachment: tc.png
(Size: 20.97KB, Downloaded 468 times)

[Updated on: Fri, 20 February 2015 17:12]

Report message to a moderator

Re: Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC [message #17934 is a reply to message #17933]

Fri, 20 February 2015 21:58

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: 93.48.234*

Nobody of EMC has ever worked on the track-EMC correlation, you are asking to the wrong guys.

  if ( (emcModule<3) && (helix->GetZ()>150.)  ) continue; // not consider tracks after emc barrel for BARREL
  if ( (emcModule==3) && (helix->GetZ()<165.) ) continue; // consider tracks only from last gem plane for FWD
  if ( (emcModule==4) && (helix->GetZ()>-30.) ) continue; // consider tracks only ending at the back of STT for BKW

The lines are well commented, and they explain why they were put there. helix is the track parameters at the last point of the track. Since these are geometrical selections, in theory they should work. Which is the EMC module which is suffering from that drop? A check with MC id could help (but you need to use recent trunk since in oct14 the MC for EMC was bugged).

Report message to a moderator

Re: Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC [message #17936 is a reply to message #17934]

Sat, 21 February 2015 00:04

Ermias
Messages: 8
Registered: November 2013
Location: IPN, Orsay

occasional visitor

From: *w92-151.abo.wanadoo.fr

Hi Stefano,

Sorry, I made the wrong assumption about who's working on that part of the code. I didn't mean to offend anyone and I should have known better to check...

For tracks that fail to get associated (emcIndex<0 after the loop over emcHits), I printed out the track MC index, its energy calculated from tracking using pion hypothesis together with the module number and energy of the emcHit with the closest energy to the track.

I only printed out a few hundred events, but It seems like module 3 is contributing to all of the unintended misses in the events I checked. Please let me know if I can provide any other useful feedback...

ps: Do you advise against using oct.14 for any simulation that uses the EMC?

Cheers,
Ermias.


pidCandMcIndex= 0    :   trackEnergy= 0.849534   Module= 3     emcHitEnergy= 0.740053
pidCandMcIndex= 0    :   trackEnergy= 4.03095    Module= 3     emcHitEnergy= 3.51169
pidCandMcIndex= 0    :   trackEnergy= 4.97663    Module= 3     emcHitEnergy= 4.8357
pidCandMcIndex= 0    :   trackEnergy= 3.74218    Module= 3     emcHitEnergy= 3.74057
pidCandMcIndex= 0    :   trackEnergy= 2.5047     Module= 3     emcHitEnergy= 2.40757
pidCandMcIndex= 0    :   trackEnergy= 0.405984   Module= 3     emcHitEnergy= 0.347898
pidCandMcIndex= 0    :   trackEnergy= 1.16359    Module= 3     emcHitEnergy= 1.08486
pidCandMcIndex= 0    :   trackEnergy= 2.81498    Module= 3     emcHitEnergy= 2.69472
pidCandMcIndex= 1084 :   trackEnergy= 0.22849    Module= 3     emcHitEnergy= 0.36478
pidCandMcIndex= 1083 :   trackEnergy= 0.428764   Module= 3     emcHitEnergy= 0.36478
pidCandMcIndex= 0    :   trackEnergy= 2.87692    Module= 3     emcHitEnergy= 2.68255
pidCandMcIndex= 0    :   trackEnergy= 1.8808     Module= 3     emcHitEnergy= 1.69046
pidCandMcIndex= 0    :   trackEnergy= 1.2923     Module= 3     emcHitEnergy= 1.2199
pidCandMcIndex= 0    :   trackEnergy= 3.45425    Module= 3     emcHitEnergy= 3.62943
pidCandMcIndex= 0    :   trackEnergy= 4.53307    Module= 3     emcHitEnergy= 3.92069
pidCandMcIndex= 0    :   trackEnergy= 3.95271    Module= 3     emcHitEnergy= 3.83431
pidCandMcIndex= 0    :   trackEnergy= 2.07854    Module= 3     emcHitEnergy= 3.70188
pidCandMcIndex= 0    :   trackEnergy= 0.840579   Module= 3     emcHitEnergy= 0.816676
pidCandMcIndex= 0    :   trackEnergy= 3.44526    Module= 3     emcHitEnergy= 3.43316
pidCandMcIndex= 0    :   trackEnergy= 4.48627    Module= 3     emcHitEnergy= 4.15238
pidCandMcIndex= 0    :   trackEnergy= 3.05255    Module= 3     emcHitEnergy= 3.01602
pidCandMcIndex= 0    :   trackEnergy= 1.46736    Module= 3     emcHitEnergy= 0.845704
pidCandMcIndex= 0    :   trackEnergy= 1.70518    Module= 3     emcHitEnergy= 1.62284
pidCandMcIndex= 0    :   trackEnergy= 1.37598    Module= 3     emcHitEnergy= 1.33291
pidCandMcIndex= 0    :   trackEnergy= 2.54198    Module= 3     emcHitEnergy= 3.89186
pidCandMcIndex= 0    :   trackEnergy= 4.27216    Module= 3     emcHitEnergy= 4.15942
pidCandMcIndex= 0    :   trackEnergy= 1.54658    Module= 3     emcHitEnergy= 1.48835
pidCandMcIndex= 0    :   trackEnergy= 3.80585    Module= 3     emcHitEnergy= 3.40713
pidCandMcIndex= 0    :   trackEnergy= 3.73259    Module= 3     emcHitEnergy= 3.56458
pidCandMcIndex= 0    :   trackEnergy= 0.898616   Module= 3     emcHitEnergy= 0.949504
pidCandMcIndex= 0    :   trackEnergy= 1.25923    Module= 3     emcHitEnergy= 0.920801
pidCandMcIndex= 0    :   trackEnergy= 0.463938   Module= 3     emcHitEnergy= 0.0957954
pidCandMcIndex= 0    :   trackEnergy= 2.92428    Module= 3     emcHitEnergy= 3.71379
pidCandMcIndex= 0    :   trackEnergy= 0.611837   Module= 3     emcHitEnergy= 0.546316
pidCandMcIndex= 0    :   trackEnergy= 4.05194    Module= 3     emcHitEnergy= 4.24035
pidCandMcIndex= 0    :   trackEnergy= 0.40836    Module= 3     emcHitEnergy= 0.320374
pidCandMcIndex= 349  :   trackEnergy= 0.262772   Module= 3     emcHitEnergy= 0.130423
pidCandMcIndex= 0    :   trackEnergy= 4.78844    Module= 3     emcHitEnergy= 4.82905
pidCandMcIndex= 0    :   trackEnergy= 0.384974   Module= 3     emcHitEnergy= 0.215389
pidCandMcIndex= 0    :   trackEnergy= 1.66274    Module= 3     emcHitEnergy= 1.65131
pidCandMcIndex= 1    :   trackEnergy= 0.212189   Module= 3     emcHitEnergy= 0.0214177

[Updated on: Sat, 21 February 2015 00:04]

Report message to a moderator

Re: Loss of efficiency for electrons at theta~22^deg, due to association failure in EMC [message #17954 is a reply to message #17936]

Fri, 27 February 2015 12:04

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Oct14 suffers for a problem of MC truth for the neutrals, but apart from this the release is fine.
All the lines you write come from geometrical considerations:

if ( (emcModule<3) && (helix->GetZ()>150.)  ) continue; // not consider tracks after emc barrel for BARREL

If the position of the last hit is in the GEMS then most probably the will not hit the barrel, then skip this correlation

if ( (emcModule==3) && (helix->GetZ()<165.) ) continue; // consider tracks only from last gem plane for FWD

Consider only the tracks with are using the last GEM plane for the propagation to the forward endcap.

if ( (emcModule==4) && (helix->GetZ()>-30.) ) continue; // consider tracks only ending at the back of STT for BKW

If the last hit is not in the negative Z then it will not go to the backward endcap.

In theory, all these conditions make sense. BUT, maybe, if you suffer from a lack of counts for module 3, the 2nd command is somehow wrong, maybe not all the tracks hit the last plane of the GEM (problems in tracking). It could make sense to check the geometry of not GEMs and EMC to see how far we are in this "edge" region of 22°.

Report message to a moderator

Previous Topic:	[FIXED] Error compiling PandaRoot (FairMultiLinkedData_Interface.h)
Next Topic:	New tags of FairSoft (external packages) mar15 and FairRoot (v-15.03)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Fri Nov 22 06:52:43 CET 2024

Total time taken to generate the page: 0.00734 seconds