Crash after GetHadronicInteraction no model found #108
Labels
Comments
|
Hello Naomi,
Is there an easy way to export events a to b from a huge hddm file into a
smaller one?
Yes, here is a snippet of python that illustrates how to do this. It has
not been tested, but you can see the flow. You should change "input.hddm"
and "output.hddm" to your preferred filenames.
import hddm_s
import sys
outf = hddm_s.ostream("output.hddm")
my_first_event=947328
my_last_event=947536
c=0
for ev in hddm_s.istream("input.hddm"):
c += 1
if c >= my_start_event:
outf.write(ev)
if c > my_last_event:
sys.exit(0)
In addition to the input event, you also should save the random number
seeds in order to get the same event simulation to follow. In practice this
is quite difficult to do if you are running in multithreading mode (as you
are) because the random sequence is not (easily) reproducible in that case.
No matter, because the strack trace you posted tells the story. Here is the
interesting bit of that long stack trace. The signal clearly happened in
thread 32, snipped below. The errors about NoModelFound are warnings, which
you can ignore. The crash was in G4VoxelNavigation::ComputeStep(). That
function should not be throwing segfaults! Has anyone else ever seen this?
Might there be a bad memory card in the computer you ran this on? Might it
be running too hot? --Richard
Thread 32 (Thread 0x2ae9d5000700 (LWP 32466)):
#0 0x00000039a2aac86d in waitpid () from /lib64/libc.so.6
#1 0x00000039a2a3e479 in do_system () from /lib64/libc.so.6
#2 0x00000039a2a3e7b0 in system () from /lib64/libc.so.6
#3 0x00002ae99704155a in TUnixSystem::StackTrace() () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:2096
#4 0x00002ae9970436bc in TUnixSystem::DispatchSignals(ESignals) () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:3562
#5 <signal handler called>
#6 G4VoxelNavigation::ComputeStep(CLHEP::Hep3Vector const&,
CLHEP::Hep3Vector const&, double, double&, G4NavigationHistory&,
bool&, CLHEP::Hep3Vector&, bool&, bool&, G4VPhysicalVolume**, int&)
…On Fri, Apr 26, 2019 at 10:58 AM nsjarvis ***@***.***> wrote:
What is the best way to report crashes? I'd like to attach the input data
file but it's 7 GB.
Is there an easy way to export events a to b from a huge hddm file into a
smaller one?
Idk if the 'GetHadronicInteraction: No Model found' incident caused the
crash, but I have not seen this message or a similar stack trace in any
other jobs.
(My job # for this one was 469100 - I might need this later)
The HDGeant4 terminal output ended with this:
G4WT35 > G4EnergyRangeManager:GetHadronicInteraction: counter=1, Ek=0,
Material = Iron, Element = Fe
G4WT35 > *0* low=0, high=25000
G4WT35 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc,
line 131:
G4WT35 > ===> GetHadronicInteraction: No Model found
G4WT17 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
Ek=12.298109649761, Material = leadScint, Element = Lead
G4WT17 > *0* low=12000, high=100000000
G4WT17 > *1* low=6000, high=25000
G4WT17 > *2* low=0, high=8000
G4WT17 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc,
line 131:
G4WT17 > ===> GetHadronicInteraction: No Model found
G4WT38 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
Ek=241.63520889138, Material = leadGlassF800, Element = Silicon
G4WT38 > *0* low=12000, high=100000000
G4WT38 > *1* low=6000, high=25000
G4WT38 > *2* low=0, high=8000
G4WT38 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc,
line 131:
G4WT38 > ===> GetHadronicInteraction: No Model found
and the job log file from the cluster has a lengthy stack trace in it. I
have attached that.
g4_40946_0_25000000.o469100.txt
<https://github.com/JeffersonLab/HDGeant4/files/3121790/g4_40946_0_25000000.o469100.txt>
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#108>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3YKWESZFIUEMEMNTLF4G3PSMKAXANCNFSM4HIWK4FQ>
.
|
|
There was also hddm_cull_events from halld_recon. I assume this still works.
Regards,
-David
-------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist, Thomas Jefferson National Accelerator Facility
Newport News, VA
davidl@jlab.org<mailto:davidl@jlab.org>
(757) 269-5567 W
(757) 746-6697 C
On Apr 26, 2019, at 12:10 PM, Richard Jones <notifications@github.com<mailto:notifications@github.com>> wrote:
Hello Naomi,
Is there an easy way to export events a to b from a huge hddm file into a
smaller one?
Yes, here is a snippet of python that illustrates how to do this. It has
not been tested, but you can see the flow. You should change "input.hddm"
and "output.hddm" to your preferred filenames.
import hddm_s
import sys
outf = hddm_s.ostream("output.hddm")
my_first_event=947328
my_last_event=947536
c=0
for ev in hddm_s.istream("input.hddm"):
c += 1
if c >= my_start_event:
outf.write(ev)
if c > my_last_event:
sys.exit(0)
In addition to the input event, you also should save the random number
seeds in order to get the same event simulation to follow. In practice this
is quite difficult to do if you are running in multithreading mode (as you
are) because the random sequence is not (easily) reproducible in that case.
No matter, because the strack trace you posted tells the story. Here is the
interesting bit of that long stack trace. The signal clearly happened in
thread 32, snipped below. The errors about NoModelFound are warnings, which
you can ignore. The crash was in G4VoxelNavigation::ComputeStep(). That
function should not be throwing segfaults! Has anyone else ever seen this?
Might there be a bad memory card in the computer you ran this on? Might it
be running too hot? --Richard
Thread 32 (Thread 0x2ae9d5000700 (LWP 32466)):
#0 0x00000039a2aac86d in waitpid () from /lib64/libc.so.6
#1 0x00000039a2a3e479 in do_system () from /lib64/libc.so.6
#2 0x00000039a2a3e7b0 in system () from /lib64/libc.so.6
#3 0x00002ae99704155a in TUnixSystem::StackTrace() () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:2096
#4 0x00002ae9970436bc in TUnixSystem::DispatchSignals(ESignals) () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:3562
#5 <signal handler called>
#6 G4VoxelNavigation::ComputeStep(CLHEP::Hep3Vector const&,
CLHEP::Hep3Vector const&, double, double&, G4NavigationHistory&,
bool&, CLHEP::Hep3Vector&, bool&, bool&, G4VPhysicalVolume**, int&)
On Fri, Apr 26, 2019 at 10:58 AM nsjarvis ***@***.******@***.***>> wrote:
What is the best way to report crashes? I'd like to attach the input data
file but it's 7 GB.
Is there an easy way to export events a to b from a huge hddm file into a
smaller one?
Idk if the 'GetHadronicInteraction: No Model found' incident caused the
crash, but I have not seen this message or a similar stack trace in any
other jobs.
(My job # for this one was 469100 - I might need this later)
The HDGeant4 terminal output ended with this:
G4WT35 > G4EnergyRangeManager:GetHadronicInteraction: counter=1, Ek=0,
Material = Iron, Element = Fe
G4WT35 > *0* low=0, high=25000
G4WT35 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc>,
line 131:
G4WT35 > ===> GetHadronicInteraction: No Model found
G4WT17 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
Ek=12.298109649761, Material = leadScint, Element = Lead
G4WT17 > *0* low=12000, high=100000000
G4WT17 > *1* low=6000, high=25000
G4WT17 > *2* low=0, high=8000
G4WT17 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc>,
line 131:
G4WT17 > ===> GetHadronicInteraction: No Model found
G4WT38 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
Ek=241.63520889138, Material = leadGlassF800, Element = Silicon
G4WT38 > *0* low=12000, high=100000000
G4WT38 > *1* low=6000, high=25000
G4WT38 > *2* low=0, high=8000
G4WT38 > In
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc>,
line 131:
G4WT38 > ===> GetHadronicInteraction: No Model found
and the job log file from the cluster has a lengthy stack trace in it. I
have attached that.
g4_40946_0_25000000.o469100.txt
<https://github.com/JeffersonLab/HDGeant4/files/3121790/g4_40946_0_25000000.o469100.txt>
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#108>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3YKWESZFIUEMEMNTLF4G3PSMKAXANCNFSM4HIWK4FQ>
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeffersonLab%2FHDGeant4%2Fissues%2F108%23issuecomment-487112957&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=5h0nVAq8FW%2FwTu7l442uzPq6oVhE7yM1dNUhdtYAZI0%3D&reserved=0>, or mute the thread<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADB6NZOOFA3UQ5CDUIXER5LPSMSNXANCNFSM4HIWK4FQ&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=lb2hu9wbq3XWieL1aPU%2FxJviFdIRzJpuFwNcEuIPVJo%3D&reserved=0>.
|
|
Yes, hddm-cull-events also works, but only for hddm_s type files such as
this, not for rest files. By learning the python interface, you get used to
something much more powerful, including the ability to skip forward using
the skip method, an order of magnitude faster.
-Richard J.
On Fri, Apr 26, 2019 at 12:31 PM David Lawrence <notifications@github.com>
wrote:
…
There was also hddm_cull_events from halld_recon. I assume this still
works.
Regards,
-David
-------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist, Thomas Jefferson National Accelerator Facility
Newport News, VA
***@***.******@***.***>
(757) 269-5567 W
(757) 746-6697 C
On Apr 26, 2019, at 12:10 PM, Richard Jones ***@***.***
***@***.***>> wrote:
Hello Naomi,
Is there an easy way to export events a to b from a huge hddm file into a
> smaller one?
>
Yes, here is a snippet of python that illustrates how to do this. It has
not been tested, but you can see the flow. You should change "input.hddm"
and "output.hddm" to your preferred filenames.
import hddm_s
import sys
outf = hddm_s.ostream("output.hddm")
my_first_event=947328
my_last_event=947536
c=0
for ev in hddm_s.istream("input.hddm"):
c += 1
if c >= my_start_event:
outf.write(ev)
if c > my_last_event:
sys.exit(0)
In addition to the input event, you also should save the random number
seeds in order to get the same event simulation to follow. In practice
this
is quite difficult to do if you are running in multithreading mode (as you
are) because the random sequence is not (easily) reproducible in that
case.
No matter, because the strack trace you posted tells the story. Here is
the
interesting bit of that long stack trace. The signal clearly happened in
thread 32, snipped below. The errors about NoModelFound are warnings,
which
you can ignore. The crash was in G4VoxelNavigation::ComputeStep(). That
function should not be throwing segfaults! Has anyone else ever seen this?
Might there be a bad memory card in the computer you ran this on? Might it
be running too hot? --Richard
Thread 32 (Thread 0x2ae9d5000700 (LWP 32466)):
#0 0x00000039a2aac86d in waitpid () from /lib64/libc.so.6
#1 0x00000039a2a3e479 in do_system () from /lib64/libc.so.6
#2 0x00000039a2a3e7b0 in system () from /lib64/libc.so.6
#3 0x00002ae99704155a in TUnixSystem::StackTrace() () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:2096
#4 0x00002ae9970436bc in TUnixSystem::DispatchSignals(ESignals) () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:3562
#5 <signal handler called>
#6 G4VoxelNavigation::ComputeStep(CLHEP::Hep3Vector const&,
CLHEP::Hep3Vector const&, double, double&, G4NavigationHistory&,
bool&, CLHEP::Hep3Vector&, bool&, bool&, G4VPhysicalVolume**, int&)
On Fri, Apr 26, 2019 at 10:58 AM nsjarvis ***@***.***
***@***.***>> wrote:
> What is the best way to report crashes? I'd like to attach the input
data
> file but it's 7 GB.
> Is there an easy way to export events a to b from a huge hddm file into
a
> smaller one?
>
> Idk if the 'GetHadronicInteraction: No Model found' incident caused the
> crash, but I have not seen this message or a similar stack trace in any
> other jobs.
>
> (My job # for this one was 469100 - I might need this later)
>
> The HDGeant4 terminal output ended with this:
>
> G4WT35 > G4EnergyRangeManager:GetHadronicInteraction: counter=1, Ek=0,
> Material = Iron, Element = Fe
> G4WT35 > *0* low=0, high=25000
> G4WT35 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT35 > ===> GetHadronicInteraction: No Model found
> G4WT17 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
> Ek=12.298109649761, Material = leadScint, Element = Lead
> G4WT17 > *0* low=12000, high=100000000
> G4WT17 > *1* low=6000, high=25000
> G4WT17 > *2* low=0, high=8000
> G4WT17 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT17 > ===> GetHadronicInteraction: No Model found
> G4WT38 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
> Ek=241.63520889138, Material = leadGlassF800, Element = Silicon
> G4WT38 > *0* low=12000, high=100000000
> G4WT38 > *1* low=6000, high=25000
> G4WT38 > *2* low=0, high=8000
> G4WT38 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT38 > ===> GetHadronicInteraction: No Model found
>
> and the job log file from the cluster has a lengthy stack trace in it. I
> have attached that.
>
> g4_40946_0_25000000.o469100.txt
> <
https://github.com/JeffersonLab/HDGeant4/files/3121790/g4_40946_0_25000000.o469100.txt>
>
> .
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#108>, or mute the
thread
> <
https://github.com/notifications/unsubscribe-auth/AB3YKWESZFIUEMEMNTLF4G3PSMKAXANCNFSM4HIWK4FQ>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeffersonLab%2FHDGeant4%2Fissues%2F108%23issuecomment-487112957&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=5h0nVAq8FW%2FwTu7l442uzPq6oVhE7yM1dNUhdtYAZI0%3D&reserved=0>,
or mute the thread<
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADB6NZOOFA3UQ5CDUIXER5LPSMSNXANCNFSM4HIWK4FQ&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=lb2hu9wbq3XWieL1aPU%2FxJviFdIRzJpuFwNcEuIPVJo%3D&reserved=0>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#108 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3YKWCPMYOD5C2Z2EUQDNLPSMU7VANCNFSM4HIWK4FQ>
.
|
|
Thanks for the the python snippet & reminder of hddm_cull_events. I certainly hope there is nothing wrong with one of my favourite cluster nodes. I use it a lot. I just gave it another job to do, will update here if I see anything else strange. |
|
Fair enough. But for completeness, there is a “-r” option in hddm_cull_events that allows it
to work with rest files.
Regards,
-David
-------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist, Thomas Jefferson National Accelerator Facility
Newport News, VA
davidl@jlab.org<mailto:davidl@jlab.org>
(757) 269-5567 W
(757) 746-6697 C
On Apr 26, 2019, at 1:05 PM, Richard Jones <notifications@github.com<mailto:notifications@github.com>> wrote:
Yes, hddm-cull-events also works, but only for hddm_s type files such as
this, not for rest files. By learning the python interface, you get used to
something much more powerful, including the ability to skip forward using
the skip method, an order of magnitude faster.
-Richard J.
On Fri, Apr 26, 2019 at 12:31 PM David Lawrence <notifications@github.com<mailto:notifications@github.com>>
wrote:
There was also hddm_cull_events from halld_recon. I assume this still
works.
Regards,
-David
-------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist, Thomas Jefferson National Accelerator Facility
Newport News, VA
***@***.******@***.******@***.***>
(757) 269-5567 W
(757) 746-6697 C
On Apr 26, 2019, at 12:10 PM, Richard Jones ***@***.******@***.***>
***@***.***>> wrote:
Hello Naomi,
Is there an easy way to export events a to b from a huge hddm file into a
> smaller one?
>
Yes, here is a snippet of python that illustrates how to do this. It has
not been tested, but you can see the flow. You should change "input.hddm"
and "output.hddm" to your preferred filenames.
import hddm_s
import sys
outf = hddm_s.ostream("output.hddm")
my_first_event=947328
my_last_event=947536
c=0
for ev in hddm_s.istream("input.hddm"):
c += 1
if c >= my_start_event:
outf.write(ev)
if c > my_last_event:
sys.exit(0)
In addition to the input event, you also should save the random number
seeds in order to get the same event simulation to follow. In practice
this
is quite difficult to do if you are running in multithreading mode (as you
are) because the random sequence is not (easily) reproducible in that
case.
No matter, because the strack trace you posted tells the story. Here is
the
interesting bit of that long stack trace. The signal clearly happened in
thread 32, snipped below. The errors about NoModelFound are warnings,
which
you can ignore. The crash was in G4VoxelNavigation::ComputeStep(). That
function should not be throwing segfaults! Has anyone else ever seen this?
Might there be a bad memory card in the computer you ran this on? Might it
be running too hot? --Richard
Thread 32 (Thread 0x2ae9d5000700 (LWP 32466)):
#0 0x00000039a2aac86d in waitpid () from /lib64/libc.so.6
#1 0x00000039a2a3e479 in do_system () from /lib64/libc.so.6
#2 0x00000039a2a3e7b0 in system () from /lib64/libc.so.6
#3 0x00002ae99704155a in TUnixSystem::StackTrace() () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:2096
#4 0x00002ae9970436bc in TUnixSystem::DispatchSignals(ESignals) () at
/home/gluex/root/root-6.06.08/core/unix/src/TUnixSystem.cxx:3562
#5 <signal handler called>
#6 G4VoxelNavigation::ComputeStep(CLHEP::Hep3Vector const&,
CLHEP::Hep3Vector const&, double, double&, G4NavigationHistory&,
bool&, CLHEP::Hep3Vector&, bool&, bool&, G4VPhysicalVolume**, int&)
On Fri, Apr 26, 2019 at 10:58 AM nsjarvis ***@***.******@***.***>
***@***.***>> wrote:
> What is the best way to report crashes? I'd like to attach the input
data
> file but it's 7 GB.
> Is there an easy way to export events a to b from a huge hddm file into
a
> smaller one?
>
> Idk if the 'GetHadronicInteraction: No Model found' incident caused the
> crash, but I have not seen this message or a similar stack trace in any
> other jobs.
>
> (My job # for this one was 469100 - I might need this later)
>
> The HDGeant4 terminal output ended with this:
>
> G4WT35 > G4EnergyRangeManager:GetHadronicInteraction: counter=1, Ek=0,
> Material = Iron, Element = Fe
> G4WT35 > *0* low=0, high=25000
> G4WT35 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc><
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT35 > ===> GetHadronicInteraction: No Model found
> G4WT17 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
> Ek=12.298109649761, Material = leadScint, Element = Lead
> G4WT17 > *0* low=12000, high=100000000
> G4WT17 > *1* low=6000, high=25000
> G4WT17 > *2* low=0, high=8000
> G4WT17 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc><
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT17 > ===> GetHadronicInteraction: No Model found
> G4WT38 > G4EnergyRangeManager:GetHadronicInteraction: counter=3,
> Ek=241.63520889138, Material = leadGlassF800, Element = Silicon
> G4WT38 > *0* low=12000, high=100000000
> G4WT38 > *1* low=6000, high=25000
> G4WT38 > *2* low=0, high=8000
> G4WT38 > In
>
/home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc<http://G4EnergyRangeManager.cc><
http://G4EnergyRangeManager.cc>,
> line 131:
> G4WT38 > ===> GetHadronicInteraction: No Model found
>
> and the job log file from the cluster has a lengthy stack trace in it. I
> have attached that.
>
> g4_40946_0_25000000.o469100.txt
> <
https://github.com/JeffersonLab/HDGeant4/files/3121790/g4_40946_0_25000000.o469100.txt>
>
> .
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#108>, or mute the
thread
> <
https://github.com/notifications/unsubscribe-auth/AB3YKWESZFIUEMEMNTLF4G3PSMKAXANCNFSM4HIWK4FQ>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeffersonLab%2FHDGeant4%2Fissues%2F108%23issuecomment-487112957&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=5h0nVAq8FW%2FwTu7l442uzPq6oVhE7yM1dNUhdtYAZI0%3D&reserved=0>,
or mute the thread<
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADB6NZOOFA3UQ5CDUIXER5LPSMSNXANCNFSM4HIWK4FQ&data=02%7C01%7Cdavidl%40jlab.org%7C330c60263ac0453d1dca08d6ca61a48b%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918918069377279&sdata=lb2hu9wbq3XWieL1aPU%2FxJviFdIRzJpuFwNcEuIPVJo%3D&reserved=0>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#108 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3YKWCPMYOD5C2Z2EUQDNLPSMU7VANCNFSM4HIWK4FQ>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeffersonLab%2FHDGeant4%2Fissues%2F108%23issuecomment-487129770&data=02%7C01%7Cdavidl%40jlab.org%7C2cb34a448a3b43a4c99f08d6ca69591e%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918951151527408&sdata=OLPZVjeJT1KFb%2FvsTApmXgZHCizbmRegLe5PtiNLK3M%3D&reserved=0>, or mute the thread<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADB6NZMM4CBDFS27SXB2ZDTPSMY4RANCNFSM4HIWK4FQ&data=02%7C01%7Cdavidl%40jlab.org%7C2cb34a448a3b43a4c99f08d6ca69591e%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636918951151537416&sdata=ZCA6%2F4adH2MTlt692sanQOqxEAGEnzsbvIf9qY%2Fro98%3D&reserved=0>.
|
|
This seems to be a one-off problem, closing. Note that Naomi is running very multi-threaded jobs over large input files, which could be exposing some unusual bugs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the best way to report crashes? I'd like to attach the input data file but it's 7 GB.
Is there an easy way to export events a to b from a huge hddm file into a smaller one?
Idk if the 'GetHadronicInteraction: No Model found' incident caused the crash, but I have not seen this message or a similar stack trace in any other jobs.
(My job # for this one was 469100 - I might need this later)
The HDGeant4 terminal output ended with this:
G4WT35 > G4EnergyRangeManager:GetHadronicInteraction: counter=1, Ek=0, Material = Iron, Element = Fe
G4WT35 > 0 low=0, high=25000
G4WT35 > In /home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc, line 131:
G4WT35 > ===> GetHadronicInteraction: No Model found
G4WT17 > G4EnergyRangeManager:GetHadronicInteraction: counter=3, Ek=12.298109649761, Material = leadScint, Element = Lead
G4WT17 > 0 low=12000, high=100000000
G4WT17 > 1 low=6000, high=25000
G4WT17 > 2 low=0, high=8000
G4WT17 > In /home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc, line 131:
G4WT17 > ===> GetHadronicInteraction: No Model found
G4WT38 > G4EnergyRangeManager:GetHadronicInteraction: counter=3, Ek=241.63520889138, Material = leadGlassF800, Element = Silicon
G4WT38 > 0 low=12000, high=100000000
G4WT38 > 1 low=6000, high=25000
G4WT38 > 2 low=0, high=8000
G4WT38 > In /home/gluex/geant4/geant4.10.02.p02/source/processes/hadronic/management/src/G4EnergyRangeManager.cc, line 131:
G4WT38 > ===> GetHadronicInteraction: No Model found
and the job log file from the cluster has a lengthy stack trace in it. I have attached that.
g4_40946_0_25000000.o469100.txt
.
The text was updated successfully, but these errors were encountered: