TRestG4Event convert to TRestHitsEvent failed when the file the too large

RESTFramework
1

REST version : v2.2.11 (Write here the result of “rest-config --version”).
REST commit : abcd1234 (Write here the result of “rest-config --commit”).

Hello every,
I met some question when I convert the TRestG4Event to TRestHitsEvent use the TRestG4toHitsProcess.
If there only 75000 events it works well to execute it. but when I simluted 560000 event and to convert it to hitsEvent it stop at some place(about 33% ).
and then the screen show the result like this:

DeepinScrot-1427
DeepinScrot-14271819×862 94.3 KB

DeepinScrot-1620
DeepinScrot-16201543×444 61.2 KB

I don’t know how to fix it? is there someone have met this situation before?
thanks for your help in advance!
lujian

2

Yes, I remember running into troubles when producing big files or merging data to a big file.

How big are your Geant4 generated files?

1 Like
3

it almost 74.24GB in G4Event.root. maybe I need change to another pc slight_smile:

4

That’s definitively too high.

What we usually do is to divide a Geant4 Montecarlo in hundreds of files.

Then, we “merge” the data without writing to disk. For example, using a TRestAnalysisPlot definition to produce resulting histograms adding several files.

In the past, in version 2.1.7, we were doing that launching

restPlots --c config.rml --f "Run_mySimulationTag_*.root"

that would list all the files matching the pattern and generate the plots defined in the TRestAnalysisPlot version.

Now, the same is achieved using restManager.

restManager --c config.rml --f "Run_mySimulationTag_*.root"

I imagine, the pattern _*.root is still accepted? @nkx. Please, note that when using patterns we need to introduce the quotes "".

5

We already had also some discussions @lobis, @luzon to produce what could be named TRestSummaryTree or TRestFilteredTree that will allow us to gather several files and generate a summary tree with

  1. the variables chosen,
  2. and the conditions on other variables chosen.

TRestSummaryTree would be a TRestMetadata class allowing to define the variables to be stored, and the conditions to be fulfilled for the entry to be saved. Then, if this object is written to disk we could register also the filtering conditions used.

In this tree we should always store the runNumber, eventId, runTag, etc.