C++ port of the Decay0/GENBB fortran Monte Carlo code for the generation of standard decay or double beta decay processes for various radioactive nuclides of interest
License: GNU General Public License v3.0
I have only checked the code related to Nd150.
Possible patch:
diff --git a/bxdecay0/genbbsub.cc b/bxdecay0/genbbsub.cc
index 9f1bf28..d09135f 100644
--- a/bxdecay0/genbbsub.cc
+++ b/bxdecay0/genbbsub.cc
@@ -172,7 +172,7 @@ namespace bxdecay0 {
event & event_,
const int i2bbs_,
const std::string & chnuclide_,
- const int ilevel_,
+ int ilevel_,
const int modebb_,
const int istart_,
int & ier_,
@@ -1209,6 +1209,11 @@ namespace bxdecay0 {
bb_params_.Zdbb = 62.;
bb_params_.Adbb = 150.;
bb_params_.EK = 0.;
+ if (modebb_ == 20) {
+ ilevel_ = 0;
+ bb_params_.Qbb = 2.085;
+ bb_params_.Zdbb = 64.;
+ }
if (ilevel_ < 0 || ilevel_ > 5) {
std::cerr << "[error] "
<< "bxdecay0::genbbsub: "
@@ -1939,7 +1944,7 @@ namespace bxdecay0 {
bool m_ok = false;
if (!m_ok && bb_params_.itrans02 == 0
&& (m == 1 || m == 2 || m == 3 || m == 4 || m == 5 || m == 6 || m == 9 || m == 10 || m == 11 || m == 12
- || m == 13 || m == 14 || m == 15 || m == 17 || m == 18 || m == 19)) {
+ || m == 13 || m == 14 || m == 15 || m == 17 || m == 18 || m == 19 || m == 20)) {
m_ok = true;
}
if (!m_ok && bb_params_.itrans02 == 2I found that the DEAY0 is very useful and would like to use it on background simulation for DUNE. Do you feel okay with it? Is there any requirement about the copyright?
Also, I have a few questions.
Will DECAY0 be long-term supported for several years?
Is it possible to add some other decays? If yes, how hard would that be? Can we contribute to this?
Hi! I'm having an issue with BxDecay0 1.0.10 and CMake 3.16.3 which looks related to 8652dbf.
The situation is the following: I'm developing a library that depends on BxDecay0, and I manage the dependencies with CMake. I call find_package(BxDecay0 1.0.10 REQUIRED COMPONENTS Geant4) in the CMakeLists.txt of the library project and it works smoothly. But: as I want my library's clients to be able to import it with CMake, I provide a LibraryConfig.cmake in which I also check that BxDecay0 is available with find_dependency(BxDecay0 1.0.10 REQUIRED COMPONENTS Geant4), as per official instructions. For a reason I don't really understand, this step fails with the following when I try to configure a client application that calls find_package(mylib):
CMake Warning (dev) at /opt/bxdecay0/lib/cmake/BxDecay0/BxDecay0Config.cmake:69 (if):
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
/home/gipert/sw/src/legend/remage/install/lib/cmake/remage/remageConfig.cmake:50 (find_dependency)
CMakeLists.txt:6 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /opt/bxdecay0/lib/cmake/BxDecay0/BxDecay0Config.cmake:69 (if):
if given arguments:
"NOT" "_requested_comp" "IN_LIST" "_BxDecay0_supported_components"
Unknown arguments specified
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
/home/gipert/sw/src/legend/remage/install/lib/cmake/remage/remageConfig.cmake:50 (find_dependency)
CMakeLists.txt:6 (find_package)
Which refers to this line here. I don't understand why this happens, as my CMake version should be high enough to have this policy set to "new". More interestingly, the error does not show up when compiling my library and calling find_package(BxDecay0 REQUIRED COMPONENTS Geant4)!
Any ideas from the developers' side?
The current use of resource files in bxdecay0 makes an install of the package non-relocatable due to the hardcoding of the install prefix:
bxdecay0/source/bxdecay0/resource.cc.in
Line 38 in 1462826
Whilst something like binreloc could be used, it would appear the resource files are
With that in mind, could it be easier to directly code these in the resource.cc file as static data (or generate the code from the resource files)?
I was wondering whether BxDecay0 is thread-safe. I have tried embedding it in my GEANT4 application (by using the built-in extension) and it works fine in sequential mode, but segfaults in multi-threaded mode. The stack trace is never the same (symptom of some non-deterministic race condition), but seems to point to a problem in libBxDeca0.so. For example:
malloc(): unaligned tcache chunk detected
### CAUGHT SIGNAL: 6 ### address: 0x3e800008cf8, signal = SIGABRT, value = 6, description = abort program (formerly SIGIOT).
Backtrace:
[PID=36088, TID=4][ 0/27]> /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c) [0x7f8ea6696a7c]
[PID=36088, TID=4][ 1/27]> /lib/x86_64-linux-gnu/libc.so.6(raise+0x16) [0x7f8ea6642476]
[PID=36088, TID=4][ 2/27]> /lib/x86_64-linux-gnu/libc.so.6(abort+0xd3) [0x7f8ea66287f3]
[PID=36088, TID=4][ 3/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x896f6) [0x7f8ea66896f6]
[PID=36088, TID=4][ 4/27]> /lib/x86_64-linux-gnu/libc.so.6(+0xa0d7c) [0x7f8ea66a0d7c]
[PID=36088, TID=4][ 5/27]> /lib/x86_64-linux-gnu/libc.so.6(+0xa545c) [0x7f8ea66a545c]
[PID=36088, TID=4][ 6/27]> /lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1c) [0x7f8ea6aaea0c]
[PID=36088, TID=4][ 7/27]> /opt/bxdecay0/lib/libBxDecay0.so(+0x1d41d) [0x7f8ea117241d]
[PID=36088, TID=4][ 8/27]> /opt/bxdecay0/lib/libBxDecay0.so(+0x1d535) [0x7f8ea1172535]
[PID=36088, TID=4][ 9/27]> /opt/bxdecay0/lib/libBxDecay0.so(_ZN8bxdecay012get_resourceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb+0x48) [0x7f8ea1172b48]
[PID=36088, TID=4][10/27]> /opt/bxdecay0/lib/libBxDecay0.so(_ZN8bxdecay012dbd_isotopesB5cxx11Ev+0x13f) [0x7f8ea118533f]
[PID=36088, TID=4][11/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction18ApplyConfigurationEv+0x19e) [0x7f8ea6c6ea1e]
[PID=36088, TID=4][12/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction10pimpl_type10get_decay0Ev+0xc0) [0x7f8ea6c6f070]
[PID=36088, TID=4][13/27]> /opt/bxdecay0/lib/libBxDecay0_Geant4.so(_ZN11bxdecay0_g422PrimaryGeneratorAction17GeneratePrimariesEP7G4Event+0xb0) [0x7f8ea6c6f6e0]
[PID=36088, TID=4][14/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager13GenerateEventEi+0x1a1) [0x7f8ea61c89d1]
[PID=36088, TID=4][15/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager15ProcessOneEventEi+0x14) [0x7f8ea61c68a4]
[PID=36088, TID=4][16/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager11DoEventLoopEiPKci+0x176) [0x7f8ea61c65d6]
[PID=36088, TID=4][17/27]> /opt/geant4/lib/libG4tasking.so(_ZN22G4WorkerTaskRunManager6DoWorkEv+0x126) [0x7f8ea61c6786]
[PID=36088, TID=4][18/27]> /opt/geant4/lib/libG4tasking.so(+0x3c542) [0x7f8ea61b8542]
[PID=36088, TID=4][19/27]> /opt/geant4/lib/libG4tasking.so(_ZNSt13__future_base13_State_baseV29_M_do_setEPSt8functionIFSt10unique_ptrINS_12_Result_baseENS3_8_DeleterEEvEEPb+0x2d) [0x7f8ea61bca4d]
[PID=36088, TID=4][20/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x99f68) [0x7f8ea6699f68]
[PID=36088, TID=4][21/27]> /opt/geant4/lib/libG4tasking.so(_ZN3PTL4TaskIvJEEclEv+0x107) [0x7f8ea61bcba7]
[PID=36088, TID=4][22/27]> /opt/geant4/lib/libG4ptl.so.0(_ZN3PTL10ThreadPool14execute_threadEPNS_14VUserTaskQueueE+0x398) [0x7f8ea2efa208]
[PID=36088, TID=4][23/27]> /opt/geant4/lib/libG4ptl.so.0(_ZN3PTL10ThreadPool12start_threadEPS0_PSt6vectorISt10shared_ptrINS_10ThreadDataEESaIS5_EEl+0x215) [0x7f8ea2efa685]
[PID=36088, TID=4][24/27]> /lib/x86_64-linux-gnu/libstdc++.so.6(+0xdc2c3) [0x7f8ea6adc2c3]
[PID=36088, TID=4][25/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x94b43) [0x7f8ea6694b43]
[PID=36088, TID=4][26/27]> /lib/x86_64-linux-gnu/libc.so.6(+0x126a00) [0x7f8ea6726a00]
Still I could have messed it up somewhere else in my application – I was just wondering whether you can make a statement about thread safety in general.
Hello,
I was looking for the U238 decay chain in the code but I cannot find it, this ref seems to be showing on Fig 1 all the particles output, but when I try to generate U238 or Rn222 background decays, the code throws an error.
Maybe this hasn't been ported yet?
Thanks
Pierre
For example 2 by default the CMakeLists.txt does not work for me.
It uses a function called "target_include_dirs" but that does't work, I found that replacing line 9 with "target_include_directories(ex02 PRIVATE ${HEPMC3_INCLUDE_DIRS})"
makes the CMakeLists work
A second issue I was having was the data file being produce had many of the mass values have negatives. What does the negative mass represent? Is there a way to get the rest masses of the partials listed?
TO DO:
G4String has been modified in G4 v11. I get this compilation error:
/root/src/extensions/bxdecay0_g4/bxdecay0_g4/unique_point_vertex_generator_messenger.cc: In member function ‘virtual void bxdecay0_g4::UniquePointVertexGeneratorMessenger::SetNewValue(G4UIcommand*, G4String)’:
/root/src/extensions/bxdecay0_g4/bxdecay0_g4/unique_point_vertex_generator_messenger.cc:114:22: error: ‘class G4String’ has no member named ‘isNull’
114 | if (! unitRepr.isNull()) {
| ^~~~~~
Hi, I'm not sure whether this should be attributed or not to an incorrect usage of G4ParticleGun in the G4 extension, you'll certainly know better than me. I have embedded BxDecay0 in my app at a very basic level, see the relevant source code here:
https://github.com/gipert/remage/blob/master/include/RMGVVertexGenerator.hh
https://github.com/gipert/remage/blob/master/include/RMGGeneratorDecay0.hh
https://github.com/gipert/remage/blob/master/src/RMGGeneratorDecay0.cc
When I test it with a simple 0vbb decay:
/bxdecay0/generator/dbd Ge76 2345 1 0
My output is flooded by G4 printouts:
...
G4ParticleGun::e-
was defined in terms of KineticEnergy: 0.000887163GeV
is now defined in terms Momentum: 0.00158237GeV/c
G4ParticleGun::e-
was defined in terms of KineticEnergy: 0.00115184GeV
is now defined in terms Momentum: 0.00035327GeV/c
G4ParticleGun::e-
was defined in terms of KineticEnergy: 0.000110225GeV
is now defined in terms Momentum: 0.00238566GeV/c
G4ParticleGun::e-
was defined in terms of KineticEnergy: 0.00192877GeV
is now defined in terms Momentum: 0.00139113GeV/c
...
From G4ParticleGun::SetParticleMomentum:
https://github.com/Geant4/geant4/blob/master/source/event/src/G4ParticleGun.cc#L168-L183
That you call here:
And this is a sort of warning because the particle didn't have zero energy before (?) I'm a bit confused.
Line 62 in 5366e1f
Seems to a bit odd to me, I don't understand why there should be a ln(2) in there.
To illustrate the problem and because I'm not quite sure about me, I've created a small ROOT macro:
#include <iostream>
#include "TPad.h"
#include "TH1D.h"
#include "TCanvas.h"
#include "TFitResult.h"
#include "TLegend.h"
#include "TF1.h"
#include "TMath.h"
#include "TRandom.h"
void test_time_diff() {
double thnuc = 164.3e-6;
TH1D histo_0("time_diff_0", ";Time [s];N decays", 1000, 0, 1000e-6);
TH1D histo_1("time_diff_1", ";Time [s];N decays", 1000, 0, 1000e-6);
int nevent=1'000'000;
for (int i=0; i<nevent; i++) {
if (i%(nevent/100)==0)
std::cout <<100.*i/nevent <<"%" << std::flush;
/// Option 0 -> no ln(2)
double tdnuc_ = - thnuc * std::log(gRandom->Uniform(0.,1.));
histo_0.Fill(tdnuc_);
/// Option 1 -> with ln(2)
tdnuc_ = - thnuc / std::log(2.) * std::log(gRandom->Uniform(0.,1.));
histo_1.Fill(tdnuc_);
}
/// From then on, just retrieve the result and plot everything
auto fit_result_0 = histo_0.Fit("expo", "S");
auto fit_result_1 = histo_1.Fit("expo", "S");
double tc0 = 1e6/TMath::Abs(fit_result_0->Parameter(1));
double tc1 = 1e6/TMath::Abs(fit_result_1->Parameter(1));
std::cout << "Time constant option 0: " << tc0 << " us\n";
std::cout << "Time constant option 1: " << tc1 << " us\n";
TCanvas c;
histo_0.SetLineColor (kBlue);
histo_0.SetMarkerColor(kBlue);
histo_1.SetLineColor (kGreen);
histo_1.SetMarkerColor(kGreen);
histo_0.Draw();
histo_1.Draw("SAME");
TF1 f("fun_name", "[1]*TMath::Exp(-x/[0])", 0, 1000e-6);
f.SetLineColor (kOrange);
f.SetMarkerColor(kOrange);
f.SetParameter(0,thnuc);
f.SetParameter(1,histo_0.GetBinContent(1));
f.Draw("SAME");
TLegend leg(0.2,0.7,0.9,0.9);
leg.AddEntry(&histo_0, Form("-thnuc #times log(uniform(0.,1.)) #tau = %.1f #mus", tc0));
leg.AddEntry(&histo_1, Form("-thnuc / log(2) #times log(uniform(0.,1.)) #tau = %.1f #mus", tc1));
leg.AddEntry(&f , "TMath::Exp(-x/164.3e-6)");
gPad->RedrawAxis();
leg.SetBorderSize(1.);
leg.Draw();
c.Print("time_diff_test.pdf");
}
This macro creates the image shown attached, time_diff_test.pdf. The Po214 livetime should be 164us, whereas it is 230us with the method in Decay0.
I'm aware this could potentially change quite a bit of the analyses using Decay0, but I'm not sure why generating bismuth/polonium 214 should lead to a decay constant other than 164us. This happens in other part of the code as well.
Dear developers,
First of all, I really thank you for this super useful tool. The results of a simulation of Cs137 beta decay have improved and helped my work at the moment.
I write you because I am interested in generating the decay particles in a certain way (direction), so I was thinking of implementing a class derived from the Primary Generator Action. However, I have tried to modify the Generate Primaries function of your Primary Generator Action class so I can give another argument and have access to the direction of emission from my own Primary Generator Action class. However, I am having a big trouble to solve this. I would really appreciate if you could recommend me the best way to achieve this aim or your suggestions.
I look forward to hearing from you.
Kind regards,
Diego Mendoza
For SuperNEMO (and DUNE do as well) we have a CVMFS repository available for distributing software and large datasets. The gA data's an obvious candidate here, so I wanted to start a discussion on the best way to organize this with future versions/patches in mind (and also for packaging with separate packages for bxdecay0 and "bxdecay0-data").
At least at first sight, the CVMFS case would appear to be simple, in that given a CVMFS root, things could be organised like:
<CVMFSRoot>/
+- bxdecay0/
+- vX.Y.Z/
+- resources/
... files ...
Versions/resources levels could be swapped on preference. A client wanting to use this would then AFAIK, just need to set the BXDECAY0_RESOURCE_DIR to, e.g. <CVMFSRoot/bxdecay0/vX.Y.Z/resources (and that could be done in suitable scripts).
CVMFS has a nice de-duplication feature (it's content based), so it wouldn't be expensive to have direct copies of all the gA data for each bxdecay0 version. The only thing I'm not sure about here is matching bxdecay0 and gA data versions, but I think bxdecay0 does for users?
Anyway, I can start experimenting with the above for SuperNEMO and happy for our CVMFS to be a test bed here!
Hi! Quick one: can I check in find_package(BxDecay0 ...) if bxdecay0 was compiled with Geant4 support? I tried with
find_package(BxDecay0 1.0 COMPONENTS BxDecay0_Geant4)But BxDecay0_FOUND is set to TRUE even if I know the BxDecay0::BxDecay0_Geant4 target is not available in my installation...
It should be (dbd_level < 0) :)
Dear developers,
As your introduction says, bxdecay0 has an interface which allows to install your own algorithm for vertex generation.
And in the example, the way to use your unique_point_vertex_generator is introduced.
But I still don't understand how to write my own vertex generator after inheriting vertex_generator_interface.
Precisely, I do not clearly know how to update my vertex ( for the unique_point_vertex_generator don't need to do this and primary_generator_action uses ShootVertex method to link to vertex generator).
So, I would appreciate it if any vertex generators like random position generation or precomputed points generation which are metioned in the comments of vertex_generator_interface.hh can be provided or described.
Best regards，
Lowerce
The original Decay0 program stores the generation time differences between successive particles in a given event, as illustrated in the following chronogram :
event
time particle particle particle
reference 0 1 2
-------+----------------x-------------x---------------------------x------------------------> t
|<-------------->|<----------->|<------------------------->|
dt0 dt1 dt2
However, BxDecay0 stores the time elapsed from the event reference time, as shown below:
event
time particle particle particle
reference 0 1 2
-------+----------------x-------------x---------------------------x------------------------> t
|--------------->| t0 : :
|----------------------------->| t1 :
|--------------------------------------------------------->| t2
Thus the generation time of a given particle within the event does not depend on the previous generated particles. This also enables to easily remove or insert new particles in the timeline of the event.
The construction of the absolute generation time of a given particle must be based on the following formula: t_abs = t_event + t_rel where t_rel is generally a decay time randomized from the half life of some nuclear level.
The various examples and the Geant4 extension must support this approach to export the BxDecay0 generate events in their own models.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.