nVeto pulses haven't made following Geant4 file

[mzks]

I found among timing check that WFSim doesn't make nVeto pulse following Geant4 file.
Events which have no nVeto hits in G4, have records_nv and truth_nv

I guess that nVeto events are shifted in somewhere...

WFSim/wfsim/strax_interface.py

Line 134 in 018694b

return channels[hit_mask], timings[hit_mask], np.array(amplitudes, int)

At this line, G4 array is flatten. There may be a bug in chopping the events after that line.
We need to check them carefully.

Rest information I investigated is there.

I used this file and tried to make pulses with very low rate.
/dali/lgrandi/xenonnt/simulations/testing_epix_wfsim/tpc_and_nveto_cryoneutrons_200.root
python v3.7.9 (default, Dec 15 2020, 15:48:53) [Clang 11.0.0 ]
strax v0.16.0 /Users/mzks/.pyenv/versions/3.7.9/lib/python3.7/site-packages/strax
straxen v0.19.2 /Users/mzks/xenon/straxen/straxen
wfsim version:0.5.6
epix version:0.1.1

Scripts:

import strax, straxen, wfsim, epix, nestpy
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import uproot

st = straxen.contexts.xenonnt_simulation()
st.register(wfsim.RawRecordsFromMcChain)
epix_config = {
    'cut_by_eventid': True,         # means that entry_start and entry_stop refer to the original G4 event id
    'debug': True,                  # print runtime outputs
    'source_rate': 0,               # do not alter G4 time of events, because this will be done in WFSim
    'micro_separation_time': 10.,   # ns; default epix separation for clustering decision
    'max_delay': 1e7                # ns; default epix cut for long events (time wrt to first interaction in TPC)
}
epix_config['detector_config_override'] = None
epix_config['micro_separation'] = 0.05
epix_config['tag_cluster_by'] = 'time'

st.set_config(dict(
    detector='XENONnT',
    #fax_file='/Users/mzks/xenon/mc/mc/build/bin/laser_test10_10000.root',
    fax_file='/Users/mzks/xenon/WFSim/bench/tpc_and_nveto_cryoneutrons_200.root',
    event_rate=1.,
    chunk_size=5.,
    entry_start=0,
    #entry_stop=20,
    #fax_config='fax_config_nt_sr0_v0.json',
    fax_config='fax_config_nt_design.json',
    fax_config_override=dict(url_base='https://raw.githubusercontent.com/XENONnT/private_nt_aux_files/master/sim_files',
                             enable_electron_afterpulses=False),
    epix_config=epix_config,
    targets=('tpc',))
)
st.set_config(dict(
    neutron_veto=True,
    fax_config_nveto='fax_config_nt_nveto.json',
    fax_config_override_nveto=dict(enable_noise=False,
                                   enable_pmt_afterpulses=False,
                                   enable_electron_afterpulses=False,
                                   photon_area_distribution='/Users/mzks/xenon/WFSim/bench/private_nt_aux_files/sim_files/XENONnT_spe_distributions_nveto_20210722.txt',
                                   pmt_transit_time_mean=46.0),
    targets=('tpc', 'nveto',),
))

run_id = 'timing_check_01'
rr = st.get_array(run_id, 'raw_records', progress_bar=False)
truth = st.get_array(run_id, 'truth', progress_bar=False)
rr_nv = st.get_array(run_id, 'raw_records_nv', progress_bar=False)
truth_nv = st.get_array(run_id, 'truth_nv', progress_bar=False)

Example:

In Original Geant4 file, event 11, g4_pmthitID[11] have no available ID for nVeto .
[106, 137, 314, 255, ... 276, 489, 438]
All of them are not nVeto ID (2000--2199)
But some records_nv have been observed.

[ramirezdiego]

Hi Keita, I am not sure I understand your example, could you please be a bit more clear?
I see that tpc_and_nveto_cryoneutrons_200.root has, for eventid==11, hits in TPC PMTs. This makes me worry and I would say this is the first think to check on the G4 MC, to discard bugs. You mean that this event has records_nv? So these TPC PMTs are treated as nVeto PMTs?

For the rest, I do not understand the problem. For all the other eventid with nVeto hits, do you see the information after WFSim?

I would start by showing an array of eventid in which there are pmthitID in the nVeto range. Then, check if all these ids are afterwards present in the truth_nv. Could you do that?

[petergaemers]

Hi Keita, what does "some records_nv have been observed mean?

[mzks]

I will show the case g4 ID 11 as an example.

An event 11 in Geant file don't have no nVeto hit but only TPC

As you know, nVeto IDs start in 2000. There are no nVeto ID in this event.
They are TPC ID, but it is not directly problem. We can discard the wrong ID in _read_optical_nveto() in WFSim.

However, WFSim generates raw_records_nv for the event 11. I found the raw_records_nv around the truth_nv['time']
(_rr_nv is the selected raw_records_nv as in Event 11).

For nVeto, WFSim simply makes pulse when it find the photon on the PMT in principle but the IDs are not match. That's the issue.

[petergaemers]

Got it. What do you propose as a solution?

[ramirezdiego]

@petergaemers Didn't we have a cut on the nVeto channels, for this case? I vaguely remember we discussed, but I can't find it from a first glance.
Namely, for the read_optical to be called from the McChain class only considering PMT id's in the nVeto range.

[mzks]

If I would have a proposal, I posted this in Pull-request.

[terliuk]

One small thing, is it only me or photons are sorted by time? i remember that we had issues due to implicit sorting in PMT hit time generation, which was not supposed to be there.

[mzks]

/home/mzks/chain_test/nveto_g4_bug_fix1.ipynb Note on dali

[mzks]

https://xe1t-wiki.lngs.infn.it/doku.php?id=xenon:xenonnt:mc:telecons:210728:nveto_bug_note HTML style

[mzks]

Solved. https://xe1t-wiki.lngs.infn.it/doku.php?id=xenon:xenonnt:dsg:nveto:calibration_design:wfsim_laser_trial1

[mzks]

But before close this issue, I would like to do more careful check. Thank you very much @petergaemers