Suspecting bug in ReadOldDecay0File

[ybedfer]

Hello,
I get a seg. fault in restG4.cc at:

if( restG4Metadata->GetPrimaryGenerator().GetParticleSource(0).GetEnergyDistType() == "TH1D" )

following the reading of a Deacy0-like file in “TRestG4Metadata”.

• I get this w/ a modified version of “TRestG4Metadata::ReadNewDecay0File”. Slightly modified, that is: I simply introduced several new particle IDs, and I modified “TRestParticle” so that each particle has a distinct origin (specified as a “TVector3” data member).
• This modified version has worked… until I git pulled to get version 4061e622, where a number of bugs were fixed in “REST_StringHelper” (bugs that I had also myself independently fixed in the mean time).
• But that version has also a modified Decay0 approach, which I think is bugged. The bug bearing, imho, on “ReadOldDecay0File” (but “ReadNewDecay0File” is probably also affected). What differs in the new source code w.r.t. previous versions (where the method is called “ReadGeneratorFile”) is:

TRestParticleCollection particleCollection;

new becoming a pointer

TRestParticleCollection* particleCollection = TRestParticleCollection::instantiate();

that is push_backed into “TRestG4PrimaryGenerator::particleCollection”. Looks like there is something fishy in that push_back, as if the just push_backed pointer were updated in the next
iteration (over the event entries in the Decay0 file).

I could fix this by instantiating a new “particleCollection” at each iteration, displacing the instantiation source code a few line downward, into w/in the event loop.

Yann

System : Linux
REST version : v2.2.10_dev #70193e6a

[ybedfer]

The hash tag of the bugged version is in fact 70193e6a…

[jgalan]

Hi Yann, thanks for this remark.

Actually I cannot reproduce the segmentation fault with the .dat Decay0 files we have in the repository. I used ‘packages/restG4/example/restG4Template/restG4.rml’. I tested with old and new Decay0 format, for example for new format <source use="Xe136bb2n.dat"/>, and for old format <source use="Xe136bb0n.dat"/>.

Could you please attach a reduced version of the decay0 file you are using.

I think for the moment only electrons and gammas are recognised using a pre-generated file, but we can adapt that. In addition, you may look to the following post, where there was some discussion about this topic. There is a new integration of ‘Decay0’, implemented by @nkx, that allows ‘online’ generation of events using Decay0.

Problem reading Decay0 generator with restG4

System : Linux REST version : v2.2.10 Hi： l used Decay0 to create the events of double-beta decay of Xe136 to excited states of Ba136. So the generated events in .dat program had both of electron and gamma’s information. However, the existing restG4 program could just read out the electron,not the gamma. For example: [image] Xe136bb0n21+.data is the new .dat program l created. And each event had the information of two electron and one gamma. [image] And then when l added the .dat …

[ybedfer]

Hello Javier,

I may have not formulated the problem appropriately enough. The important fact is not the crash
in itself (the latter results from the particular circumstances of my very special Decay0-like file), but instead what I identify as a bug in the uploading of the events via:

TRestG4PrimaryGenerator::AddParticleCollection ( TRestParticleCollection* collection )

where the argument is a pointer to a one and same “TRestParticleCollection” instance, defined
outside of the loop over the successive events:

TRestParticleCollection* particleCollection = TRestParticleCollection::instantiate();
[...]
for (int n = 0; n < fGeneratorEvents && !infile.eof(); n++)
{
    [...]
    {
        [...]        
        particleCollection->AddParticle(particle);
    }
    fPrimaryGenerator.AddParticleCollection(particleCollection);
}

In my understanding, the push_back in “TRestG4PrimaryGenerator::AddParticleCollection” simply pushes the “particleCollection” address over and over again. At each new push_back,
the address contains a different event, but what’s stored is always the one and same pointer,
which contents are updated in the mean time…

What I propose is instead is:

for (int n = 0; n < fGeneratorEvents && !infile.eof(); n++)
{
    TRestParticleCollection* particleCollection = TRestParticleCollection::instantiate();
    [...]
    {
        [...]        
        particleCollection->AddParticle(particle);
    }
    fPrimaryGenerator.AddParticleCollection(particleCollection);
}

Could you check this point w/ the standard "TRestG4Metadata::ReadNewDecay0File? Is it really storing the events as required?

Of course, I can prepare the demonstrator-file that you requested. But if you check the point I
just mentioned supra, and find that the present source code is bugged, that would spare me the effort…

[jgalan]

Ok, I got what you mean. Yes, the error must have appeared at the time that TRestParticleColllection inside TRestPrimaryGenerator was moved to a pointer, as you mention in your first post. This must have happened after I implemented those methods, I remember testing those recently, after the integration.

I tested, and in fact, the resulting spectra was a monochromatic line. After the fix in the following commit with your suggestions the problem seems solved to me.

Sign in