wcsim / wcsim Goto Github PK

To simulate a more realistic SK-IV geometry, the acrylic should be added around the PMTs.

We should add a set of validation input files and .mac files so that we can check after updates that things still work properly.

This might be in a separate repository.

This will be needed to complete issue #13 . This needs to be done with issue #37 in mind as the way we implement the readout of multiple PMTs will affect how the pointers should be stored.

Currently this method takes an integer argument. It returns the total p.e. if i = 1; and the position of the first "hit time" related to this WCSimRootCherenkovHit in the hit time array if i = 0.

This is documented in DetectorDocumentation.pdf:

WCSimRootCherenkovHit These hits are records of photons hitting the PMTs
before the digitization step (and associated threshold, etc.). In each trigger
the number of true cherenkov hits is given by GetNcherenkovhits() .

• GetTotalPe(0) - the position in the array of HitTimes
• GetTotalPe(1) - the number of true photons that hit this PMT, which is
  also the number of entries in that list that belong to this PMT

But it can be made clearer in the code itself.

This was brought up by @AlexFinch in pull request #89. Our makefile runs doxygen, but we haven't put doxygen style comments in the code. Ensuring each class and method had a basic description of what it does and what the arguments are would allow us to generate meaningful doxygen documentation.

Currently, behavior such as after-pulsing is not simulated. It might be important for future low-energy studies for Gd etc.

We currently have two macros (novis.mac and vis.mac) which differ only in that one of them has the visualization turned on. We should make a single, simple macro where we can turn on and off the visualization using a command. Thanks to @fdilodov for suggesting this.

After #4 is finalized by @eosullivan then the work from @YujiOkajima can also be incorporated to add the HPDs. This needs to be done in a way that is accessible to both SK and HK and involves adding the new single PE distribution etc. It should be handled like the other tube cases and not with hardcoded 'if' statements.

I was going to change WCPMTGlassThickness to be defined in the newly created src/WCSimPMTObject.cc file. I have noticed that in src/WCSimDetectorConfigs.cc (where the glass thickness is currently defined) that the WCPMTGlassThickness= 0.4 cm for the SK 20" PMTs, but WCPMTGlassThickness= 0.55 cm for the HK 20" PMTs. Is this just a bug or did someone purposely implement this difference for some reason?

Thanks to @wilking and @cvilelasbu for bringing this issue to our attention. Currently, the /WCSim/Construct line is buried after a bunch of detector configurations, which makes it easy to miss. If a user wishes to change the detector configuration in the macro, but doesn't uncomment out the /WCSim/Construct line, the new detector configuration will not be properly built. We should either find a way of automatically implementing this line if a new detector configuration is called, or at the very least should find a way to make this line more visible.

After working with WCSim for a couple of months, I've just found out that I've not been reading jobOptions.mac, jobOptions2.mac, or tuning_parameters.mac while running WCSim. This is because I've been running WCSim from a directory that isn't the root of the package (i.e. not the one with these files in). I see a few options for rectifying this:

1. If any of these files aren't found, throw a fatal exception.
2. Make it clear in the documentation that WCSim must be run from the root directory, or copies (or soft links) of these files must be present in your running directory (e.g. make it explicit at https://github.com/WCSim/WCSim/wiki/Tutorial:-How-to-set-up-GitHub-%28in-the-context-of-WCSim%29#test-that-your-code-is-working and elsewhere)
3. Add relative paths to WCSim.cc, so that these files are looked for at $WCSIMDIR/jobOptions.mac. Running a simple test on this, it seems that variable expansion must be performed first.
4. Specify the .mac file locations on the command line (with sensible defaults if they're not given).
   I'd suggest doing 1 (so no one has a chance to get burnt again) and either 2 or 3 or 4.

The introduced timing resolution of HPD, which was calculated from sigma and lambda of Exponentially modified Gaussian, seems to be different from that timing resolution analyzed from the measurement result in the low charge region.
I changed the analysis method (make the number of qbin twice as big as past analysis by changing the qbins width, change the fitting target from lambda to 1/lambda) , and analyzed HPD timing resolution again.

1/lambda (new analysis, fitted by 1/(pol1))

sigma (new analysis)

Timing resolution (sqrt(sigma^2+1/lambda^2), blue: old parameters, red: new parameters)

On the other hand, Box and Line PMT seems not to be such a big difference between data and fitted function.
The below figure shows the timing resolution of Box and Line PMT and function which has been introduced in WCSim.

If we want to really simulate SK-IV we need to add parametric OD tube placement for the cylindrical geometries. To make this really work also depends on the issues related to reading out multiple tubes like #37, #38, #39 .

Currently, only the Hyper-K egg geometry has OD tubes. They are manually placed and non-electronically active now.

This is a bug that was discovered by Debra Dewhurst. The digitizer threshold is implemented before the PMT threshold, which leads to some events in the final digitized collection with less hits than the digitizer threshold. This is an issue only for low energy events. To solve this, the PMT threshold function should be moved into the WCSimWCPMT.cc file (which is probably where it belongs anyways).

The default method of QE involves removing the correct proportion of tracks at the StackingAction step according to the QE of the phototube. The current simulation only considers the QE of the phototube associated with the ID. When we set up an OD, we will need to do something more intelligent to account for the different phototube here.

For the treatment of scattered light, fiTQun requires the information of whether or not hit-generating photons have scattered or reflected in the detector. This data is used to compile the look-up tables that are used to predict the amount of scattered light at each PMT, for a given track hypothesis.

This should be implemented in a general way, so that it can be used for studies other than fiTQun tuning.

For each p.e., the following information should be accessible:

• The index of the true track that radiated the optical photon
• The PMT number (index?) where the hit was produced
• For each optical photon interaction, as the photon is propagated to the PMT:
  • The type of interaction
  • The position of the interaction (?)
  • The direction of the optical photon after the interaction (?)
  • The energy of the photon after the interaction (?)

The items with (?) are not required for fiTQun tuning, but there might be a general interest in keeping them.

We currently have two default macros in WCSim: novis.mac and vis.mac. These macros contain all possible detector configuration options, as well as any options which can be controlled with the detector messenger. We should think about restructuring to have a simple default macro file, which can then include other macro files to perform more complicated functions. This would mean having a larger catalogue of macros (for example, having a new macro for every new detector configuration) and either having a large macro with all the possible commands (but which is not the default macro) or utilizing the wiki to explain all the available commands. This could be a potential fix for issue #79 and is related to issue #80.

After #4 and #11 are finished we could simulate the SK-IV electronics setup. This is necessary to use WCSim for real SK/T2K based analysis work.

This shouldn't have to be set manually by the macro. Since it is a property of the PMt, it should be automatically done when the PD type is changed. This will also need to be done for the OD where the dark rate will be different than the ID.

This depends on issue #4 being resolved. But, after that work is done the current digitizer can be further sub-divided in electronics and DAQ pieces. This way one could implement things like the current SK software triggers cleanly.

WCSimConstructMaterials has a bunch of commented code. Is this deprecated or still useful? The photon energy table uses e-09*GeV which should just be eV. Some parts of the implemented properties, tables and surfaces are too much spread over the .cc file, so I believe the file can use some clean up. Also better naming for some variables wrt myST2 for example.

In WCSimDetectorConfigs.cc, half of the current configurations are various DUSEL-related detectors. Is anyone using these for anything? I would like to remove them because each time I add a new option that must be specified in the WCSimDetectorConfigs file (a new way of choosing PMTs for example), I must add it to all configurations and then test each one to ensure I haven't introduced an error. With the upcoming addition of an OD to our detectors, perhaps now is the time to delete these defunct options so we only have the options we need/actively use? If anyone desperately wanted to recover the old configurations then they could look through a previous tagged version and fish out the details. Any complaints?

This will allow us to separately specify various tubes, HPDs etc and digitizer electronics models.

Erin already started this work but I just rediscovered some work by Stan Seibert you also might look at in the archive/PMTProperties branch. It has some abstract base classes for digitizers that might be useful.

We should make clear that this file is only used to make cylindrical geometries, not all Water Cherenkov detectors. Since this is only a file name, and not a class name, this should require no change in code other than renaming the file.

This is required for part of the fiTQun tuning procedure, namely extracting the PMT charge response function.

After the latest merge, WCSim won't compile. Error is:

src/WCSimDetectorMessenger.cc: In member function ‘virtual void WCSimDetectorMessenger::SetNewValue(G4UIcommand*, G4String)’:
src/WCSimDetectorMessenger.cc:181: error: ‘class WCSimDetectorConstruction’ has no member named ‘SetWaterTubeLength’

@YujiOkajima , for some reason you weren't on the list of people I could assign this to on the issue tracker, but can you please correct this? I think you probably just need to correct the typo in line 102 in the .hh file.

Then, do some basic tests to make sure things look ok. First try compiling. Then try running one of the macros (vis.mac is good for this especially since you can see the length of the detector changing). Try setting the Super-K geometry and make sure the program doesn't crash. Then set the Hyper-K geometry and make sure the code still works. Try changing the length of the partition and make sure it is doing what you think it is. As a final check, it is also good to checkout your branch that you want to make a pull request for after you have pushed it on to GitHub. This is an especially good check to see if there are files which you might have on your local copy that you have forgotten to add to the repository.

We really do need a standard validation suite (a la issue #10)!

We want to add nuPRISM as an option in WCSim. Specifically, we are suggesting the option to build the detector as

• An air volume slightly larger than the 52.5m deep, 10m diameter nuPRISM shaft
• A water volume 52.4941m deep and 10m in diameter, filling the shaft with water
• An instrumented water volume with 52.4m depth and 6m diameter, positioned at the centre of the nuPRISM shaft. This is the nuPRISM detector.
• All of these numbers are changeable from the WCSim macro file - the above would just be the default numbers. This lets you simulate a nuPRISM-lite detector by reducing the depth of the instrumented region and offsetting it in the shaft.

This is created in the same way as the hyper-K specific geometry, using a ConstructNuPrism() method.

The function WCSimRootEvent::HasSubEvents() seems to be 'flipped' (assuming I understand the definition of SubEvent). It is currently

bool HasSubEvents() { return (fEventList->GetEntriesFast()==1); }

whereas I think it should be

bool HasSubEvents() { return (fEventList->GetEntriesFast()!=1); }

The problem of difference between hit of WCSim and SKDetSim still not be solved.
The figure below shows the comparison of 10 MeV electron (kinetic energy) events between WCSim and SKDetSim simulation.

From this figure, there is 10 % difference between 2 software (Total charge difference was ~2%).
It will effect to low energy analysis

In WCSimDetectorConfigs, the only thing relating to the photodetector should be CreatePMT and GetPMTName. The radius and expose height are already retrieved using the PMT pointer in ConstructPMT(), so they are redundant here. The glass thickness should also be retrieved this way so that we can build PMTs with different glass thicknesses in the detector, which we currently cannot do.

This is necessary to be able to simulate and read from the OD, which will be needed for issue #13. This will also require the capabilty to store multiple PMTObject pointers, which is currently not possible and is the topic of issue #38.

This is a long term project to get the BNL water based scintillator option available in the physics lists.

I seems that the Hyper-K code is relying on SK to already have been constructed to set some of the needed variables. We at least have noticed the glass thickness variable. It should be added so Hyper-K could be made by itself first and the assignment is not implicit.

The R3600 PMT collection efficiency measured by Hamamatsu is 73%. We will implement this in the code and will remove the extra factors that have been mimicking this efficiency factor. This will require further investigation, but will likely be related to the ratio factor in the quantum efficiency routines, and the absorption length tuning. When this is done, the correctionFactor introduced to the B&L phototubes in PR #98 will be removed. This will be implemented after issue #9 since the absorption factor tuning will be sensitive to the physics used.

In WCSim, the table of collection efficiency is exist in WCSimWCSD.cc, but the function which include the table (WCSimWCSD::ProcessHits) seems not to be used.
To introduce photodetectors' collection efficiency, It is necessary to modify WCSim code.

I'm sorry,

I found the function which I used for hit timing resolution analysis of measured data is different from the function which has been already introduced. It will effect in high charge region.

I will fix it as soon as possible.

Since this is on a public site I should probably add GPL info to the files etc. But, first I have to figure out what you are allowed to do for G4 code.

In WCSim, the hit timing distribution is based on Gaussian.
However, All photosensors timing distribution seems to be asymmetric and not to follow Gaussian.
The figure below is hit timing distribution of 1 p.e. charge of High QE R3600.

Add in new candidate options proposed at the Hyper-K meeting as described here: https://wiki.hyperk.org/DesignReport/DetectorOptimization#proposedbasictankperformance

The tanks are both cylindrical with dimensions 60 m (H) x 74 m (D) and both use 20" HQE B&L phototubes. One tank will have a photocoverage of 13.51 % and the other will have a photocoverage of 40 %.

For the HK design studies, new detector options must be implemented. The detector configurations that we need right now are:

1. SK detector with 12" HPD and 14.59% photocoverage
2. SK detector with 20" HPD and 13.51% photocoverage
3. A cylindrical detector with a height of 100m and a diameter of 69m with 12" HPD and 14.59% photocoverage
4. SK detector with 20" normal PMT and 20.27% photocoverage
5. SK detector with 20" HPD and 20.27% photocoverage

If you search on google for WCSim you still mostly get this:

https://wiki.bnl.gov/dusel/index.php/WCSim

Those pages should point the reader to GitHub.

Check to make sure this system builds and compiles with GEANT4 version 10.
Should the make system should be consolidated? Do we have to use cmake now?

Currently in WCSimConstructPMT, if a sensitive detector exists, no further sensitive detectors are instantiated. We will want different SD volumes when we create the OD. This will be done after issue #38 and before issue #37.

Someone needs to revisit the PhysicsList status.

Currently we are using the default one setup in the WCSimPhysicsList.cc code. There was some work by David Webber is branch archive/PhysicsLists that was merged into the trunk in commit 9784b8b that set the defaults but also gave an .mac file interface. Someone needs to review our default physics lists, look at the interface in the jobOptions2.mac file, possibly combine jobOptions.mac and jobOptions2.mac as described in bug #3, and also review the new physics lists options in the new GEANT4.

Other possibly related bugs would be:
#3 (Consolidate jobOptions.mac files)
#7 (Checking the situation for Gd)

This is needed to simulate the OD for issue #13 and can only be completed after issue #37 and #38. This either requires two separate digitizers that read from the two (ID and OD) types of tubes, or a single digitizer that somehow distinguishes between the ID and OD PMTs. Some thought will have to be put into how to best organize the readout of these digitized collections into the .root file.

Inspired by pull request #28.

Currently Tube ID numbers in WCSim follow the same convention as in SKDetSim, starting from 1 per the Fortran convention. However, all the arrays tube's, hits, etc. are stored in start from 0. As WCSim for HK moves further away from SKDetSim, keeping this convention will continue to create these off-by-one errors with little tangible benefit. I suggest we change the indexing to 0 now to avoid running into these problems for year to come. This change will be somewhat painful, but it will only get more painful as time goes on.

This will require someone to go through and check all the places where tube number gets referenced. Some less obvious things I know will need to be checked/fixed, both internally and externally. There are of course many more.

• Root example scripts
• fiTQun interface
• Superscan/APFIT interface (GeometryTables): this bit of code will need to keep indexing from 1 if we want to continue to support it.

Now there are jobOptions and jobOptions2.mac files. We should check if they can be combined. These are .mac files that need to be run before the physics setup happens (so that vis.mac is too late).

If possible tuning_parameters.mac should also be combined.

These all contain settings which must be set before control is passed to interpreter.