custom times in csv input are ignored

[KaraMelih]

It looks like the custom times are ignored when using a csv instructions
mwe

import pandas as pd 
import cutax

# common folder
# custom_microphysics_instructions = pd.read_csv("/project2/lgrandi/xenonnt/simulations/supernova/sim_instructions/instructions_j4s7nrf3lw_00001.csv")
# custom_dethysics_instructions = pd.read_csv("/project2/lgrandi/xenonnt/simulations/supernova/sim_instructions/instructions_j4s7nrf3lw_00002.csv")

# check the time columns in both, they are int64, ns precision
# custom_microphysics_instructions.head(3)
# custom_dethysics_instructions.head(3)

# on fuse_context branch of cutax
context = cutax.contexts.xenonnt_fuse_full_chain_simulation()
context.set_config(
                {
                    "path": "/project2/lgrandi/xenonnt/simulations/supernova/sim_instructions/",
                    "file_name": "instructions_j4s7nrf3lw_00001.csv",
                    "n_interactions_per_chunk": 250,
                    "source_rate": 0,
                }
            )
mp = context.get_df("00001", "microphysics_summary")

returns all times equal to zeros. Any higher level data are not created because of this time issue.

[ramirezdiego]

"source_rate": 0 looks very suspicious to me 👀

[KaraMelih]

Also, just noticed the difference between the instructed locations and the locations in microphysics summary;
The positions (x, y, z) are 1 order of magnitude lower. i.e. instructed position is x=43.567, position in microphysics summary x=4.355 there is also a difference in the floating points but I guess that might be due to some effects.

[ramirezdiego]

The positions issue could be because the input to fuse should be done in mm (as Geant4 provides the entries) and we then convert it to the cm straxen uses.

[KaraMelih]

Indeed. I was not sure how source_rate behaves, I was under the impression that if times are manually given the source rate should be set to zero.

Aaaand I found the distance unit conversion here okkie dokkie. Thanks! Closing.

[HenningSE]

Hey, I think I found the solution to the problem. Per default fuse was subtracting the time of the first interaction of an event from all following interaction times (of that specific event). This way, for custom instructions with only a single interaction per event, we always get time 0. I opened a draft PR fixing this problem. Maybe you can give it a go and report if this solves the problem.

[HenningSE]

I re-opened the issue as indeed a source_rate of 0 should tell fuse to not touch the input timing.

[ramirezdiego]

Indeed. I was not sure how source_rate behaves, I was under the impression that if times are manually given the source rate should be set to zero.

Hey Melih, this is correct, as Henning pointed out in the open PR. I had missed it. For custom times your source should obviously be zero, hence that's still a bug. Thanks both!

[KaraMelih]

Ah okay. I see, so before, it was normalizing all events so that the first event time is always at zero. And now if source rate is set to zero, it also skips that right?

So; default behaviour: if user passes all zeros, simulates times with the default source rate (), and brings the first event to time equal zero. Correct me if I'm mistaken.

[HenningSE]

Event timing in fuse should work like this:

source_rate > 0:

• fuse will distribute events in time for you.
• The event times will be drawn from a uniform distribution based on the source_rate
• For each event the time of the first interaction of that event is subtracted from all other times in that particular event. Then we add the random times.
• The intention is that from Geant4 simulations all events start from 0 but we can get very large times for the interactions we actually care about. Example: You could simulate a radioactive decay chain in e.g. the cryostat. The first energy deposit that makes it into the TPC could then have a time of a million years or so. This is of course not what we want in most cases.
• If you use this setting with a csv input of single energy deposits per event, all energy deposits can have time 0. fuse will distribute them for you.

source_rate == 0:

• This should only be used with csv input.
• fuse should not mess with the timing.
• The user has to take care that all events are distributed in time like they want and that all interactions of an event have the correct timing.
• If you pass the same csv instructions with all times 0 like in the case above and the source rate set to 0, all energy deposits would be simulated at the same time.

I hope that it makes sense.