|Message: AnalysisManager root performance for large numbers of ntuples||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I have a problem with the file writing of the AnalysisManager. The simulation contains about 1000 Detectors, for which I want to safe the deposited energy individually. Previously this was done via TFile and TTree in SensitiveDetector. Due to version 4.10 and the conflicts of this solution and the multithreading I decided to let the AnalysisManager handle the root files by storing the data as nTuples. This is implemented just like Example B4c.
The problem is that calling analysisManager->Write() takes very long. For 1500 nTuples with four threads it takes about 30 s real time to write the files for a single event. The required time increases with both, number of events and number of threads. This converges to somewhat 3 s per event with four threads, which bears no relation to the actual simulation time of about 3 ms per event.
Is this an expected/known behaviour for the AnalysisManager for large numbers of nTuples?
Or is there probably something wrong with my approach? (in which case I would provide more information about the actual implementation of course)
Thank you very much for your help and a happy new year,
|Inline Depth:||Outline Depth:||Add message:|