| backward endcap time consuming [message #10613] |
Fri, 30 April 2010 13:29  |
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  |
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
|
|
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
