Get Error after using TrackHeed::TransportDeltaElectron()

Dear experts

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
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){
  //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!

can you please provide a minimal working example?

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

Let me give some simple example:

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?

No, num1 is the number of electrons produced by the first call to TransportDeltaElectron, num2 is the number of electrons produced by the second call.

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############

Does your object contain anything related to TrackHeed as a class member?

No, I didn’t store any TrackHeed objects in root file, and because TrackHeed is not inherited from TObject I think I won’t be able to do that anyway…

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

To be able to debug this further, I’m afraid you will need to provide a minimal working example that reproduces the problem.

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!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.