next-exp/nexus

Geant4 simulation framework of the NEXT Collaboration

nexus's Issues

Set default volume visibility in NEXT-100 geometry

Solving this issue will provide you the hability to identify the structure of the nexus code that builds the geometry of a NEXT detector.

NEXT-100 geometry has a default visibility in nexus as shown below:

The rendering time is very slow because the TPB coating inside the teflon mask holes in the tracking plane is being draw. This issue can be easily solved by modifying the default visibility of this volume to Invisible in the SiPM board geometry code.

With this issue I propose to change the default visibility above to another one that could help to visualice the inner elements of the detector, for example to something like or variant that might be useful for the user

Hint/How-to-start:

To run NEXT-100 default visibility go to nexus directory and run ./bin/nexus -i macros/NEXT100.init.mac (Caution: this macro uses Next100OpticalGeometry instead of Next100, that does not include the external shielding geometry)

You can start modifying the energy plane visibilities, for example, in

nexus/source/geometries/Next100TrackingPlane.cc

Lines 145 to 154 in e3e2925

	if (visibility_) {
	G4VisAttributes copper_brown = CopperBrown();
	copper_plate_logic->SetVisAttributes(copper_brown);
	} else {
	copper_plate_logic->SetVisAttributes(G4VisAttributes::GetInvisible());
	sipm_board_logic ->SetVisAttributes(G4VisAttributes::GetInvisible());
	plug_logic ->SetVisAttributes(G4VisAttributes::GetInvisible());
	}
	}

Scintillation yield in the mesh volumes

Since part of the volumes of the meshes (cathode, gate and anode) are in a region with an electric field defined, the IonizationClustering process occurs. This process expects scintillation optical properties, to generate scintillation photons related to the energy depositions. However, in order to simulate the scintillation correctly in the meshes, we would need to read the scintillation properties from the material they're made of (xenon gas), which is not the case in the current code. Alternatively, we could redefine the cathode, gate and anode positions to exclude these volume entirely.

The discussion is open.

Secondary QE of TPB

Simulate TPB with no wls absorption length in the blue region (TPB emission range) and compare with current simulations. This is to assess how much assuming 0.65 QE for all wavelengths affects light collection.

Photoelectric emission from SS Grids

There is a small probability of photoelectric effect of VUV photons on the SS mesh. This can lead to additional light in the EL region due to additional liberated electrons. NEXUS implements this process as an optional physics process, however, it does not input the PE emission probability.

The following paper from LUX reports a quantum efficiency of 4e-4 on SS304:
https://journals.aps.org/prd/abstract/10.1103/PhysRevD.102.092004

Other measurements from Gonzalo report some other values:
https://next.ific.uv.es/cgi-bin/DocDB/private/ShowDocument?docid=1361

Other interesting reports of the quantum efficiency of TPB are in:
https://arxiv.org/abs/1411.4524
This could also be implemented for future studies.

This is worth adding as a configurable option in the code with all these reported values.

City IC structure

Define the City IC structure

- [] the configuration parameters
- [] data selection algorithm 
- [] map creation algorithm
- [] parameter evolution
- [] define the output parameters
- [] monitoring
- [] tests and validation

ICAROS data preparation

ICAROS data preparation, selection of the Kr events

- [] selection of 1 S1, monitoring and check efficiency
- [] selection of 1 s2, monitoring and check efficiency
- [] selection of S2 vs t-drift  band, monitoring and check

• returns the filtered dst and an masks associated to the different filters
• store information about the filters
• save histograms and counters

bb2nu sims

bb2nu simulations take a very long time to run because the energy threshold applied it is only considered to write the events to the output file, or not; but all the events are simulated.

The energy threshold must be considered before running the simulation.

Geometry testing

The idea is to have a couple of automatic tests:

1. Check that the volumes / masses of all the different volumes in our detectors have the expected value.
2. Check that there are no overlaps between the volumes of a detector.

Random point samplers

The random point sampling classes need a complete overhaul. A few issues that need to be addressed:

• The G4String-based interface is slow. Enums should be used instead.
• The names for the different regions should be unified.
• The geometric definition should probably follow those of the geometry classes. The point samplers could even take a logical/physical volume as input for construction.
• The muon point sampler does not belong there.
• Tests should be written.

The above list is not exhaustive, of course.

New generator with nexus hits as input

Up to date, nexus full simulations can be used for light studies in different geometries.

In the case we wanted to extend the use of full simulations for background studies, it would be necessary to implement a new generator. It would take as input the output hits of a previous nexus fast-simulation, and would generate the corresponding scintillation photons and ionization electrons.

The overall procedure would be:

1. Run a nexus fast-sim storing only those events with energy in the region of interest (Edep>2.4 MeV for instance), therefore discarding the majority of the events.

2. Run nexus full-sim with the new generator, taking as input the output of previous step.

Change default PMT binning?

Full simulation default PMT time binning is 100 ns, instead of the 25 ns which is used in the experiment. Is there any reason for this? If not, I would suggest to change it since it may cause some confusion in the IC processing: you will get 100 ns instead of 25 ns waveforms as you will likely want.

nexus/source/geometries/PmtR11410.cc

Line 49 in 4b3d3d5

binning_(100.*nanosecond)

Review of the temperature-dependent density code

To be able to use the code that calculates the gas density as a function of pressure and temperature, further review is required.

Scintillation yield by particle type

Nowadays the scintillation yield is set by parameter in all our detectors. Although it is a fix number for electrons, in the discussion about NextFlex MR we realized that sometimes that parameter is changed and set to a different value when running special alpha simulations, in which the scintillation yield is modified to accomplish with the quenching factor of heavy particles.

The point is that those simulations in which light and heavy particles play a role (cosmogenic studies, for instance), the scintillation yield considered in our simulations for all of them is the same, being wrong.

I propose to change the scintillation yield from a fix value set by parameter, by a hard-coded "particle-type" basis value.

Grids simulation

Current grids simulations only contemplate 2 possibilities for incoming photons, they are absorbed or transmitted.
Probably, in real life, some of the incident light is reflected.
It would be interesting to include light reflection in our grids.

Ionization energy & Fano Factor of Xenon gas

Currently these values are hard-coded into IonizationClustering.cc

These Xenon Gas properties should be set in OpticalMaterialProperties.cc, and IonizationClustering.cc get them from there. There is commented code ready to do this.

At the same time, we should check that the values set are the most updated ones.

Transparency of photo-etched meshes

The photo-etched meshes that will be installed in NEXT-100 follow a honeycomb arrangement of 5-mm wide cells. Their quoted transparency is ~95%. We should check that our current optical model for the meshes (a dielectric with a certain absorption length) is still correct for these new meshes.

Coding conventions in NEXUS

By Justo @ Gitlab (See discussion on GitLab).

I have noticed a departure lately from the historical coding conventions that we had been following in NEXUS. Some examples include function names mixing CamelCase with underscores or function names using only underscores. We should, perhaps, write some conventions we can all agree with and start enforcing them during the revision of merge requests.

PTFE optical properties update

It must take into account that:

• If the reflectivity is a function of the thickness, do it.
• Study the way to allow photons to be transmitted through the material (needed for teflon masks).

SetELzCoord and GetELzCoord functions from BaseGeometry

These two functions are not general enough to be part of the base class BaseGeometry. On top of that, their use to position a physical volume within its mother results in somewhat obscure code, in my opinion. A simple alternative: providing the origin of coordinates via the constructor as done in the class Next100TrackingPlane(), or via a setter specific to the class that the user has to call necessarily.

Document optical simulation of surfaces TPB+PTFE and TPB+others

Check Refractive Index of Gaseous Xenon

Review argon optical properties

Fix our TrackingActions to allow the visualization of photons and geantinos from the very beginning

Cerenkov emission in GXe

Geant4 simulates the emission of Cerenkov photons in the frequency range in which the refractive index of a material is defined. The intensity of the emission is proportional to the frequency (i.e. inversely proportional to the wavelength). In the case of NEXT, electrons in the ROI produce deep UV photons, and the optical properties in that range in NEXUS are not consistently defined. This slows down considerably the simulation of events in the ROI.

We should make sure that optical properties are defined in all cases down to ~150 nm.

Random sampler of arbitrary binned distributions

Several classes in NEXUS make use of ROOT histograms to sample randomly arbitrary binned functions. We should write our own function or class that provides this functionality in order to remove, as planned, the dependency on ROOT.

Add optical properties of liquid argon to nexus

Implemented already somewhere else: https://github.com/jmalbos/G4OpSim/blob/2f8ffaf00b9a9c4c1a1a9e2611c4e0ffc8b1cd43/src/OpticalMaterialProperties.cpp#L39

Implement the new Hamamatsu SiPMs (1.3 mm × 1.3 mm) that will be used in NEXT-100

NEXT-100 will make use of new Hamamatsu SiPMs of $1.3 \times 1.3~\mathrm{mm}^2$ active area. Their geometry and optical properties have to be added to NEXUS.

Data-sheet with their description:
K30-I50426_specification_sheet_S13372-1350TE_.pdf

material TPB in OpticalMaterialProperties.cc not conserving energy

when simulating a TPB in nexus, there are some instances where the energy of the incoming UV photon interacting within the TPB is lower than the overall energy of the outgoing photons. So for example, I have one 7.2 eV photon causing the generation of 3 photons with energy ~3 eV. In some cases I can get even 6 photons with energy totaling at ~16 eV from just one 7.2 eV UV primary photon.

FusedSilica and FakeFusedSilica refraction indices not valid

The formula for the refractive indices for FusedSilica and FakeFusedSilica is valid only up to ~10.7 eV. However, the values are calculated in the code up to optPhotMaxE_, which is set to 11.5 eV:

nexus/source/materials/OpticalMaterialProperties.h

Line 88 in 5389016

constexpr G4double optPhotMaxE_ = 11.5 * eV;

Thus, this value:

nexus/source/materials/OpticalMaterialProperties.cc

Line 82 in 5389016

rIndex.push_back(sqrt(n2));

is nan for points above 10.7 eV.

Simulation of 0nubb and physics lists

The simulation of 0nubb events is done through the Decay0Interface generator.
It seems that loading the physics list NexusPhysics as the first list in the macro init file messes up electrons with IonizationElectrons (ie-). The two 0nubb electrons are simulated as ie- which does not loose any energy, resulting in undesired output.

Build fails with Geant4 10.7

Geant4 10.7: https://geant4.web.cern.ch/node/1914

Create high resolution images of nexus simulation

The DAWN visualization driver creates vectorized .eps files from visualization, which are suitable for publications and presentations. We should study how to add this visualization option to our simulation.

Compilation error with gcc 12.2.0

I recently updated my gcc compiler on Ubuntu to the 12.2.0 version. Now, the compilation fails with these errors:

In file included from source/base/DetectorConstruction.cc:9:
source/base/DetectorConstruction.h:33:22: error: 'std::unique_ptr' has not been declared
...
source/base/DetectorConstruction.h:13:1: note: 'std::unique_ptr' is defined in header '<memory>'; did you forget to '#include <memory>'?
   12 | #include <G4VUserDetectorConstruction.hh>
  +++ |+#include <memory>
   13 | 

and

In file included from source/base/PrimaryGeneration.cc:10:
source/base/PrimaryGeneration.h:32:23: error: 'std::unique_ptr' has not been declared
...
source/base/PrimaryGeneration.h:15:1: note: 'std::unique_ptr' is defined in header '<memory>'; did you forget to '#include <memory>'?
   14 | #include <globals.hh>
  +++ |+#include <memory>

Adding the #include <memory> fixes indeed the issue. Before opening a PR it would be good to have someone verify this independently.

City Tools

Tools and NBs associated with ICAROS

- [] functions to apply the correction on data (Sphronia)
- [] access and display the map data
- [] compare two runs
- [] NB step by step of the Kr calibration 

Crashes due to persistency manager

1. If no persistency manager (PM) is specified in the initialisation macro, NEXUS crashes due to a FatalException. Do we need to enforce the use of a PM? There are plenty of cases in which one is not really needed.

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : NexusApp()
      issued by : [NexusApp]
A persistency manager must be specified.
*** Fatal Exception *** core dump ***
 **** Track information is not available at this moment
 **** Step information is not available at this moment

-------- EEEE -------- G4Exception-END --------- EEEE -------

2. If no output file is specified in the configuration macro, NEXUS crashes at the end of the processing with no hint whatsoever about what has happened. We should check earlier whether the user has provided the filename or use a default.

### CAUGHT SIGNAL: 11 ### address: 0x10,  signal =  SIGSEGV, value =   11, description = segmentation violation. Address not mapped to object.

Add roughness to the PEDOT of the PMT enclosures.

When there is PEDOT in the PMT enclosures the PMTs end up detecting more light than expected.
We have tested a simplified enclosure (TPB,PEDOT,Sapphire) with photons of 2.9 and 7.2eV and different angles of incidence.
Regardless of the angle of incidence, for the PEDOT case there is a maximum refraction angle for the photons, which is 61°. For the NO PEDOT no maximum angle is observed due to the rough surface of the TPB.
This is the reason why in the current NEW simulation more light is observed when the PEDOT is added to the enclosure windows.
To counteract this effect a rough surface should be added to the PEDOT.

front_back_roughness_comp_all_ang.pdf

Check that all relevant material properties have adequate range

We should check that materials meant to be used with either xenon or argon have material properties defined up to argon scintillation energies.
At the same time, materials that see TPB-shifted photons should have their properties defined to cover the full TPB emission spectrum.

Compression of output h5 files

Review the performance of the compression of output h5 files.

Rewriting of DBD generator to eliminate dependency on GSL

The current DBD generator is a line-by-line translation of DECAY0/GENBB (written originally in Fortran) that introduces a dependency on the GSL mathematical library.