I used TrackHeed::TraansportDeltaElectron() to simulated many delta electrons, but after I simulated all particles and try to save them (didn’t use Garfield++ here) I got error:
void AtomPhotoAbsCS::remove_shell(int nshell): ERROR:
nshell< 0 ||nshell>= qshell
nshell=90155568
FunNameStack: s_init=1 qname=1
0 void AtomPhotoAbsCS::remove_shell(int nshell)
File is /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/GARFIELD/garfield_5.0/Heed/heed++/code/PhotoAbsCS.cpp , line number is 625
spexit_action: the streams will be now flushed
spexit_action: the abort function is called
my code looks like:
TrackHeed fTrackHeed = new TrackHeed();
for(int I=0; I<10000; ++i){
fTrackHeed->TransportDeltaElectron(xxx);
//extract electrons information here
//save to root file here
}
is this because electrons will keep increasing in the fTrackHeed object? If so how can I flush (or reset) it? Thank you in advance!
I see, I will try to make one, but can you please tell that if the number of clusters will keep increasing if I don’t delete TrackHeed object?
I want to understand what does this error message mean
TrackHeed* fTrack = new TrackHeed();
fTrack->TransportDeltaElectron(x1,y1,z1,t1,e1,dx1,dy1,dz1,num1); //simulate one delta electron
fTrack->TransportDeltaElectron(x2,y2,z2,t2,e2,dx2,dy2,dz2,num2); //simulate another delta electron
and my question is: will num2 = num1 + num_clusters_of_deltaElectron2 because I used the same object pointer?
Thank you, emmmmm…then I have no clue of the error I got. So basically I don’t need to recreate TrackHeed object at all to simulate different particles, is this correct?
Thank you! I just found the error message I showed, it appeared not even the place I used Garfield++ but quite after…maybe this is hard to reproduce, can you please briefly tell what does the error message indicate so that I can check my code?
It’s hard to say; I had a quick look and the function that seems to throw this error is not normally called at all. To debug it further, I would need a minimal working example that reproduces the issue.
Sorry I found it only can be reproduced on my app… but I found something wired:
the app is trying to save some object inherited from Object, the error occurred at the saving process which has nothing to do with Heed…
I used gdb to get stack calling information before abort signal, but seems TClass::GetActualClass() is calling Heed::AtomPhotoAbsCS::remove_shell (#3 and #4 in the debug info) ??? How can this be?
debug info here:
(gdb) bt
#0 0x00007fffec24f387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007fffec250a78 in __GI_abort () at abort.c:90
#2 0x00007ffff546f6e6 in Heed::spexit_action (file=...)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/GARFIELD/garfield_5.0/Heed/wcpplib/util/FunNameStack.cpp:310
#3 0x00007ffff53c24c1 in Heed::AtomPhotoAbsCS::remove_shell (this=0x49f5780, nshell=77551488)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/GARFIELD/garfield_5.0/Heed/heed++/code/PhotoAbsCS.cpp:625
#4 0x00007ffff2e02787 in TClass::GetActualClass (this=this@entry=0xd429a0, object=object@entry=0x49f5780)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/ROOT/root_v6.18.00/core/meta/src/TClass.cxx:2535
#5 0x00007ffff242eb2b in TBufferIO::WriteObjectAny (this=0xd26f120, obj=0x49f5780, ptrClass=0xd429a0, cacheReuse=true)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/ROOT/root_v6.18.00/io/io/src/TBufferIO.cxx:504
#6 0x00007ffff2dc8eed in operator<< <TObject> (obj=0x49f5780, buf=...)
at /group/had/muon/ssun/ICEDUST_master/build_externals/root_v6.18.00/include/TBuffer.h:401
#7 TObjArray::Streamer (this=0x49c82a0, b=...)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/ROOT/root_v6.18.00/core/cont/src/TObjArray.cxx:486
#8 0x00007ffff2427bb4 in Streamer (onfile_class=0x0, b=..., obj=0x49c82a0, this=0xdac4d0)
at /group/had/muon/ssun/ICEDUST_master/build_externals/root_v6.18.00/include/TClass.h:570
#9 TBufferFile::WriteObjectClass (this=0xd26f120, actualObjectStart=0x49c82a0, actualClass=0xdac4d0, cacheReuse=<optimized out>)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/ROOT/root_v6.18.00/io/io/src/TBufferFile.cxx:2552
#10 0x00007ffff242eb63 in TBufferIO::WriteObjectAny (this=0xd26f120, obj=0x49c82a0, ptrClass=0xdac4d0, cacheReuse=true)
at /group/had/muon/ssun/ICEDUST_master/ICEDUST_externals_source_LFS/ROOT/root_v6.18.00/io/io/src/TBufferIO.cxx:522
###########more lines not shown here############
Also I quickly had a look in PhotoAbsCS.cpp, seems nshell is the number of energy level of an atom, but how can I change this value…? I didn’t even use functions from Heed, I only used functions of Garfield::TrackHeed and I believe TrackHeed already extract information from Heed::particle so there should be no information left for Heed::particle
Hello, are you trying to save TrackHeed class through ROOT I/O? If I were you I’d try to comment out every I/O part of your code and see if the problem persists.
You wouldn’t want that anyway, since TrackHeed is a “tool” class, not a “storage” class.
Thank you for the reply, the error occurred when TGeoManager::Write() is called, but this is nothing to do with TrackHeed… I will try to comment out I/O to check the result
This problem is solved by found a mistake of deleting TGeoNode pointer, I mistakenly add delete node; in somewhere and caused node becomes a dangling pointer. But it turns out this is nothing related to Garfield++, but no one knows what happens if there is a dangling pointer in your app…
Anyway, thank you all for sparing your time to help me!