DetectorHistogrammer has only one bin, even for the example.conf

Hi everyone,
I seem to have a run hitting problems lately. Maybe it is just late and therefore I am blind, but I cannot get the hit_map or any other from the DetectorHistogrammer producing meaningful output. I am using the “latest” build provided in CVMFS.

I run a minimally modified example.conf:

log_level = "INFO"
log_format = "DEFAULT"
detectors_file = "example_detector.conf"
number_of_events = 10


physics_list = FTFP_BERT_EMY
particle_type = "Pi+"
source_energy = 120GeV
source_position = 33um 66um -500um
source_type = "beam"
beam_size = 10um
beam_direction = 0 0 1
number_of_particles = 1
max_step_length = 1um

model = "mesh"
file_name = "example_electric_field.init"

temperature = 293K
charge_per_step = 100

max_depth_distance = 5um


name = "detector1"
file_name = "example_output"
granularity = 100, 100

name = "detector2"
file_name = "test2"
granularity = 100, 100

# replace by [VisualizationGeant4] to run the visualization
# [VisualizationGeant4] #[Ignore]
# mode = "gui"

# File name of the output file 
file_name = "example_output" 
# Ignore initially deposited charges and propagated carriers: 60
exclude = DepositedCharge, PropagatedCharge

Upon inspection, the modules.root contains all the nice files, but all the histograms have only one bin as shown in the appended image. Due to the granularity of 100, 100 I expect 100x100 bins in this histogram. I also don’t see file_name = "test2" to have any impact and cannot find it in the documentation.
What do I do wrong? Is this not how the Histogrammer works or do I use it wrong?
I highly appreciate any help! Thanks a lot!

Hi @flome

no worries, that’s what the forums are here for… :slight_smile:

As far as I can see, everything seems to work fine, but you are expecting things to happen that are not foreseen:

  • file_name is not a parameter of DetectorHistogrammer (hence the missing documentation) because it always stores its output (the bunch of histograms) in the “main ROOT file” which you configure in the global section of the configuration (via root_file). The reason for this is that the results are not considered “output” to be stored separately but rather debugging and simulation performance plots for checking that everything went fine.
  • The histograms probably have only one bin because you are using the diode detector with only one channel. Hence, a hitmap can only show you this exact pixel. The granularity setting you found affects plots that subdivide this pixel e.g. cluster_size_map (okay, with a single pixel you’ll only find single pixel cluster, so that one’s not particularly useful for you). These plots use additional information (usually the MC particle penetration point) to create histograms of “what happened where” in a single pixel cell.

Does this make sense?


1 Like

Hi @simonspa,
thanks a lot for the quick reply! I figured it out now, thanks to you. I am actually using the “test” detectors in the example above (sorry for the confusion), which has 5 pixels in each dimension. Therefore the x and y axis in the plot have the approriate number of pixels shown. Only the central pixel is hit though, therefore the others do not contain data which I mistook as not beeing there because they do not show “zero” but simply do not show.
Is this a correct observation? I ran this again using a pixelated diode with 10x10 pixels and the output matches my expectation:

From this, I still do not know hot to use the granularity properly though to be honest.

Sorry for the late reply, somehow I missed this post…

The granularity controls histograms which look at properties within single pixel cells, i.e. measurements you would not have access to without reference measurements. One example is the in-pixel cluster size map that draws (within one pixel cell) where you have which cluster size on average. It uses the position of the incident particle (MC truth information). The granularity of this (i.e. into how many bins each pixel cell is divided) is controlled by the granularity parameter.