wcsim/wcsim

The WCSim GEANT4 application

Welcome to WCSim

WCSim is a very flexible Geant4-based program for developing and simulating large water Cherenkov detectors.

As of August 2014 WCSim has been moved to GitHub. It can be found here

WCSim has very few external dependencies. It relies on only ROOT and Geant4.

There is a mailing list which will send you GitHub push/checkin notifications here

You can follow issues/requests etc by watching the GitHub respository.

Validation Webpage

WCSim uses GitHub Actions CI to perform build and physics tests for each pull request and commit. The scripts it runs can be found in this separate github repository

Validation results can be found here

Documentation

Caution

The WCSim wiki & PDF documentation are outdated.

The doxygen documentation is more correct, but incomplete.

Tutorials and information about the branches and WCSim development model can be found on the wiki

More detailed information about the simulation is available in doc/DetectorDocumentation.pdf

Additionally, doxygen documentation is available here. Note that most of the code has no doxygen comments, but all output class member variables are documented. See the WCSimRoot* classes

doxygen documentation can be built locally by running

cd $WCSIM_SOURCE_DIR/ && doxygen WCSim_doxygen_config

For admin: A more featured doxygen build can be performed & pushed using an alternative doxygen config file (requires dot from graphviz)

git clone -b gh-pages --single-branch [email protected]:WCSim/WCSim.git WCSim-dox
cd WCSim-dox
./get_dox.sh

You can also make this featured version locally by

cd $WCSIM_SOURCE_DIR
git clone -b gh-pages --single-branch [email protected]:WCSim/WCSim.git WCSim-dox
doxygen WCSim-dox/WCSim_doxygen_config

Build Instructions

Dependencies

The automated building testing is currently performed inside the hk-software docker container with the prerequisites:

• Geant4 10.3.3 (installed via CMake)
  • All of the G4 data files are also required to be installed, include hadron xsec, etc.
• ROOT 6.26/04 (installed via CMake)
• HepMC3 3.2.6
• gcc 8.5.0
• CMake 3.20.2

And as such this is the most supported version of the software (it is guaranteed to work)

Tip

If you just need to read WCSim output files, you can do this without the G4 dependency using the WCSim_WCSimRoot_only CMake option (see here).

Other versions of prerequisite software can be tried, but aren't guaranteed to work.

• Geant
  • If using a newer version of Geant, it is your responsiblity to assess whether Geant physics changes are significant, relative to the officially supported 4.10.3.3
• ROOT
  • ROOT5 (e.g. v5r34p36 or v5r34p38, or potentially any v5r34) can potentially be made to work. You may need to modify $WCSIM_BUILD_DIR/src/cmake_install.cmake to take account of ROOT5 not producing .pcm files
  • ROOT6 has been tested on an older version than above (6.20/04)
• HepMC3
  • HepMC3 version 3.2.6 is supported and any minor versions below/above this should also work.
  • It is possible that older versions (<=3.1.x) will also work, though this is not guaranteed.
• CMake 3.1 and above are required by CMakeLists.txt, but not all old versions have been tested
• The compiler should support -std=c++11 (or -std=c++0x) e.g. gcc 4.8.5
  • The WCSim CMake step should set your C++ standard to be the same as what was used by the installation of ROOT you are building against

Build Instructions using CMake

CMake is cross-platform software for managing the build process in a compiler-independent way. It is required to build ROOT and Geant4 also through CMake. Using cmake, builds and source code need to well separated and make it easier to build many versions of the same software.

A recommended way to set up the directory structure in your own preferred WCSIM_HOME:

• ${WCSIM_HOME}/WCSim : contains the src dir, typically the cloned or unzipped code from GitHub
• ${WCSIM_HOME}/WCSim_build : contains directories for each build, eg. for each branch you want to test or for different releases, comparing debugged versions, etc. Each subdirectory like WCSim_dev or WCSim_v1.2 would contain the intermediate files produced during compilation and not the finale ones

To compile you need to have CMakeLists.txt in the WCSim source dir.

• mkdir -p ${WCSIM_HOME}/WCSim_build/mydir ; cd ${WCSIM_HOME}/WCSim_build/mydir
• Set up the dependencies

  source /path/to/thisroot.sh
  source /path/to/geant4.sh

• cmake3 ../../WCSim : this executes the commands in CMakeLists.txt and generates the Makefiles for both the ROOT library as the main executable.
  • For some OS, cmake3 is just cmake
• make clean : if necessary
• make -j\nproc` install` : will
  • first compile libWCSimRoot.so which you need for using the ROOT Dict from WCSim (e.g. to read the output files)
  • compile WCSim (libWCSimCore.so and the executable WCSim)
  • install the software in the build directory (copies things into bin/, include/, etc.)
• source bin/this_wcsim.sh : will setup the environment variables such that you can run WCSim

To recompile:

• Typically just make install will be enough and also redo the cmake phase if something changed.
• Sometimes you need to make clean first.
• When there are problems, try removing CMakeCache.txt, and redo the cmake.

Useful cmake commands:

• make edit_cache : customize the build.
• make rebuild_cache : redo the cmake phase.

WCSim cmake build options

• -DWCSim_Geometry_Overlaps_CHECK=<ON|OFF> If ON, turns on geometry overlap checking when running the code (slow, but important when setting new detector geometry options). Default: OFF
• -DWCSim_DEBUG_COMPILE_FLAG=<ON|OFF> If ON, turns on the gcc debug compiler flag -g. Default: OFF
• -DWCSIM_SAVE_PHOTON_HISTORY_FLAG=<ON|OFF> If ON, turns on photon scattering/reflection history saving. The data class WCSimRootCherenkovHitHistory is used in a similar way as WCSimRootCherenkovHitTime. Default: OFF
• -DWCSim_WCSimRoot_only=<ON|OFF> If ON, only builds the WCSimRoot library (ignoring the WCSimCore one). This is useful if one wants only to read the WCSim output files (for e.g. reconstruction) and not running any simulation. Default: OFF

Build with CMake on sukap:

A script allowing to build WCSim with CMake on sukap is available:

cd $WCSIM_SOURCE_DIR
./setup/env_sukap.sh
./make.sh

Note that ./make.sh should also work on other systems.

This script will read the current WCSim directory name and create a directory to hold the different cmake builds. For example, in case your current WCSim directory name is 'WCSim', it will create a '../WCSim-build' directory. It will also create a ../WCSim-install directory.

It will then create a directory for your current branch which will have the name of the current branch. For example, in case your current branch name is hybridPMT, you will have:

WCSim/
WCSim-build/
WCSim-build/hybridPMT/
WCSim-install/
WCSim-install/hybridPMT/

Note that by default, just make install is run. You can run make clean before make install by running ./make.sh clean

Build Instructions using GNUmakefile

Caution

GNUmakefile is specifically only for use with ROOT5 and is not supported otherwise.

All output that needs to be trusted must use cmake. To discourage you from using this, the GNUmakefile is hidden in a different branch

The result of a build using the GNUmakefile will be different to the result of a CMake build. If you are using WCSim as a dependency for other packages, you will have to update their build paths to find WCSim includes/libraries

export WCSIM_BUILD_DIR=/path/to/WCSim/
cd $WCSIM_BUILD_DIR
git clone --depth 1 https://github.com/WCSim/WCSim.git -b makefile --single-branch makefiledir
cp makefiledir/GNUmakefile .
make clean_wcsim
make rootcint
make

Using WCSim without building using Docker

Docker allows you to use WCSim without compiling in an OS independant way. The Docker images are hosted on DockerHub and can be used by following the steps below.

Important

Automated WCSim Dockerfile builds have stopped working. There have been no requests (yet) to restore them.

In the meantime, if you are a Hyper-K collaborator you can use the hk-software image. (This is what the CI uses)

Alternatively, the old Dockerfiles are still available in this repository. You are free to use/modify them to build a newer version of WCSim for your use. If you do, please share your Dockerfile changes via a pull request.

1. Install Docker cross platform instructions can be found at https://www.docker.com/
2. Get the latest HK container image docker pull ghcr.io/hyperk/hk-software:main
3. Run an instance of the container which will have WCSim and all dependencies installed docker run --name=WCSim -it ghcr.io/hyperk/hk-software:main

• Note: only run once or you will make multiple contianers
• To save data from inside your docker image mount a local folder in the docker image at runtime and then anything placed in that directory will be available in that folder after exit. To do that run the following docker run --name=WCSim -it -v local_folder_path:docker_mount_path ghcr.io/hyperk/hk-software:main

4. The WCSim version in the container will probably be out of date. Let's update it

cd $WCSIM_SOURCE_DIR
git pull origin develop
cd ../build-Linux_x86_64-gcc_8-python_3.8.13
make -j`nproc` install

5. Run WCSim
6. To exit the docker image exit

Note: You only need to use the docker run command once to create the container. Once created you changes are saved in that container instance and you can start the container at any time with docker start -i WCSim

Extra docker commands:

1. See all images docker images
2. Delete an image docker rmi imageID
3. See all containers docker ps -a
4. Delete a container docker rm ContainerID

Using WCSim without building using Singularity

Singularity is a similar container tool with different philosophies. The most important being that you can't run as root. This means that it may be installed and available to use on your local cluster.

You should be able to run the docker container with singularity without any problems. Just to note that $WCSIM_SOURCE_DIR and $WCSIM_BUILD_DIR will be read-only, therefore you should clone, build, and run a new version of WCSim elsewhere (if you forget you'll see a nasty seg fault when running WCSim - this is just because of the read-only directory).

Running WCSim

To test that WCSim is working (however you installed it), try running the test macro WCSim.mac, which runs 10 electrons with 5 MeV of energy in the Super-Kamiokande detector (it should take less than a minute to run).

cd $WCSIM_BUILD_DIR
WCSim WCSim.mac macros/tuning_parameters.mac

WCSim.mac is well commented. Take a look inside (and also at other .mac files in /macros/) for the various options you can use to run WCSim

Analysing the output of WCSim

There are a few example scripts inside sample-root-scripts/

• sample_readfile.C is a general script that allows you to see (most) event-level variables
• For the hybrid geometry, see AnalyzeWSHierarchy.c
  • Compile it using the Makefile in sample-root-scripts/ (i.e. run make from that folder)
  • Execute it using Analyzer.sh in sample-root-scripts/ (i.e. run ./Analyzer.sh from that folder)
• For info about the other scripts, see the README inside sample-root-scripts/

Color Convention for visualization used in WCSimVismanager.cc

• gamma = green
• neutrino = yellow
• electron = blue
• positron = red
• muon = white
• muon+ = silver
• proton = magenta
• neutron = cyan

---

WCSim development is supported by the United States National Science Foundation.

wcsim's Issues

Make it possible to instantiate multiple sensitve detector volumes

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.

Make it possible to store multiple PMT pointers.

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.

Change the quantum efficiency method to allow for different types of phototubes in the same detector

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.

Clean up WCSimConstructMaterials

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.

Separate the phototube and digitizer into two distinguishable pieces.

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.

Add comments in code to generate meaningful doxygen output

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.

Properly set collection efficiency for each photosensor option

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.

Simulate SK-IV Electronics

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.

Add HPDs to the list of possible tubes.

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.

Change hit timing distribution shape

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.

Further subdivide the digitizer into electronics and DAQ.

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.

Restructure how our macros are organized to include a simple default macro and a catalogue of more specialized macros

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.

Simulate PMT after-pulsing and other realistic PMT effects.

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

Add nuPRISM geometry as option to WCSim

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.

Hard-coded .mac files not found should be a clearer error

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.

Split WCSimRootCherenkovHit GetTotalPe(int i) method in two and rename for clarity.

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.

Externally document and internally comment the Hyper-K geometry code.

Change first TubeID to 0

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.

Move photodetector parameters out of WCSimDetectorConfigs

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.

Add acrylic around the phototubes

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

Add a 12" HPD to the list of available photodetectors

Check compatibility with latest version of GEANT4 and possibly consolidate/update make system.

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?

Incorporate BNL WB Scintillator model

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

Rename WCSimConstructWC to WCSimConstructCylinder

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.

Implement candidate HK detector options

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

Move the PMT threshold cut from WCSimWCDigitizer.cc to WCSimWCPMT.cc

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).

Function WCSimRootEvent::HasSubEvents() seems incorrect

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); }

Check and validate PhysicsList situation

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)

Incorrect hit timing resolution

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.

Consolidate the jobOptions .mac files

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.

Removing old DUSEL detector configurations

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?

Add missing variables to the PMT construction for Hyper-K

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.

Add license info

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.

Add new Hyper-K candidate detector options from July HK Meeting

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 %.

Implement optical photon tracking, and include this information in the output

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.

Implement the direct generation of raw p.e.'s, Poisson distributed over all the PMT's.

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

Make it possible to digitize info from different PMTs

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.

WCPMTGlassThickness different for SK 20" PMTs and HK 20" PMTs

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?

Make it possible to read hit info from multiple PMTs

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.

Use the proper R3600 PMT collection efficiency

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.

Merge novis.mac and vis.mac to make a single default executable

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.

Add OD option for cylinders

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.

Difference between hit count of WCSim and SKDetSim

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

Make it less likely for users to accidentally miss the /WCSim/Construct line in novis.mac/vis.mac

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.

Update the old DUSEL pages so people can find WCSim if they look for it on google.

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.

More precise analysis of HPD parameters

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.

Add a validation suite for running after updates

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.

Code won't compile after pull request #21 was merged

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)!

Move dark rate and convert rate from the macro into WCPMTObject

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.

Check and validate Gd model/situation