GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » EMC » backward endcap time consuming
backward endcap time consuming [message #10613] Fri, 30 April 2010 13:29 Go to next message
Dmitry Khaneft is currently offline  Dmitry Khaneft
Messages: 75
Registered: January 2009
continuous participant
From: *kph.uni-mainz.de
Dear all,

I met a problem that simulations with my geometry of the EMC backward endcap go quite slow.

I tried different combinations of EMC geometry including very old ascii and one done by Ola and I found out that ascii geometry works much faster than mein or Ola's.

After asking some people what could be wrong I got an answer that problem could because of too complicated ProcessHit function in PndEmc.cxx. It has a lot of if() operators which could cause the problem.

As I understood this function is called each step in simulation for each particle. Thus if it could consume a lot of time in case of electromagnetic shower in EMC.

1. My first question is: where is the code responsible for processing events when ascii geometry is used? I think it should be inside ProcessHit function but I can't identify it. May be I could take a look in and than correct my code correspondingly. Because geometry in all cases should be essentially the same just the size and the position of crystals are different.

Another observation I done shows that in all cases there are error or warning(see below) + one of another kind which appears only in my case. In case of ascii geometry it appears not so often as in Ola's and in Ola's geometry it apperas less than in mine. I think it is the main problem because these warnigs take a lot of time compare to events processing.

2. What are this messages are and what can I do?

P.S. I tried to change max step number to different values up to 30000 but it changes nothing.

This warning appears in all cases and in different cases it gives different coordinates.
>>> Event 5
*** Particle reached max step number (10000). ***
10002      329    -56.7     -663      2.29        0        0      31.3      
cave Transportation
10003      329    -56.7     -663      2.29        0        0      31.3
CrystalVol Transportation
10004      329    -56.7     -663      2.29        0        0      31.3      
cave Transportation
10005      329    -56.7     -663      2.29        0        0      31.3
CrystalVol Transportation
*** Particle reached max step number (10000). ***

*********************************************************************************************************
* G4Track Information:   Particle = gamma,   Track ID = 60,   Parent ID = 59
*********************************************************************************************************


This kind of warnings appear only in my case.
+++++++++++++++++++++++         
No physical volume found at track vertex: (1.08019e+06,753627,-1.92401e+06)
++++  TG4Warning: ++++                                                    
    TG4TrackingAction::UserProcessHits:                              

Cannot locate track verrtex.                                            
+++++++++++++++++++++++

++++  TG4Warning:  ++++
    TG4SpecialControlsV2::SetSwitch:
    No limits defined in BoxVol
+++++++++++++++++++++++


best regards,
Dmitry

[Updated on: Fri, 30 April 2010 16:21]

Report message to a moderator

Re: backward endcap time consuming [message #10614 is a reply to message #10613] Fri, 30 April 2010 13:44 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
From: *fuw.edu.pl
Hi,

In case of ascii geometry the following part of code works in hit processing, which defines the volume where hit took place

401 if (nam.BeginsWith("emc"))
402 {
403 sscanf(nam,"emc%dr%dc%d", &nMod, &nRow, &nCrys);
404
405 // Crys 1-5000; copyNo 1-20; nRow 1-100, nMod 1-6
406 if ((nMod==1) || (nMod==2))
407 id = gMC->CurrentVolOffID(2,copyNo);
408 if ((nMod==3) || (nMod==4)|| (nMod==6))
409 id = gMC->CurrentVolOffID(1,copyNo);
410 // 1 -because the pad stays inside flayer4 (Emc4), so only "1" as inheritance.
411 // In barrel part one pad stays into Emc1 which stays inside Emc12 (and after Emc12 is
412 // copied and rotated -> the inheritance level is "2"
413 }

whereas the lines 126-389 with a lot of if statements works for root geometry.

And after that from line

432 fVolumeID = nMod*100000000 + nRow*1000000 + copyNo*10000 + nCrys;

and code is universal for ascii and root geometry.

Concerning the warning I have no suggestions at the moment.

Best regards,

Dima
Re: backward endcap time consuming [message #10637 is a reply to message #10613] Thu, 06 May 2010 12:04 Go to previous messageGo to next message
Dima Melnychuk is currently offline  Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
first-grade participant
From: *fuw.edu.pl
Hi Dmitry,

It seems that I partially solved the problem with time consumption with EMC endcaps simulation with root geometry.

The following lines of code in PndEmc::ProcessHits() were executed at each hit but results were not used. However these calculation were rather time consuming.

244 Int_t daughtQuar = gMC->NofVolDaughters(namQuar);
245 Int_t daughtSub = gMC->NofVolDaughters(namSub);
246 Int_t daughtBox = gMC->NofVolDaughters(namBox);
247 Int_t daughtCrys = gMC->NofVolDaughters(namCrys);

Equivalent lines of code were for forward endcap also. So I have removed them with rev. 8554. As a results simulations with Geant4, energy=0.7 GeV, theta=155 deg., phi=45 deg. were at least 4 times faster.

To identify the problem I used callgrind profiler.

valgrind --tool=callgrind root.exe sim_emc.C


And the output can be viewed with kcachegrind.

Best regards,

Dima
Re: backward endcap time consuming [message #10665 is a reply to message #10613] Mon, 10 May 2010 10:28 Go to previous message
Dmitry Khaneft is currently offline  Dmitry Khaneft
Messages: 75
Registered: January 2009
continuous participant
From: *gsi.de
Thank you Dima,

it works much faster now.

Actually when there are no warnings it works very fast but sometimes there are a lot of them.

Best regards,
Dmitry

[Updated on: Mon, 10 May 2010 16:27]

Report message to a moderator

Previous Topic: Problem with svn commit
Next Topic: Modification of EMC digitization
Goto Forum:
  


Current Time: Sun Jan 29 00:12:40 CET 2023

Total time taken to generate the page: 0.00991 seconds