RawG4Event.hh Causing Compiling Error?

[evan012345]

Hey Guys, Who is in charge of the RawG4Event.hh stuff? I can't compile because I can't find/have Math/InterpolationTypes.h or Math/Interpolator.h. What are those headers? Do we need them?

[evan012345]

@moukaddam, is this the code you added?

[bkatiemills]

@evan012345, can you post the exact compilation failure? @evitts, can you check and see if it's the same problem you reported to me on Friday?

There are going to be some hiccups while we manage this huge merge of the SPICE framework - Evan, do please keep pointing these problems out so we can get them ironed out as quickly as possible. Avoiding these situations is why I bug you guys about frequent, gradual merges - nevertheless, these things happen, we'll get it sorted soon.

[evan012345]

I haven't been avoiding this, just downloaded the latest merge today. I didn't want to just comment this stuff out to get it to compile since this would probably make @moukaddam unhappy. The compilation error is below:

local1@localhost (~/Geant4-Builds/GitHub) > sh makeit.sh
-- G4 Examples: HBOOK package not found. --> g4tools/hbook analysis disabled
-- Configuring done
-- Generating done
-- Build files have been written to: /home/local1/Geant4-Builds/GitHub
[  2%] Building CXX object CMakeFiles/detectionSystems.dir/detectionSystems.cc.o
In file included from /mnt/hgfs/GitHub/detectorSimulations/include/RootManager.hh:17,
                 from /mnt/hgfs/GitHub/detectorSimulations/detectionSystems.cc:43:
/mnt/hgfs/GitHub/detectorSimulations/include/RawG4Event.hh:22:37: error: Math/InterpolationTypes.h: No such file or directory
/mnt/hgfs/GitHub/detectorSimulations/include/RawG4Event.hh:23:31: error: Math/Interpolator.h: No such file or directory
In file included from /mnt/hgfs/GitHub/detectorSimulations/detectionSystems.cc:43:
/mnt/hgfs/GitHub/detectorSimulations/include/RootManager.hh:18:83: error: /opt/DetectorSimulations/detectorSimulations/dataRootClass/TSpiceData.h: No such file or directory
/mnt/hgfs/GitHub/detectorSimulations/include/RootManager.hh:43: error: ISO C++ forbids declaration of ‘TSpiceData’ with no type
/mnt/hgfs/GitHub/detectorSimulations/include/RootManager.hh:43: error: expected ‘;’ before ‘*’ token
/usr/local/clhep/2.1.3.1/include/CLHEP/Units/PhysicalConstants.h:80: warning: ‘CLHEP::electron_charge’ defined but not used
/usr/local/clhep/2.1.3.1/include/CLHEP/Random/Randomize.h:68: warning: ‘CLHEP::HepRandomGenActive’ defined but not used
make[2]: *** [CMakeFiles/detectionSystems.dir/detectionSystems.cc.o] Error 1
make[1]: *** [CMakeFiles/detectionSystems.dir/all] Error 2
make: *** [all] Error 2
local1@localhost (~/Geant4-Builds/GitHub) >

[bkatiemills]

Great, thanks Evan - to clarify, I wasn't suggesting you were avoiding anything; I just meant 'we can avoid messing Evan (and everyone else) up by making small, frequent merges.' Sorry that wasn't clear.

Anyway, I bet this is a simple one for @moukaddam to fix - looks like some stuff of his just didn't get git add'ed when he pushed - Mohamad, let us know!

[ghost]

@moukaddam can confirm but I believe you need to 'make' within the dataRootClass folder prior to compiling the rest of the code

[bkatiemills]

Sounds like we need some 'how to build' docs - I will throw something down after @moukaddam comments.

[evan012345]

I tired making the dataRootClass before making the detectorSimulations but still didn't compile, same error as before. However the dataRootClass built properly.

Forgive my ignorance, I haven't looked at this code too closely, but it appears to be very specialized. How come this code is built into the Geant4 code, and not a separate root code? For example, output all the Geant4 data into a root tree using ntuples, then use your own analysis root code to sort it the way you need it? We now have two classes, HistoManager and RootManager, that makes two independent root trees.

[moukaddam]

headers problem : @evan012345 @bill @Lee I had to clean the headers before, sorry for this, I'll make a new commit, but first can you please test if you have the same compilation error after you replace the headers in RawEventClass with the list below :

{
#ifndef _RAWEVENT_CLASS
#define _RAWEVENT_CLASS
//Root
//#include "Riostream.h"
#include "TVector3.h"
//c++
#include "vector"
#include "iostream"
#include "map"
#include "utility"
using namespace std;
//g4              
#include "globals.hh" 
}  

And the RootManager with this one (Only one line is added)

{
#ifndef ROOTMANAGER_H 
#define ROOTMANAGER_H 1
//c++
#include <iostream>
#include <map>
#include <ctime>
using namespace std ;
//ROOT
#include "TFile.h"
#include "TH1.h"
#include "TTree.h"
//User
#include "RawG4Event.hh"
#include "/path/to/dataRootClass/TSpiceData.h"
}

[bkatiemills]

I was told that the recent additions were designed to output a root tree rather than a collection of flat histograms. @evan012345, if you're saying that your HistoManager can provide this functionality already, then I agree, the SPICE code should make better use of it and the rest of the existing infrastructure. I would like @moukaddam and @evitts to please comment, today, on their code, list what it is intended to do, and explain why the existing infrastructure can't support it. Evan, I'll need your expert help reviewing these comments; if it appears that the SPICE team has reimplemented a bunch of things that didn't need to be reimplemented, we will revert those changes and try again to merge their work, this time more gradually.

Thanks for everyone's patience here. Huge merges cause huge disruptions, but I think we can get back to normal soon.

[moukaddam]

Basically you have three classes

RootManager is the bridge to "communicate" between Geant and ROOT

• You can look at it as the "chef d'orchestre"
• creates the Tree and connect the Tree to the writing or container Root Class(es)
• It draws the data from Geant (at this stage the g4 event is just a lot of bits of energy, positions, momenta.. in several segments) and store them in a c++ map of RawG4Event class where you can do further analysis that are NOT related to "physics" but more likely to reshape the raw event and transform it to a "close to reality" event

In RawG4Event

• separate the segments if the event fold is higher than unity and work separately on them
• add the energies of all the hits in one segment
• and store other information need for simulation analysis like the pdg of the primary event particle, or even the daughter particles,
• there's also room for other stuff...

TSpiceData which is writing Root class (a container):

• It is very specific for Spice and is intended to be this way
• Each event in Geant has a key, and each key belong to a detector or a segment of detector,
• when the key matches a spice event,the RootManager::SetSpiceEvent will be called to do further analysis that is specific to this detector
• And than fill the spice container which has its own branch in the output tree.
• The same thing could be done to other detector but their "container Classes" needs to be written.

I lean for a tree of containers and variables where you can use all the aces of the ROOT Tree. Also encapsulating each event in a container specific for a detector is easier for analysis. Finally the classes above are not perfect and your contribution/comment are welcome. However, the code design can be changed EASILY. It's open for debate, but I intend to defend this logic of:

• one class being the bridge (RootManager)
• use of root tree in the output
• use separate classes or containers for each detector This way is very "democratic" since each person can make his own class for the detector he is developing.

One potential Idea is that we can also make the output looks like a FragmentTree (Raw tree from MIDAS) that we are producing in GRSISpoon. And then use our analysis codes on the "real life" simulated tree.

[ghost]

In response to @BillMills and to give you an idea of the final merge, my fork is a simple merging of functions/files between detectionSystems/SPICE. These changes are not yet present in Mhd's commit. I can not list every change, but the main differences are:

• ApparatusSpiceTargetChamber [Updated geometry]
• DetectionSystemS3 [New]
• DetectionSystemSpice [Updated]
• DetectorConstruction [To build/place the S3/SiLi]
• PrimaryGeneratorAction [A couple of extra functions to emit particles at desired energies, could potentially be merged with other present functions but shouldn't be clashing for now]
• SensitiveDetector [Spice uses the SensitiveDetector class]
• TabulatedMagneticField [New]
• TrackingAction [New]

I copied over a couple of the root related files too but I believe Mhd has changed them in his commit. I'll update you if I remember any other changes.

[bkatiemills]

@moukaddam In general I am a fan of what you're trying to do here. I agree with you (and insist) that output be generated as a tree; I also like the pattern you're proposing WRT per-detector output classes - in software we call that 'encapsulated', but 'democratic' is just as good. And I also consider being able to output fragments that are identical in structure to real data to be a requirement of the simulation, and has been a long term goal that I have been discussing with @r3dunlop for some time now.

However, @evan012345 has an important point - it's not clear if we need entirely new infrastructure to do this. Evan, can you please comment on the existing tree implementation and whether you think it can be more naturally modified to accommodate what the SPICE team proposes?

Regardless of what we decide on how to move forward, we absolutely must address the original topic of this thread quickly, and get things compiling and running again for the Guelph team ASAP. If we can't, then we may have to push this development to an auxiliary branch, which was a complication I was trying to spare you - but it may be necessary if we can't unblock things for Guelph quickly.

@evitts Sounds good - per our discussion offline, we will be going with your implementations of the detector systems relevant to SPICE, and will get that sorted and integrated once things calm down a little here.

[evan012345]

I don't doubt this is really important code, however it seems more like an analysis code than Geant4 code. It also seems like we have to make this dataRootClass program before we can compile the Geant4 code (when we get it working), even if we are not using SPICE. That seems counter-productive for non-SPICE users.

As I mentioned in our emails last week, the HistoManager supports ntuple root trees, I believe this is the most basic type of tree. Ntuples are basically excel spreadsheets in root. 'N' number of columns which can be anything, ie. deposited energy, event number, detector number, segment number, position, ... And the rows correspond to an event or a step, whatever you want. Every step would show you the particles bouncing around in your geometry, whereas each event would give you the result of all steps until the particle comes to a rest. Most of the time we only care about events (and this is faster than tracking each step), but for some more complicated analysis we may need the step information.

From the basic ntuple root tree we can make other more complicated trees - this would be a separate analysis code that is run after the Geant4 simulation. My question was, do we need these new classes? Or can you achieve what you want from ntuples? If you need more specialized trees, is it too time consuming to make your trees from the ntuple trees?

Also, I would argue that nearly every #include in RawG4Event.hh is redundant, that's more than two dozen includes. All the root functionality in Geant4 is contained in #include "g4root.hh", that should be the only include we need (see HistoManager). It appears this code was a stand-alone root code that has been cut-and-pasted into the Geant4 code. That's why I'm saying it looks more like an analysis code than a required part of the Geant4 code.

This is a discussion we will probably continue to have time and time again. Every group that wishes to use the GRIFFIN / TIGRESS Geant4 code is going to want to do something specific to them. Do we support every groups requirements for output, or do we keep the Geant4 code as general as possible and have groups run their own separate "analysis/sort" codes? I don't have a definite answer here, and we should decide this as a collaboration. There are pros and cons to each. Ideally every group is going to want the Geant4 output to look like and have the same format as the output from their real experiment.

[evan012345]

@BillMills I don't think the simple ntuple root trees are sufficient for the SPICE team proposes. Which is why @moukaddam married the root functionality with Geant4 using the RootManager as the bridge. There is nothing wrong with this, and I am impressed it works! The issue I see is we are now outside the Geant4 world and cross-breeding with "external" root. We will be more susceptible to library issues, etc. Arguably not a huge problem since we most likely all have root on our machines, but it's not a given.

I don't want to seem biased, or promote one view or another. Anyone can do anything they want with the code, but if it's going to be contributed to the main branch, it needs to be run-able by everyone. Which becomes a bit more dangerous when we start marrying libraries.

[bkatiemills]

A couple of comments:

• I think everyone agrees on the central point that the simulation output should look like real data - so let's stick to that as our guiding principle for output format.
• I think there is some confusion here between code being analysis specific, and code being hardware specific. I absolutely agree that analysis specific code has no place in this project; analyses should be completely decoupled from simulations. However, I don't have a problem with hardware specific code, which is I think what @moukaddam is proposing here; each device has its own output class, that spits out data in the same format as the real data stream. I can tell you for sure that hardware-specific ROOT classes are how data is getting written by the real DAQ - implementing the same pattern here only serves my first bullet.
• Production scale simulations should be able to produce the DAQ-style output without an additional processing step.
• If there are redundant includes, they have to be eliminated. Lets get things compiling for everyone, then we can tease out benign but superfluous code.

We should also pay attention to continuity of analyses here - we may ultimately only support the real DAQ style output, but we can't torpedo any ongoing projects using the existing ntuple; both need to be supported, at least for now.

@evan012345 I also agree that this has to be runnable by everyone. @moukaddam, we are going to move in the direction you propose, but I need you to help the Guelph team get compiling and running ASAP. If no progress is made on this by tomorrow 5 PM Vancouver time, I am pushing your modifications out into a development branch, off of master (I will show you and @evitts how to work with a side branch at your convenience); we will re-merge at a later date, when things are a bit more settled.

[evan012345]

Thanks for commenting @BillMills. Just so I'm clear, those redundant includes are NOT redundant if we want to use EXTERNAL ROOT libraries. They are redundant if we want Geant4 to handle our ROOT trees for us. I would argue, when possible, to let Geant4 handle making, filling, etc, the ROOT trees. I don't claim to be a Geant4/ROOT expert, so I'm not sure if Geant4 has all the capabilities to make the trees the SPICE team needs. We may very well need additional ROOT libraries and classes to achieve what they need, which means marrying the two codes together.

[evan012345]

I took advantage of where I am to ask a real expert. I'm currently at Stanford attending a Geant4 workshop. It turns out Geant4 can not make complicated ROOT files. Geant4 plateaus at making ntuples, that is the most complicated tree Geant4 can handle. If we want to make more complicated trees we need to start marrying ROOT libraries.

Word of warning (as was told to me), when you leave the Geant4 world and start letting ROOT fill its own trees it will no longer be thread safe. The current version of Geant4 we are using (Geant4 9.6.p02) does not use threads, so we are fine. But the new version 10 is based on threads, and if we use external code to fill trees we can expect bad things to happen.

I agree we need DAQ-style output, and that should be a priority.

[moukaddam]

@evan012345 let me know if you still have any problems and see if we can sort them out at least for now. If we cant fix it tomorrow (a very busy day for me) we can continue on the branch if needed.

Compiling issue : I guess implement a line in the cmake to compile everything on the fly could fix the problem.

Analysis issue:

• Apart from the angle of the primary event with the beam axis, there's no real analysis. all what I was trying to do was to collect the energies, positions and some other information in a structure that is based on segment by segment. Basically, in the final tree, I only have the touched segment, the energy in this segment and some other raw information from G4 (e.g. angles and primaries pdg and a room for other things).
• If we produce a root Ntuple, we still need Root to look at it. So having root libraraies or not is not the main problem.

Concerning the final decision:

• I can't argue with the threading, I'm also not an expert on this issue and eventually we want to move to the new version. So a long term decision should be taken.
• I understand that some users would like to have the Ntuple tree the way it is. So a transition code between Ntuple and proper tree might be the final solution. However, in my opinion, having a lot of transition codes is not the best thing to have but I understand that there's many users.

I really have no problem in switching, but we need to understand well what we really want. Here's what I wanted to have and my understanding for what will happen:

• I want to have a "reality" output tree where you can plot things in a powerful way without going through making a "Macro per plot". This was the case before as far as I know.
• Also I wanted to have a design where you can draw coincidence between the detectors. It's not only about one detector: e.g. segment in Griffin Vs segment in Spice. If we don't have different branches we cant do this.
• The Ntuple will not give us this luxury directly, unless if we start another project taking the Ntuple as input to make a "reality" data trees (e.g. full deposited energy per segment etc...)
• So if I want to "link" the present situation with our final goal it would be something like this: [legend of symbols : (=>) for a product, (->) for input]

DetectorSimulation => Ntuple ->Transition Code

= > (output 1 : main goal) MIDAS-Fragment-Tree-Like ->GRSIspoon =>Simulated GRSISpoon-analyzed-Tree-Like = > (output 2) Simulated "reality" tree

• The second output is important for us, because the MIDAS-Fragment-Tree-Like (which is the real DAQ style output) is like the ntuple where you have the same structure for any event from any detector. So we should "GRSISpoon" it before we start playing with coincidences. And I guess it's important to have the ability to plot sensible stuff right after the simulation.

Conclusion : I can go with Ntuple or the root tree, but we need to plan well what we need in the long term.

[evan012345]

@moukaddam I totally agree with everything you outlined above. I see it as a "pick your poison" decision. Either change to ntuples and have to use a sort code outside Geant4, or keep the existing code and worry about any library or thread issues in the future.

Once @BillMills merges your pull request I'll try compiling the new code and let you know if I can compile it or not.

[bkatiemills]

Good, good - I see we all understand and agree on strategy here. Flexible plotting, coincidences and a data format consistent with GRSISpoon's post-sorting output are all long-term musts for this simulation - @moukaddam has implemented the foundational elements of this, and that is the direction we will move.

@evan012345, thanks for looking into the external ROOT issue with the experts (very thoughtful of you to happen to be at a Geant conference right now!). This is a serious concern, but I consider it a substantial weakness of Geant which I will not allow this project to be held back by; we will have to work around it when the time comes. I suspect (and please, let me know if I'm imagining this wrong), that the multithreaded capabilities of 10.0 are designed to support parallel processing for high-statistics production-scale simulations. If so, this is a convenience feature that can be replaced with lots of single-thread simulations farmed out by a batch system; it's a bit more external infrastructure, but only just barely and a worthy price to pay.

I will be trying to coerce the current master head into compiling today. If I can't get it to go, we'll open a development branch for these features as discussed. @evan012345, in the event that I do get it to compile, I would like to run whatever macros you are trying to look at to make sure everything is happy at runtime too - get the pertinent files to me so I can check this out for you.

[bkatiemills]

Alright - the simulation is compiling for me on alphadon. #67 implements some of the header changes recommended by @moukaddam above, which was the only change necessary for me to compile.

(GitHub superuser protip: in your posts, escape your code between ``` quotes in a new paragraph - that way things like "include <awesome.h>" won't get interpreted as HTML and disappear :)

Unfortunately, I wasn't able to reproduce @evan012345's error regarding Math/InterpolationTypes.h; I am going to look into that now, but it must be some environment setup problem. If we have learned anything from this exercise, it should be that compile guides are desperately needed for complicated packages like this one.

This is successful enough that we can defer branching the new features for a day or two while we try and nail down @evan012345's problem, particularly since he's travelling right now. Will post again shortly (I hope) with some strategy on what to do about Math/InterpolationTypes.h.

[evan012345]

Still does not compile on my machine. Errors below. For completeness I'm running Scientific Linux 5.8, ROOT version 5.34/03, Geant4 9.6.p02.

local1@localhost (~/Geant4-Builds/GitHub) > cmake -DGeant4_DIR=$G4LIB/Geant4-9.6.2 /mnt/hgfs/GitHub/detectorSimulations
-- G4 Examples: HBOOK package not found. --> g4tools/hbook analysis disabled
-- Configuring done
-- Generating done
-- Build files have been written to: /home/local1/Geant4-Builds/GitHub
local1@localhost (~/Geant4-Builds/GitHub) > make
[ 2%] Building CXX object CMakeFiles/detectionSystems.dir/detectionSystems.cc.o
In file included from /mnt/hgfs/GitHub/detectorSimulations/include/RootManager.hh:18,
from /mnt/hgfs/GitHub/detectorSimulations/detectionSystems.cc:43:
/mnt/hgfs/GitHub/detectorSimulations/include/RawG4Event.hh:22:37: error: Math/InterpolationTypes.h: No such file or directory
/mnt/hgfs/GitHub/detectorSimulations/include/RawG4Event.hh:23:31: error: Math/Interpolator.h: No such file or directory
/usr/local/root/5.34.03/include/root/TObject.h:108: warning: ‘virtual void TObject::Clear(const Option_t*)’ was hidden
/mnt/hgfs/GitHub/detectorSimulations/include/../dataRootClass/TSpiceData.h:54: warning: by ‘void TSpiceData::Clear()’
make[2]: *** [CMakeFiles/detectionSystems.dir/detectionSystems.cc.o] Error 1
make[1]: *** [CMakeFiles/detectionSystems.dir/all] Error 2
make: *** [all] Error 2
local1@localhost (~/Geant4-Builds/GitHub) >

[evan012345]

@BillMills I'll look into this error, see if there is an easy fix. It's a clear library header error. Since we are now going outside the Geant4 libraries we have to be careful, or run identical machines.

[bkatiemills]

I am a big fan of identical machines; I insisted on a consistent setup on all the GRSI machines at TRIUMF. @carlu @damiller could probably spec this for you if you want to do the same - it might be overkill since you aren't running MIDAS, but it would guarantee that anything that works for us will work for you.

I will also poke at this error after my meetings today - let me know what you come up with and I'll do the same.

[carlu]

All the newer TRIUMF machines which we use for GRSISpoon are running Scientific Linux 6.x. x is 4 or 5 in most cases. These have gcc versions around 4.4.7 or so, although 4.7.2 works fine on my Ubuntu machine.

For a root version we agreed on 5.34.14 as our standard for now. Although several earlier versions of 5.34 have been confirmed to work eg 5.34.05

On 5 March 2014 12:20, Bill Mills notifications@github.com wrote:

I am a big fan of identical machines; I insisted on a consistent setup on all the GRSI machines at TRIUMF. @carlu https://github.com/carlu @damiller https://github.com/damiller could probably spec this for you if you want to do the same - it might be overkill since you aren't running MIDAS, but it would guarantee that anything that works for us will work for you.

I will also poke at this error after my meetings today - let me know what you come up with and I'll do the same.

Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/detectorSimulations/issues/66#issuecomment-36788606 .

[evan012345]

I have the Guelph group running on identical VMs provided by the IN2P3 group (http://geant4.in2p3.fr/spip.php?rubrique8&lang=en). They provide a virtual machine with Scientific Linux OS with Geant4 already installed including CLHEP, ROOT, Qt, OpenGL, HepRApp, DAWN, WIRED, etc.

[damiller]

It looks like to me that the Interpolator is part of the MathMore ROOT library extension. I'm not positive, but I think that this might depend on GSL being installed. Surprisingly, GSL doesn't seem to be installed by default in the scientific linux distro. I'd check on the IN2P3 virtual machines via

$ root-config --has-mathmore

[bkatiemills]

@evan012345, in my build directory, I have the file CMakeFiles/detectionSystems.dir/flags.make; inside this file is a bunch of flags for the C compiler. In particular, CXX_FLAGS contains a flag -I/home/wjmills/packages/root/include; this is the path that Math/InterpolationTypes.h lives under on my machine. Is there an analogous flag in yours that points at your ROOT build?

If not, there must have been some env variable undefined when you create the makefile; what is the value of your $ROOTSYS and $PATH variables? @moukaddam, do you have any other ideas on where this compile flag comes from?

[bkatiemills]

Good catch @damiller - my root-config --has-mathmore returns yes - how about you, @evan012345?

[moukaddam]

@evan012345 Have you tried without the interpolator header? I have already posted what headers are needed above, the other headers are relics from another code, that should be cleaned..

[moukaddam]

@evan012345, I cleaned the extra header, try this https://github.com/moukaddam/detectorSimulations.git

[bkatiemills]

Excellent - making only those changes to RawG4Event.hh removes the dependence on mathmore and still compiles for me; @moukaddam, why don't you merge that change now - it may solve @evan012345's problem, and even if it doesn't we shouldn't be carrying around all those unnecessary includes anyway.

[evan012345]

root-config --has-mathmore returns no

I tried https://github.com/moukaddam/detectorSimulations.git and it fails to compile because of the header "#include "/opt/DetectorSimulations/detectorSimulations/dataRootClass/TSpiceData.h" in RootManager.hh. If I change this include to "#include "../dataRootClass/TSpiceData.h" it gets a lot farther along in the compiling process, but eventually fails returning the following:

local1@localhost (~/Geant4-Builds/GitHub) > make
Linking CXX executable detectionSystems
/usr/local/root/5.34.03/include/root/TObject.h:108: warning: ‘virtual void TObject::Clear(const Option_t*)’ was hidden
/mnt/hgfs/GitHub/detectorSimulations/dataRootClass/TSpiceData.h:54: warning:   by ‘void TSpiceData::Clear()’
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddDetectionSystemGriffinBackDetector(int)':
DetectorConstruction.cc:(.text+0x6d9): undefined reference to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddDetectionSystemGriffinBack(int)':
DetectorConstruction.cc:(.text+0x81f): undefined reference to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddDetectionSystemGriffinForwardDetector(int)':
DetectorConstruction.cc:(.text+0x96f): undefined reference to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddDetectionSystemGriffinForward(int)':
DetectorConstruction.cc:(.text+0xab5): undefined reference to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddDetectionSystemGriffinCustom(int)':
DetectorConstruction.cc:(.text+0xc0f): undefined reference to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o:DetectorConstruction.cc:(.text+0xd5d): more undefined references to `DetectionSystemGriffin::DetectionSystemGriffin(int, int, double, int)' follow
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddApparatus8piVacuumChamberAuxMatShell(double)':
DetectorConstruction.cc:(.text+0x145f): undefined reference to `Apparatus8piVacuumChamberAuxMatShell::Apparatus8piVacuumChamberAuxMatShell()'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::AddApparatus8piVacuumChamber()':
DetectorConstruction.cc:(.text+0x14cd): undefined reference to `Apparatus8piVacuumChamber::Apparatus8piVacuumChamber()'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::DetectorConstruction()':
DetectorConstruction.cc:(.text+0x2ee9): undefined reference to `DetectorConstruction::DefineMaterials()'
DetectorConstruction.cc:(.text+0x2f57): undefined reference to `DetectorConstruction::DefineSuppressedParameters()'
CMakeFiles/detectionSystems.dir/src/DetectorConstruction.cc.o: In function `DetectorConstruction::DetectorConstruction()':
DetectorConstruction.cc:(.text+0x342f): undefined reference to `DetectorConstruction::DefineMaterials()'
DetectorConstruction.cc:(.text+0x349d): undefined reference to `DetectorConstruction::DefineSuppressedParameters()'
CMakeFiles/detectionSystems.dir/src/DetectorMessenger.cc.o: In function `DetectorMessenger::SetNewValue(G4UIcommand*, G4String)':
DetectorMessenger.cc:(.text+0x986): undefined reference to `DetectorConstruction::AddDetectionSystem8pi(int)'
DetectorMessenger.cc:(.text+0x9bb): undefined reference to `DetectorConstruction::AddDetectionSystem8piDetector(int)'
collect2: ld returned 1 exit status
make[2]: *** [detectionSystems] Error 1
make[1]: *** [CMakeFiles/detectionSystems.dir/all] Error 2
make: *** [all] Error 2
local1@localhost (~/Geant4-Builds/GitHub) > 

[bkatiemills]

@evan012345 all these undefined reference complaints reek of things from the suppressed files - did you freshly clone @moukaddam's fork and not stick these in? If you just use the head of the main repo, with the suppressed files included, the dataRootClass make'd, a make clean for good measure in your build directory, and delete the two lines about Math/interpolate from RawG4Event.hh, do you get anything different?

[evan012345]

opps... good catch @BillMills . After placing the suppressed files in I can successfully compile @moukaddam's forked code. I did need to edit RootManager.hh as outlined in my last comment. ie:

#include "/opt/DetectorSimulations/detectorSimulations/dataRootClass/TSpiceData.h to #include "../dataRootClass/TSpiceData.h

After that change everything is gravy. I will run some test simulations when I have some free time.

[bkatiemills]

Okay cool. @moukaddam, please PR your latest commit and we should be good to close this issue. I will cook down the resulting discussion into a strategy issue this week; I think we have a much clearer idea of where we're going with the project now, but there's a ton of work to do (re: writing all the HW-specific classes). Please don't forget about #64 - we should have some canonical simulations we can all run at each change to make sure nothing has broken too badly during this time of great upheaval; as I explained there, no one has to write any new code for this to begin with, just throw up some stuff you already have so we can keep an eye on it; a smarter test suite will grow from there.

[bkatiemills]

Alright, all better at #68, closing issue now, to be replaced with a strategy issue as mentioned above.