Message: RE: Simulation Blocked Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None RE: Simulation Blocked 

Forum: Processes Involving Optical Photons
Re: Question Simulation Blocked (Ibrahim)
Re: Feedback Re: Simulation Blocked (Gumplinger Peter)
Date: 05 Nov, 2010
From: Robert Penny <Robert Penny>

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB7D41.BB129646
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ibrahym,

I hope this is on topic and relevant.

In some optical modeling I was doing Geant was getting stuck.  I'm not =
sure if there was a minor misalignment in my geometry at some surface =
boundaries.  I was using things like polishedbackpainted surfaces and =
such. =20

I never found the bad geometry that caused the problem, if indeed this =
was the cause.  It was only very rare optical photons that did get =
stuck.  To work around the problem, I found where in the Geant code it =
was getting stuck and modified the code to put a safety loop counter.  =
If a photon got stuck for too long it was killed.

There are points in the optical tracking code where Geant has do-while =
loops that rely on something like a G4BooleanRand(theReflectivity) or =
some such thing to jump out.  If there are errors that causes a bad =
normal vector for the optical photon, the G4BooleanRand can be called =
with a value of zero and it never exits.  I'm being a little vague =
because it's been a while since I worked on this problem.  Also, it's =
quite possible (or even likely) to be a completely different problem in =
your case.  However, the fact remains that the Geant code (probably for =
computational efficiency) seems to have places where there are no =
watchdogs.  If a G4BooleanRand is being called to exit a loop, and the =
argument it's called with is zero, it will never leave the loop.

I don't know if you're working in a Unix type environment.  For me I can =
just put a local copy of a source file (such as G4OpBoundaryProcess.cc) =
in my local work directory for the project I'm working on, do any minor =
modifications, then compile and link the project.  The local source file =
will satisfy the link dependencies replace the Geant4 library code at =
link time.  The beauty of doing this is not only that you can safely =
work with a modified copy of a Geant file, but also that you can compile =
it with the debug flags on so you can breakpoint and trace through the =
execution with gdb.  You don't need to recompile the whole Geant library =
with debugging turned on.  When running under gdb, if the code gets =
stuck you should be able to ^C to interrupt execution and do a backtrace =
to find where in the code you're stuck.

In my own case, this little local hack worked.  (I'm only showing =
differences between the 4.9.3 standard file and my own hack.)

rob> diff =
/usr/local/src/geant_src/geant4.9.3/source/processes/optical/src/G4OpBoun=
daryProcess.cc  G4OpBoundaryProcess.cc
76c76
< #include "G4OpBoundaryProcess.hh"
---
> #include "RDP_G4OpBoundaryProcess.hh"
436c436,442
<                     DielectricDielectric();
---
>       // Hack to kill tracks stuck in DielectricDielectric
>       // RDP Thu Apr  8 18:20:01 PDT 2010
>=20
>                     if( DielectricDielectric() =3D=3D -1 )
>       {
>         DoAbsorption();
>       }
764c770
< void G4OpBoundaryProcess::DielectricDielectric()
---
> G4int G4OpBoundaryProcess::DielectricDielectric()
768a775,779
>  G4long loopCntr =3D 0;
>  G4long leapCntr =3D 0;
>=20
>  const G4long loopMax =3D 10000;
>=20
769a781
>    leapCntr++;
774a787,798
>     loopCntr++;
>     if( loopCntr > loopMax ) {
>      G4cout=20
>        << "Killing stuck track in =
G4ObBoundaryProcess::DielectricDielectric"
>        << G4endl
>        << "leapCntr =3D "   << leapCntr
>        << "  loopCntr =3D " << loopCntr
>        << G4endl;
>=20
>        return -1;
>       =20
>     }
1001a1026
>     return 0; // No error abort

I also had to put my own slightly modified include file in the local =
tree, so I could change the prototype of DielectricDielectric from void =
to G4int to return an error status if I wanted to break out.

rob> diff =
/usr/local/src/geant_src/geant4.9.3/source/processes/optical/include/G4Op=
BoundaryProcess.hh  ../include/RDP_G4OpBoundaryProcess.hh
192c192
<  void DielectricDielectric();
---
>  G4int  DielectricDielectric();


Apart from this, to narrow in on the problem, all of the things that =
Peter said are extremely relevant.  Being able to launch directly into =
the event that gets stuck would help enormously in reproducing the =
problem and debugging it in a timely fashion.

I hope this helps and wasn't just information overload.

-Rob.



-----Original Message-----
From: douglas@slac.stanford.edu on behalf of Gumplinger Peter
Sent: Fri 11/5/2010 3:34 PM
To: opticalphotons-g4hn@slac.stanford.edu
Subject: Re: Simulation Blocked
=20

*** Discussion title: Processes Involving Optical Photons

Hi Ibrahym,

> Does anybody know why?

There isn't much you can do except find out the status of your random
number generator at the beginning of the last event (or somewhere near
before the last event) which is apparently hanging. It would be nice if
I could point you to a document where this is explained for an event far
along in a job's execution, but I can't without spending some time.
Maybe somebody monitoring this Forum, can help. Or you'll have to just
look for this information yourself. Some of our examples store and
retrieve random generator seed information.

In any case, once you have the begin-of-event status you should relaunch
just that one event by seeding the generator and add debug as needed
until you find out where the program is stuck. This should work unless
previous events overwrite execued memory (which they should not). If the
program hangs inside the Geant4 source code, let us know.

Peter

-------------------------------------------------------------
Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or =
unsubscribe) at:=20
http://hypernews.slac.stanford.edu/HyperNews/geant4/get/opticalphotons/35=
0/1.html=20



------_=_NextPart_001_01CB7D41.BB129646
Content-Type: text/html;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7655.4">
<TITLE>RE: Simulation Blocked</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Ibrahym,<BR>
<BR>
I hope this is on topic and relevant.<BR>
<BR>
In some optical modeling I was doing Geant was getting stuck.&nbsp; I'm =
not sure if there was a minor misalignment in my geometry at some =
surface boundaries.&nbsp; I was using things like polishedbackpainted =
surfaces and such.&nbsp;<BR>
<BR>
I never found the bad geometry that caused the problem, if indeed this =
was the cause.&nbsp; It was only very rare optical photons that did get =
stuck.&nbsp; To work around the problem, I found where in the Geant code =
it was getting stuck and modified the code to put a safety loop =
counter.&nbsp; If a photon got stuck for too long it was killed.<BR>
<BR>
There are points in the optical tracking code where Geant has do-while =
loops that rely on something like a G4BooleanRand(theReflectivity) or =
some such thing to jump out.&nbsp; If there are errors that causes a bad =
normal vector for the optical photon, the G4BooleanRand can be called =
with a value of zero and it never exits.&nbsp; I'm being a little vague =
because it's been a while since I worked on this problem.&nbsp; Also, =
it's quite possible (or even likely) to be a completely different =
problem in your case.&nbsp; However, the fact remains that the Geant =
code (probably for computational efficiency) seems to have places where =
there are no watchdogs.&nbsp; If a G4BooleanRand is being called to exit =
a loop, and the argument it's called with is zero, it will never leave =
the loop.<BR>
<BR>
I don't know if you're working in a Unix type environment.&nbsp; For me =
I can just put a local copy of a source file (such as =
G4OpBoundaryProcess.cc) in my local work directory for the project I'm =
working on, do any minor modifications, then compile and link the =
project.&nbsp; The local source file will satisfy the link dependencies =
replace the Geant4 library code at link time.&nbsp; The beauty of doing =
this is not only that you can safely work with a modified copy of a =
Geant file, but also that you can compile it with the debug flags on so =
you can breakpoint and trace through the execution with gdb.&nbsp; You =
don't need to recompile the whole Geant library with debugging turned =
on.&nbsp; When running under gdb, if the code gets stuck you should be =
able to ^C to interrupt execution and do a backtrace to find where in =
the code you're stuck.<BR>
<BR>
In my own case, this little local hack worked.&nbsp; (I'm only showing =
differences between the 4.9.3 standard file and my own hack.)<BR>
<BR>
rob&gt; diff =
/usr/local/src/geant_src/geant4.9.3/source/processes/optical/src/G4OpBoun=
daryProcess.cc&nbsp; G4OpBoundaryProcess.cc<BR>
76c76<BR>
&lt; #include &quot;G4OpBoundaryProcess.hh&quot;<BR>
---<BR>
&gt; #include &quot;RDP_G4OpBoundaryProcess.hh&quot;<BR>
436c436,442<BR>
&lt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DielectricDielectric();<BR>
---<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; // Hack to =
kill tracks stuck in DielectricDielectric<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; // RDP Thu =
Apr&nbsp; 8 18:20:01 PDT 2010<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if( =
DielectricDielectric() =3D=3D -1 )<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DoAbsorption();<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<BR>
764c770<BR>
&lt; void G4OpBoundaryProcess::DielectricDielectric()<BR>
---<BR>
&gt; G4int G4OpBoundaryProcess::DielectricDielectric()<BR>
768a775,779<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; G4long loopCntr =3D 0;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; G4long leapCntr =3D 0;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const G4long loopMax =3D 10000;<BR>
&gt;<BR>
769a781<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; leapCntr++;<BR>
774a787,798<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; loopCntr++;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; if( loopCntr &gt; =
loopMax ) {<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; G4cout<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;&lt; &quot;Killing stuck track in =
G4ObBoundaryProcess::DielectricDielectric&quot;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;&lt; G4endl<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;&lt; &quot;leapCntr =3D &quot;&nbsp;&nbsp; &lt;&lt; leapCntr<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;&lt; &quot;&nbsp; loopCntr =3D &quot; &lt;&lt; loopCntr<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;&lt; G4endl;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
return -1;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; }<BR>
1001a1026<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; return 0; // No error abort<BR>
<BR>
I also had to put my own slightly modified include file in the local =
tree, so I could change the prototype of DielectricDielectric from void =
to G4int to return an error status if I wanted to break out.<BR>
<BR>
rob&gt; diff =
/usr/local/src/geant_src/geant4.9.3/source/processes/optical/include/G4Op=
BoundaryProcess.hh&nbsp; ../include/RDP_G4OpBoundaryProcess.hh<BR>
192c192<BR>
&lt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; void DielectricDielectric();<BR>
---<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; G4int&nbsp; =
DielectricDielectric();<BR>
<BR>
<BR>
Apart from this, to narrow in on the problem, all of the things that =
Peter said are extremely relevant.&nbsp; Being able to launch directly =
into the event that gets stuck would help enormously in reproducing the =
problem and debugging it in a timely fashion.<BR>
<BR>
I hope this helps and wasn't just information overload.<BR>
<BR>
-Rob.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: douglas@slac.stanford.edu on behalf of Gumplinger Peter<BR>
Sent: Fri 11/5/2010 3:34 PM<BR>
To: opticalphotons-g4hn@slac.stanford.edu<BR>
Subject: Re: Simulation Blocked<BR>
<BR>
<BR>
*** Discussion title: Processes Involving Optical Photons<BR>
<BR>
Hi Ibrahym,<BR>
<BR>
&gt; Does anybody know why?<BR>
<BR>
There isn't much you can do except find out the status of your =
random<BR>
number generator at the beginning of the last event (or somewhere =
near<BR>
before the last event) which is apparently hanging. It would be nice =
if<BR>
I could point you to a document where this is explained for an event =
far<BR>
along in a job's execution, but I can't without spending some time.<BR>
Maybe somebody monitoring this Forum, can help. Or you'll have to =
just<BR>
look for this information yourself. Some of our examples store and<BR>
retrieve random generator seed information.<BR>
<BR>
In any case, once you have the begin-of-event status you should =
relaunch<BR>
just that one event by seeding the generator and add debug as needed<BR>
until you find out where the program is stuck. This should work =
unless<BR>
previous events overwrite execued memory (which they should not). If =
the<BR>
program hangs inside the Geant4 source code, let us know.<BR>
<BR>
Peter<BR>
<BR>
-------------------------------------------------------------<BR>
Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or =
unsubscribe) at:<BR>
<A =
HREF=3D"http://hypernews.slac.stanford.edu/HyperNews/geant4/get/opticalph=
otons/350/1.html">http://hypernews.slac.stanford.edu/HyperNews/geant4/get=
/opticalphotons/350/1.html</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CB7D41.BB129646--

 Add Message Add Message
to: "RE: Simulation Blocked"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews