jeffersonlab / remoll

Simulations for the MOLLER Experiment at Jefferson Lab, http://moller.jlab.org

Simulations for the MOLLER Experiment at Jefferson Lab

Community

Simulations are coordinated on the [email protected] mailing list and the JLab 12 GeV Slack workspace (in particular, the #moller_simulation channel). Anyone with a jlab.org email address can join without invitation. Feel free to contact developers there with questions.

Running simulations

There are several options for running simulations:

• downloading and compiling the code,
• using a docker container on any operating system,
• using a singularity container on linux systems.

Simulations can be run in interactive mode when not specifying arguments, or in batch mode when specifying a macro:

Usage:
 remoll [-g geometry] [-m macro] [-u session] [-r seed] [-t nthreads] [macro]

Analyzing the output

You can access the output file with a regular root installation (it will warn about non-perfect support). A listing of the output variables is available for reference.

To take advantage of dedicated functionality for the data types in the output file, you will need to follow the more detailed analysis instructions. To simplify this, you can also use the helper executable reroot which is available wherever remoll is available.

Known issues

Error: LLVM SYMBOLS ARE EXPOSED TO CLING

You may encounter the following error message when running in graphical mode:

 Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE EXPOSED TO CLING!
 This will cause problems; please hide them or dlopen() them after the call to
 TROOT::InitInterpreter()!

This is a (generally harmless) known issue. A workaround is to run remoll with OpenGL disabled:

LIBGL_ALWAYS_INDIRECT=1 build/remoll

remoll's Issues

remollIO recreates default remollout.root even when other output filename specified in macro

Because remollIO::InitializeTree() is called by the remollIO constructor, the default remollout.root file is always recreated, even if (later) the macro specifies a different filename. This can cause loss of data in remollout.root even when the user thinks they are going to be writing to a different file.

Possible solution: do not call InitializeTree() in constructor and handle this only with a call to remollIO in RunAction::BeginOfRun().

Multiple Volume Target Work

Target needs support for multiple volumes. This becomes tricky because sampling needs to be done effectively and radiative effects over several volumes needs to be accounted for.

In addition having material in the beamline in the form of windows where events will not be generated, but radiative losses/multiple scattering are included must be supported as well.

Random Number Seed

Seed should be set through G4Random:: and not CLHEP::Random:: in remoll.cc

https://twiki.cern.ch/twiki/bin/view/Geant4/QuickMigrationGuideForGeant4V10#Random_numbers

Regenerate dictionaries on header change

Few things are more frustrating than spending 4 days trying to debug a phony problem that is caused by out-of-date dictionaries. With increases in development, more frequent changes in headers, and no automatic way of recompiling dictionaries, we're bound to run into more issues (which may not lead to a crash and only manifest in strange results).

Implement remoll geometry validation executable

Implement a simple bin/remoll-validate-geometry <gdml file> executable that tests for successful loading of the geometry and performs an overlap check. Exit code should return success when no issues.

Use Thomas-BMT spin tracking equations of motions

In order to study PMT DD type effects as observed by Qweak, we will need to be able to study longitudinal and transverse polarization tracking through the magnetic fields using the Thomas-BMT equations of motion.

This is how Qweak implements this in https://qweaksvn.jlab.org/repos/Simulation/trunk/QWGEANT4/src/QweakSimDetectorConstruction.cc

#define TRACK_ELECTRON_SPIN
#ifdef  TRACK_ELECTRON_SPIN
  fGlobalEquation = new G4Mag_SpinEqRhs(pMagneticField);
  G4int numberOfVariables = 12;
#else
  fGlobalEquation = new G4Mag_UsualEqRhs(pMagneticField);
  G4int numberOfVariables = 6;
#endif

  // taken from one of the Geant4 presentation:
  // - If the field is calculated from a field map, a lower order stepper
  //   is recommended: the less smooth the field is, the lower the order of the
  //   stepper that should be used. For very rough fields one should use 1st order
  //   stepper, for a somewhat smooth field one must choose between 1st and 2nd
  //   order stepper.

  //fGlobalStepper  = new G4ClassicalRK4(fGlobalEquation, numberOfVariables);  // classical 4th order stepper
  //fGlobalStepper  = new G4ExplicitEuler(fGlobalEquation, numberOfVariables); //           1st order stepper
  //fGlobalStepper  = new G4ImplicitEuler(fGlobalEquation, numberOfVariables); //           2nd order stepper
  fGlobalStepper  = new G4SimpleRunge(fGlobalEquation, numberOfVariables);   //           2nd order stepper


  // Provides a driver that talks to the Integrator Stepper, and insures that
  //   the error is within acceptable bounds.
  G4MagInt_Driver* fGlobalIntgrDriver = new G4MagInt_Driver(0.1*mm,  //1.0e-3*mm,
							    fGlobalStepper,
							    fGlobalStepper->GetNumberOfVariables());

  fGlobalChordFinder = new G4ChordFinder(fGlobalIntgrDriver);



  //       G4bool fieldChangesEnergy = false;
  //       G4FieldManager* pFieldMgr = new G4FieldManager(myField,pChordFinder,FieldChangeEnergy);
  //       LocalLogicalVolume = new G4LogicalVolume(shape, material,"name",pFieldMgr,0,0);

  //   // minimal step of 1 mm is default
  //   fMinStep = 0.01*mm ;
  //
  //   fGlobalChordFinder = new G4ChordFinder (pGlobalMagnetField,
  //                                           fMinStep,
  //                                           fGlobalStepper);

  fGlobalFieldManager->SetChordFinder(fGlobalChordFinder);

Geometry overlap check test and macro

Newly introduced geometry overlap issues should be flagged.

Quartz needs to be implemented

Red warning when reading reading the fieldmaps

This is not really a bug, but bound to be noticed by everyone and commented upon by some (since it's a big red warning; most real errors are just regular color text...)

Warning /home/wdconinc/workspace/remoll/src/remollMagneticField.cc line 271: File map_directory/blockyUpstream_rm_1.1.txt header contains too narrow phi range for given xtants.
Warning:   Proceeding assuming null field in non-described regions
50 deg range < 51.4286 deg xtant

The reason is that the fieldmaps contain only fields through over 50 degrees, while 360/7 = 51.4286 is slightly larger than that. The region not described by the field map is inside the coils itself, so 1) determination of the field is ill-defined, 2) no particles of interest will propagate there, and 3) whatever does propagate in these regions is likely ending up as diffuse background and does not need an accurate simulation (at this point).

Replace std::to_string (C++11 only) with backwards compatible solution

Relevant line

remoll/src/remollGenericDetector.cc

Line 33 in 306a6f6

fMessenger = new G4GenericMessenger(this,"/remoll/SD/det" + std::to_string(fDetNo) + "/","Remoll SD properties for " + name);

Re-add G4Types.hh to remolltypes.hh

Was removed when reroot was added.

ROOT support for remoll GDML import

Todo: Get ROOT to support tags in gdml... or otherwise nothing gets drawn when you import a remoll GDML file in ROOT (better geom tree browser in ROOT, easier for people to use if they don't know remoll or have geant4 allergies).

Solution as bug report to ROOT:

• Copy XMLNodePointer_t TGDMLParse::ConProcess(TXMLEngine* gdml, XMLNodePointer_t node, XMLAttrPointer_t attr) in geom/gdml/src/TGDMLParse.cxx to TGDMLParse::QuanProcess(...) and use GetScale to multiply GetAttrValue("unit").
• Add const char* quanstr = "quantity" and if strcmp handler to TGDMLParse::ParseGDML.

Solution within remoll (ugly):

• Remove all tags and turn them into tags with multiplied unit.

Add CentOS 6.9, gcc 4.4.7, without default C++11 support, to the testing matrix

Qt GUI Development

A GUI needs to be written common with remoll_solid: https://github.com/JeffersonLab/remoll_solid

This should be done Qt, take the important features from GEMC that people like, in addition to being able to select GDML configurations.

Rich Holmes request we be able to study individual events in an output by specifying a seed and an event number.

Fix logicDownstream/tubeDownstream issues (suspected geometry overlap)

During simulation (e.g. test_elastic.mac) the following error occurs (in branch mt, but it's endemic):

*** G4Exception : GeomNav0003
      issued by : G4Navigator::GetGlobalExitNormal()
 WARNING> Expected normal-global-frame to be valid,  i.e. a unit vector!
  - but |normal|   = 3.973405514  - and |normal|^2 = 15.78795138
 which differs from 1.0 by 14.78795138
   n = (3.2294635,-2.314847054,0)
 Global point: (3229.4635,-2314.847054,12786.97813)
 Volume: logicDownstream_PV
 Solid: tubeDownstream, Type: G4Tubs
-----------------------------------------------------------
    *** Dump for solid - tubeDownstream ***
    ===================================================
 Solid type: G4Tubs
 Parameters: 
    inner radius : 0 mm 
    outer radius : 1000 mm 
    half length Z: 3932.84 mm 
    starting phi : 0 degrees 
    delta phi    : 360 degrees 
-----------------------------------------------------------

============================================================
   State of Navigator: 
The current state of G4Navigator is: 
  ValidExitNormal= 1
  ExitNormal     = (3.229,-2.315,0)
  Exiting        = 1
  Entering       = 0
  BlockedPhysicalVolume= None
  BlockedReplicaNo     = -1
  LastStepWasZero      = 1

 Current Localpoint = (3229.4635,-2314.8471,-579.59187)
 PreviousSftOrigin  = (3229.4635,-2314.8471,12786.978)
 PreviousSafety     = 0
Current History: 
History depth=1
Level=[0]: Phys Name=[logicMother_PV] Type=[N]
Level=[1]: Phys Name=[logicDownstream_PV] Type=[N]

============================================================
Value obtained from stored global-normal is not a unit vector.

*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

remollGenExternal needs mutexes

Fix units in QE cross section

Don't rely on hardcoded units...

Travis keeps failing for jlabce 1.2

Related to AnyMethod for G4GenericMessenger. Probably due to const G4String& which used to be buggy... Need to test on ifarm or docker with docker build -t jeffersonlab/remoll . (sudo required).

In file included from /usr/include/Geant4/G4GenericMessenger.hh:36:0,
                 from /home/travis/build/JeffersonLab/remoll/src/remollSteppingAction.cc:7:
/usr/include/Geant4/G4AnyMethod.hh: In instantiation of ‘void G4AnyMethod::FuncRef1<S, T, A0>::operator()(void*, const string&) [with S = void; T = remollSteppingAction; A0 = const G4String&; std::string = std::basic_string<char>]’:
/home/travis/build/JeffersonLab/remoll/src/remollSteppingAction.cc:88:1:   required from here
/usr/include/Geant4/G4AnyMethod.hh:185:12: error: cannot bind ‘std::basic_istream<char>’ lvalue to ‘std::basic_istream<char>&&’
       strs >> a0;
            ^
In file included from /usr/include/c++/4.8/sstream:38:0,
                 from /usr/include/c++/4.8/complex:45,
                 from /usr/include/Geant4/G4Types.hh:67,
                 from /usr/include/Geant4/G4ios.hh:39,
                 from /usr/include/Geant4/globals.hh:49,
                 from /home/travis/build/JeffersonLab/remoll/include/remollSteppingAction.hh:6,
                 from /home/travis/build/JeffersonLab/remoll/src/remollSteppingAction.cc:1:
/usr/include/c++/4.8/istream:872:5: error:   initializing argument 1 of ‘std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&&, _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = const G4String]’
     operator>>(basic_istream<_CharT, _Traits>&& __is, _Tp& __x)
     ^
make[2]: *** [CMakeFiles/remoll-lib.dir/src/remollSteppingAction.cc.o] Error 1
make[1]: *** [CMakeFiles/remoll-lib.dir/all] Error 2
make: *** [all] Error 2

Fix CMakeLists.txt to not compile everything twice

Started at the point when reroot was added in pion branch.

Code fails to compile master on gitinfo error

Checking out a fresh copy of master and trying to compile for the first time hangs up on:
[ 69%] Building CXX object CMakeFiles/remoll.dir/src/remollRunData.cc.o
/home/ciprian/playtime/remoll/src/remollRunData.cc:2:22: fatal error: gitinfo.hh: No such file or directory
#include "gitinfo.hh"
^
compilation terminated.
make[2]: *** [CMakeFiles/remoll.dir/src/remollRunData.cc.o] Error 1
make[1]: *** [CMakeFiles/remoll.dir/all] Error 2
make: *** [all] Error 2
[ciprian@negoiu build]$ grep gitinfo ../src/*
../src/remollRunData.cc:#include "gitinfo.hh"

My guess this is related to this commit:
8619363#diff-52845aab4628b4fe1c66538ffd1ddb39

Format readme file, review content

We should really move to markdown from flat text. Work in progress.

LLVM issue in ROOT 6.10 on ifarm

Error in branch hotfix_issue38_visualization with ROOT 6.10

Error in <UnknownClass::InitInterpreter()>: LLVM SYMBOLS ARE EXPOSED TO CLING! This will cause problems; please hide them or dlopen() them after the call to TROOT::InitInterpreter()!

Can't reproduce on my own systems.

Store hit.t to assess arrival times of hits

In the pion detector, but presumably also the main detectors, we should look at arrival times of photons at the PMT. This will give us a sense of pulse shapes, in particular tails that could lead to pile-up. This is not implemented in remoll, but could be added by storing hit.t = prestep.GetGlobalTime() (pending issue #22).

Option to break down resonances from Christy/Bosted

Resonances from Christy/Bosted need to be individually selectable through the macro (all should be on by default). PV asymmetries should be implemented

Hyperon event generator using Ghent's RPR model

The output from http://rprmodel.ugent.be/calc/ is a lookup table that should be easy to interpolate in between grid points.

Singularity Hub

hey Jefferson Lab! Your container was successfully built but for some reason didn't correctly ping back to the server - it might be my fault because I did a few restarts earlier. I'm on the builder instance and should be able to get it finished up soon.

Ignore warnings about non-existing Tungsten-180 since low abundance

Tungsten's stable isotopes have Z = 74, A = 182-184,186. Somehow geant4 tries to find the cross sections for Z = 74, A = 180. That's a metastable isotope with half-life > age of universe but with a low abundance (0.12%). Presumably the NIST database defines G4_W with this component included, but the scattering cross sections aren't in the data tables because they limit themselves to completely stable isotopes only...

In any case, marking this as WONTFIX and closing right away. Wish there was a way to 'fix' this properly (i.e. hide warnings that do not indicate anything is wrong). Submitting this for future reference.

Example output below:

@@@ G4ParticleHPInelastic instantiated for particle neutron data directory variable is G4NEUTRONHPDATA pointing to /usr/share/geant4/data/G4NDL4.5/Inelastic
@@@ G4ParticleHPInelasticData instantiated for particle neutron data directory variable is G4NEUTRONHPDATA pointing to /usr/share/geant4/data/G4NDL4.5
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
NeutronHP: /Inelastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Inelastic/CrossSection/74_182_Tungsten
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
NeutronHP: /Inelastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Inelastic/CrossSection/74_182_Tungsten
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
NeutronHP: /Inelastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Inelastic/CrossSection/74_182_Tungsten
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
NeutronHP: /Inelastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Inelastic/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
NeutronHP: /Elastic file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Elastic/CrossSection/74_182_Tungsten
@@@ G4ParticleHPInelastic instantiated for particle neutron data directory variable is G4NEUTRONHPDATA pointing to /usr/share/geant4/data/G4NDL4.5/Inelastic
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten
NeutronHP: /Capture file for Z = 74, A = 180 is not found and NeutronHP will use /usr/share/geant4/data/G4NDL4.5/Capture/CrossSection/74_182_Tungsten```

/remoll/SD/det2000/enable requires argument when I intended it not to

/remoll/SD/det2000/enable fails, but /remoll/SD/det2000/enable true or /remoll/SD/det2000/enable false succeeds. What's .SetDefaultValue("true") for then? Argh, too close to (i.e. past) 5pm to look into the docs now.

Accidental commit and push

I just accidentally pushed into JeffersonLab/remoll/develop. I didn't pay enough attention to where my git push was still pointing. This last commit should simply be undone: Commit # 1add254 should be reset back to # 0e37474

Optical photons need to be implemented and have a flag to toggle them

Moller Internal Radiative effects

Moller internal radiation needs to be implemented. This effects the cross sections, but more importantly the energy acceptance

Default beam energy of 11.0 GeV cannot be changed in macros or generators

If I understand correctly, this default choice of the beam energy

remollBeamTarget::remollBeamTarget()
 39 : fBeamEnergy(**gDefaultBeamE**),...............

(

remoll/src/remollBeamTarget.cc

Line 39 in cd7110a

: fBeamEnergy(gDefaultBeamE),fBeamCurrent(gDefaultBeamCur),fBeamPolarization(gDefaultBeamPol),

) to come from the global variable "const double gDefaultBeamE = 11.0*GeV;" in include/remollglobs.hh causes "/remoll/beamene NUMBER GeV" in macros (and in alternate generator source files that also rely on stuff like remollGenBeam's "double E = fBeamTarg->fBeamE;") to fail to change the beam energy.

This may be an issue of the messenger functions not being implemented properly, which I will now check, but regardless of the simplicity of the cause, the /remoll/beamene command is not functioning as advertised (or at least as included in the macros given in the master branch).

Optical surface photo-electric effect properties can't be set in GDML in geant4.10.03

Currently, geant4 does not allow for changing REFLECTIVITY and EFFICIENCY on dielectric_metal optical surfaces (such as the light guide to PMT surface) using just GDML. To solve this with geant4.10.03 and earlier, one has to modify the G4MaterialPropertiesTable associated with the optical surface after reading it in. A first attempt at fixing this was using tags, but they are not parsed for optical surfaces.

A bug report has been submitted to geant4 with a patch for inclusion in a next geant4 release. I'm keeping this issue open until upstream fix has been applied or denied (in which case we will end up with a remollGDMLParser class).

Implications at the remoll level are limited to having a 0% photo-electron efficiency in the photo-cathode of the PMTs of the pion lucite detector. The efficiency is entered in the GDML file, but won't be parsed correctly until the upstream fix is in. remoll will produce a GDML validation warning, but proceed with 0% efficiency and 100% reflectivity for the photo-cathode optical surface.

mt branch: event generators do not respond to /remoll/thmin and /remoll/thmax in macros

When setting theta ranges (and presumably energy, theta COM, phi ranges) in macros, the event generator doesn't receive this information in the multithreading branch. This causes, naturally, the wrong results and is a major bug on mt operation.

Suspected cause is that since event generators are thread-local, /remoll/thmin may set only 1 of the threads (whichever one's messenger is activated) or in no threads at all.

Fixes could involve making the /remoll/thmin messenger and commands part of master thread and getting that info to the individual threads (ugly) or reading up some more on how messengers and threads are supposed to interact. There's a sentence or two in the geant4 migration guide but it's rather brief...

Change in physics output with release v.1.1.0

The physics output after release v.1.1.0 is different from the base v.1.0.0 release and is different from expectations. I attach a couple of plots with direct draws of variables from the output tree for 1000 moller events.

Versions 1.1.1 and 1.1.2 show the exact same behaviour as 1.1.0.

All these plots are for detector 200, but they will produce similar stuff for detector 28 (the detector we use for background analysis).
v1.0.0

v1.1.0

Here are the issues I see:
*The first major issue is that the 7 fold symmetry is somehow broken to 3 fold (see the bottom rows). Selecting electrons (or MOLLER electrons) only does not bring back the 7 fold symmetry.
*Secondly the number of hits per event increases dramatically from ~10 to 700
*Thirdly the ratio of photons to electrons detected changes (for some reason after v1.1.0 there are many more photons)
*Fourthly with v1.1.0 there seem to be hits at two z positions.
*Lastly the time it takes to run the simulation is significantly increased (I guess this is related to point 2 above since G4 has to process so many more hits). v1.0.0 took ~10 s to run while v1.1.0 took about 230 s.

To reproduce this:

git clone [email protected]:JeffersonLab/remoll
cd remoll
git checkout -b v1.0.0 v1.0.0
mkdir build;cd build;cmake ../;make;cd -
build/remoll macros/runexample.mac

Repeat the last 3 lines for v1.1.0, v1.1.1, v1.1.2

I ran these on the same machine with:
GNU 4.8.5
ROOT 5.34/36
G4.10.2.2

Pion branch stores hits with x,y,z outside detector volume

The pion branch stores detectors in the cylindrical disks that act as PMTs. These are only 1 mm thick. However, when running the simulation, hits are created in this detector with a variety of hit.x,y,z values outside the disk. Could this be because we get the x,y,z from the G4Step prestep point? Should we use the poststep point?

Image below should only have hits in the disk shaped region on the right. Hits distributed in the middle and to the left are far outside of the PMT volume.

Merge tracking_C12 and tracking_LH2 into develop

The work that Rupesh has done in these two branches relates to putting GEM foils into the preferred locations. They should be merged into develop at some point. There are also some new event generator work in there (Mott).

Random number seeding: messenger command to set /dev/urandom seed

Right now we set the random seed to something constructed from pid, time and /dev/urandom (talk about overkill) on startup. By default this leads to statistically independent but non-repeatable simulations. I think a better default configuration would be to start from a default fixed seed in remoll.cc, and then have two ways to change the seed in macros:

• /random/setSeeds int[] or /remoll/seeds int (both exist): sets the seeds in a determined way
• /remoll/setSeedToRandom: sets the seeds to whatever comes out of /dev/urandom, guaranteed to be independent/non-repeatable when you call it

Finally, what would be needed is a way to store each event's seed within the tree and allow for reading that value and setting it for simulations. This is slightly more difficult than it seems since setSeeds only sets a fraction of the random number generator internal state (the rest is set to zero). Storing and setting a seed after the fact needs the full random number generator internal state, which is closer to 128 ints if I recall.

Code does not compile on G4.10.01.p01

Looking at:
https://github.com/JeffersonLab/remoll/blob/master/src/remollOpticalPhysics.cc#L87

It seems to me that if I have an earlier version of G4 this code won't compile.

remoll not running from within build directory on branch pion (verified)

Issue reported by Scott. Not all geometry files are copied over to the build directory. A better solution for this may be needed.

The list of files is hard-coded in CMakeList.txt. It could at least be globbed.

But even then, probably we can find an even better solution where we use make install to copy them to remoll/{bin,lib,share}. That would have other advantages too, e.g. installation in /usr/local/ or other versioned directories. Without make install you can still just run build/remoll, for backwards compatibility brownie points.

Implement /remoll/SD/disable to disable all SD

User story: I am only interested in one detector. I would then like to execute:

/remoll/SD/disable
/remoll/SD/det2000/enable

TFoam support for MC event generator

There is already an event generator that takes MC output files and generates events starting from those events as input (e.g. factorization of lead wall showering and post lead wall optical simulation for pion detector). This suffers from limited event statistics unless we recycle events.

TFoam would be able to generate by x,y,z,theta,phi,E distributions representative of those events.

Other uses:

• Pre-scattering energy loss as simulated by Geant4 itself: run delta(E) beam into the target in a separate simulation, store all hits in target volume, pick and interpolate according to proper energy loss distribution. This would get away from models for energy loss implemented in our code and instead rely on the physics available in Geant4 materials definitions.
• Fast optical generation: run flat electron field in x,y,theta,phi onto a single quartz module, store resulting PE distribution, then run non-optical simulations and interpolate without need for optical simulation while still getting distribution correct. Full simulations are always possible, but the idea is that this would be 1000 times faster.

Random seeds fail, every single run of remoll uses the same exact set of seeds

The seeds set by line 64 of remoll.cc do not affect the seeds that are used by remoll while running, in fact, the seeds never change across different runs.

What am I doing wrong? Has this been fixed already? Can the solution be added to the README?

remoll/remoll.cc

Line 64 in 3223485

seed += devrandseed;

Depolarization Effects

Depolarization based on external beam radiation needs to be implemented

Random segfaults during runtime at the end of the Event Action - default remoll/develop behavior

Running remoll with a macro fails sometimes. The stack trace is below:

remoll/src/remollEventAction.cc

Line 72 in 7f06b5b

io->FillTree();

There was a crash.
This is the entire stack trace of all threads:

Thread 3 (Thread 0x2b7f2fba0700 (LWP 46231)):
#0 0x0000003402a0e264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0000003402a09508 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x0000003402a093d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x000000000045fe9d in G4TemplateAutoLock<pthread_mutex_t, G4int ()(G4Mutex), G4int ()(G4Mutex)>::lock (this=0x2b7f2fb36f80) at /share/apps/geant4/geant4.10.01.p03-install/include/Geant4/G4AutoLock.hh:90
#4 0x000000000045f777 in G4TemplateAutoLock<pthread_mutex_t, G4int ()(G4Mutex), G4int ()(G4Mutex)>::G4TemplateAutoLock (this=0x2b7f2fb36f80, mtx=0x6dc760, l=0x453e28 <pthread_mutex_lock
plt>, u=0x453d58 <pthread_mutex_unlock
plt>) at /share/apps/geant4/geant4.10.01.p03-install/include/Geant4/G4AutoLock.hh:74
#5 0x000000000045f0f8 in G4ImpMutexAutoLock::G4ImpMutexAutoLock (this=0x2b7f2fb36f80, mtx=0x6dc760) at /share/apps/geant4/geant4.10.01.p03-install/include/Geant4/G4AutoLock.hh:113
#6 0x0000000000464b0e in remollEventAction::EndOfEventAction (this=0x2b7f340c9450, aEvent=0x2b7f344dcda0) at /home/cameronc/gitdir/remoll/src/remollEventAction.cc:31
#7 0x00002b7f2782649c in G4EventManager::DoProcessing(G4Event*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4event.so
#8 0x00002b7f275d516c in G4WorkerRunManager::ProcessOneEvent(int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#9 0x00002b7f275d57d9 in G4WorkerRunManager::DoEventLoop(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#10 0x00002b7f275cbc5c in G4RunManager::BeamOn(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#11 0x00002b7f275ddc20 in G4MTRunManagerKernel::StartThread(void*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#12 0x0000003402a079d1 in start_thread () from /lib64/libpthread.so.0
#13 0x00000034022e88fd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x2b7f30ba1700 (LWP 46232)):
#0 0x00000034022ac65d in waitpid () from /lib64/libc.so.6
#1 0x000000340223e609 in do_system () from /lib64/libc.so.6
#2 0x000000340223e940 in system () from /lib64/libc.so.6
#3 0x00002b7f21eee608 in TUnixSystem::StackTrace() () from /share/apps/root/lib/libCore.so
#4 0x00002b7f21eed483 in TUnixSystem::DispatchSignals(ESignals) () from /share/apps/root/lib/libCore.so
#5
#6 0x00002b7f23061ee0 in TBufferFile::WriteFastArray(int const*, int) () from /share/apps/root/lib/libRIO.so
#7 0x00002b7f24a75d3d in TBranch::FillLeavesImpl(TBuffer&) () from /share/apps/root/lib/libTree.so
#8 0x00002b7f24a7810a in TBranch::Fill() () from /share/apps/root/lib/libTree.so
#9 0x00002b7f24ac7225 in TTree::Fill() () from /share/apps/root/lib/libTree.so
#10 0x0000000000484247 in remollIO::FillTree (this=0x2b7f2e070010) at /home/cameronc/gitdir/remoll/src/remollIO.cc:168
#11 0x0000000000464ce8 in remollEventAction::EndOfEventAction (this=0x2b7f380c93e0, aEvent=0x2b7f384dc670) at /home/cameronc/gitdir/remoll/src/remollEventAction.cc:72
#12 0x00002b7f2782649c in G4EventManager::DoProcessing(G4Event*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4event.so
#13 0x00002b7f275d516c in G4WorkerRunManager::ProcessOneEvent(int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#14 0x00002b7f275d57d9 in G4WorkerRunManager::DoEventLoop(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#15 0x00002b7f275cbc5c in G4RunManager::BeamOn(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#16 0x00002b7f275ddc20 in G4MTRunManagerKernel::StartThread(void*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#17 0x0000003402a079d1 in start_thread () from /lib64/libpthread.so.0
#18 0x00000034022e88fd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x2b7f2d206be0 (LWP 46205)):
#0 0x0000003402a0b5bc in pthread_cond_wait

GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00002b7f275d1631 in G4MTRunManager::WaitForEndEventLoopWorkers() () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#2 0x00002b7f275d0d7d in G4MTRunManager::RunTermination() () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#3 0x00002b7f275cbc65 in G4RunManager::BeamOn(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#4 0x00002b7f275e0160 in G4RunMessenger::SetNewValue(G4UIcommand*, G4String) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#5 0x00002b7f2a9ffebb in G4UIcommand::DoIt(G4String) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#6 0x00002b7f2aa0c357 in G4UImanager::ApplyCommand(char const*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#7 0x00002b7f2a9f1827 in G4UIbatch::ExecCommand(G4String const&) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#8 0x00002b7f2a9f27ab in G4UIbatch::SessionStart() () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#9 0x00002b7f2aa09fd3 in G4UImanager::ExecuteMacroFile(char const*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#10 0x00002b7f2aa05318 in G4UIcontrolMessenger::SetNewValue(G4UIcommand*, G4String) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#11 0x00002b7f2a9ffebb in G4UIcommand::DoIt(G4String) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#12 0x00002b7f2aa0c357 in G4UImanager::ApplyCommand(char const*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4intercoms.so
#13 0x0000000000455253 in main (argc=2, argv=0x7fff722f6b48) at /home/cameronc/gitdir/remoll/remoll.cc:138

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
#6 0x00002b7f23061ee0 in TBufferFile::WriteFastArray(int const*, int) () from /share/apps/root/lib/libRIO.so
#7 0x00002b7f24a75d3d in TBranch::FillLeavesImpl(TBuffer&) () from /share/apps/root/lib/libTree.so
#8 0x00002b7f24a7810a in TBranch::Fill() () from /share/apps/root/lib/libTree.so
#9 0x00002b7f24ac7225 in TTree::Fill() () from /share/apps/root/lib/libTree.so
#10 0x0000000000484247 in remollIO::FillTree (this=0x2b7f2e070010) at /home/cameronc/gitdir/remoll/src/remollIO.cc:168
#11 0x0000000000464ce8 in remollEventAction::EndOfEventAction (this=0x2b7f380c93e0, aEvent=0x2b7f384dc670) at /home/cameronc/gitdir/remoll/src/remollEventAction.cc:72
#12 0x00002b7f2782649c in G4EventManager::DoProcessing(G4Event*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4event.so
#13 0x00002b7f275d516c in G4WorkerRunManager::ProcessOneEvent(int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#14 0x00002b7f275d57d9 in G4WorkerRunManager::DoEventLoop(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#15 0x00002b7f275cbc5c in G4RunManager::BeamOn(int, char const*, int) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#16 0x00002b7f275ddc20 in G4MTRunManagerKernel::StartThread(void*) () from /share/apps/geant4/geant4.10.01.p03-install/lib64/libG4run.so
#17 0x0000003402a079d1 in start_thread () from /lib64/libpthread.so.0
#18 0x00000034022e88fd in clone () from /lib64/libc.so.6

/opt/gridengine/default/spool/compute-0-0/job_scripts/2777: line 6: 46205 Segmentation fault (core dumped) ../../remoll ../../macros/runexample_dump.mac

Implement new raster in all branches

The new raster with an origin upstream needs to be implemented in all branches. In particular, making sure the beam generator includes those effects is critical.

G4 navigator can't find proper unit vector

I'm on a RHEL7 gcc 4.8.5, ROOT 5.34/36, G4.10.2.2. Fresh copy of the repo.
This has been reproduced on a MacOS, clang 6.0.0.6000057, G4.10.1.1, ROOT 5.34/36

It seems that there may be some mistake in the default geometry (overlaps maybe?) as the navigator can't find a proper normal vector:

History depth=1

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomNav0003
      issued by : G4Navigator::GetGlobalExitNormal()
 WARNING> Expected normal-global-frame to be valid,  i.e. a unit vector!
  - but |normal|   = 2.073115653  - and |normal|^2 = 4.29780851
 which differs from 1.0 by 3.29780851
   n = (-1.921000488,0.7794649667,0)
 Global point: (-1921.000488,779.4649667,10188.68862)
 Volume: logicDownstream_PV
 Solid: tubeDownstream, Type: G4Tubs
-----------------------------------------------------------
    *** Dump for solid - tubeDownstream ***
    ===================================================
 Solid type: G4Tubs
 Parameters: 
    inner radius : 0 mm 
    outer radius : 1000 mm 
    half length Z: 3932.84 mm 
    starting phi : 0 degrees 
    delta phi    : 360 degrees 
-----------------------------------------------------------

============================================================
   State of Navigator: 
The current state of G4Navigator is: 
  ValidExitNormal= 1
  ExitNormal     = (-1.921,0.7795,0)
  Exiting        = 1
  Entering       = 0
  BlockedPhysicalVolume= None
  BlockedReplicaNo     = -1
  LastStepWasZero      = 1

 Current Localpoint = (-1921.0005,779.46497,-3177.8814)
 PreviousSftOrigin  = (-1921.0005,779.46497,10188.689)
 PreviousSafety     = 0
Current History: 
Level=[0]: Phys Name=[logicMother_PV] Type=[N]
Level=[1]: Phys Name=[logicDownstream_PV] Type=[N]

============================================================
Value obtained from stored global-normal is not a unit vector.

*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

I get similar warnings for tubeUpstream as well.

Hyperon Decays

Hyperon decays need to be implemented via work by K. Aniol

Setting kryptonite to false in macro claims to still treat tungsten and copper as kryptonite (but not lead)

When changing the macro kryponite setting to false these lines (and a random number of them, always appearing in such pairs) appear at runtime, suggesting that kryptonite is being set to true (I'm not sure the best way to verify this other than plopping a block of tungsten somewhere sensitive), contrary to the macro settings:

G4WT0 > --> Event 0 starts with initial seeds (70003157,20804345).
G4WT0 > Loading kryptonite materials table...
G4WT1 > Loading kryptonite materials table...
G4WT0 > Treating Tungsten as kryptonite.
G4WT1 > Treating Tungsten as kryptonite.
G4WT0 > Treating Copper as kryptonite.
G4WT1 > Treating Copper as kryptonite.
G4WT0 > Treating Tungsten as kryptonite.
G4WT1 > Treating Tungsten as kryptonite.
G4WT0 > Treating Copper as kryptonite.
G4WT1 > Treating Copper as kryptonite.

I do not know why lead doesn't show up here too.

This may be related to some segfault problems I am encountering elsewhere, but I cannot say for certain yet.

remoll/macros/runexample.mac

Line 59 in c45cfb3

/remoll/kryptonite true

Visualization does not work out of the box

To quote the readme:

Visualization macros are found in vis/
To run, execute
./remoll
which should bring up a graphical command interface
To see the geometry you have to say:
/run/initialize
then
/control/execute macros/vis.mac

I'm on a RHEL7 gcc 4.8.5, ROOT 5.34/36, G4.10.2.2. Fresh copy of the repo.

Running the visualizer from the main directory or the build directory gives:

***** Illegal application state </remoll/setgeofile geometry_dose/mollerMother.gdml> *****
***** Batch is interrupted!! *****