It is a real problem when the simulation contains only NIST materials and no external Material Database is used.

Causing this error:
GateMaterialDatabase.cc (l.131): GateMaterialDatabase: could not find the definition for material 'Vacuum' in material

To solve this issue I propose to replace all the SetMaterialName("Vacuum") by SetMaterialName("G4_Galactic") defined in NIST materials.

When attempting to build Gate 7.1 with CMake variable GATE_DOWNLOAD_EXAMPLES_DATA = ON, I receive the following error:

The file provided in example_Radiotherapy/example10/data appears to be "resampledTHORAX.raw", not phantom.raw.

Would it be possible to update example10 with the correct image file?

Many thanks

When I tried to configure my dose actor such that the dosel geometry would be the same as the patient voxel geometry by setting the same voxelsize, I got a 511x511x55 dose distribution while the patient is actually 512x512x55, and the "elementspacing" in the dose MHD file does not match the voxelsize which I configured, and it is also different from the patient voxelsize; I think that the only quantity that was preserved is the total size of the image volume (I think you call that the "bounding box"). In Z the spacing is a round number, namely 3mm, but in X and Y it's 1.03516mm, so I'm guessing there is some rounding issue going on. If instead of the VoxelSize I set the Resolution to 512x512x55 this problem seems to be solved (or rather: worked around).

I have browsed a bit through the dose and image actor code but it's quite a deep rabbit hole, so I can't really claim yet that I found a bug. I can look into it later (and learn a lot about ITK and imaging). But maybe also someone else can have a look at this who has more experience with imaging code and has a clearer idea where/why this might happen. I can share the details for reproducing the problem, if needed.

Another solution which I tried is to omit both voxel size and resolution. I was hoping that it would take those settings from the patient data, but instead the dose actor regarded the entire patient image as a single voxel. I thought that was odd.

I was going to clarify the DoseActor documentation on the wiki, based on these experiences, but after some more pondering I thought that this is actually something that needs fixing, or at least discussion.

So this issue has two parts:

(1) There seems to be a rounding problem with setVoxelSize in the dose actor.
(2) Why doesn't the dose actor by default use the same voxelization as the patient data?

I didn't try to understand the code yet, but if the code is kept untouched, one should provide alternative implementations for compilers where the two functions don't exist. (The functions do exist in MSVC 2013.)

We have found several problems in a phantom simulation. This simulation was previously validated with FLUKA and MCNP5, [F. Botta, A. Mairani, G. Battistoni, M. Coca Perez, M. Cremonesi, R. Hobbs, M. Pacilio, K. Parodi, G. Sgouros, A. Vergara Gil, “Customization of FLUKA Monte Carlo code for dosimetry on PET-CT and SPECT-CT images: comparison with EGS-based 3D-RD and MCNP5”, Journal of Nuclear Medicine 53(S1), May 2012, 1497].

Following a description of the issues:

• Dose profiles using an analytical phantom does not match with the voxelized one [analitical phantom is te one simulated with Gate using cylinders and gps sources; voxelized phantom is the one simulated with Gate using mhd images for both geometry and sources].
• A posible explanation for the last issue shall be the non match between voxel densities read by the voxelized geometry range translator. The dose equals Edep/voxel mass for both the analitical and voxelized sources so this may not be the problem. Although you can see a discrepancy in the top right cilinder (bone insert) and in the water – air interface.
• The calculated Edep/mass image does not match with the already published one using FLUKA.
• The dose image also does not match with the FLUKA one.

Analytical phantom

voxelized phantom

FLUKA results

analytical phantom

voxelized phantom

FLUKA results

When running make install in a Gate build directory, the following things get copied to the install directory:

1. the (statically linked) Gate executable
2. the MetaIO library (static)
3. the MetaIO header files

Why do we install the MetaIO stuff? It's not even our own code, it's a copy of a directory in an old release of ITK. The static library is (by definition) not needed for running Gate. I don't think we want to encourage other developers to use our ITK copy (library and header files), they should use ITK directly.

On the other hand, I think it would be very useful to store the examples stuff (macros and input data) in the share part of the installation directory (except if the user left GATE_DOWNLOAD_EXAMPLES_DATA as OFF, then the user apparently does not want to install the examples). I usually treat the build directory as a temporary directory, which I delete after I'm done for the day with installing/developing/testing. All the interesting long term useful stuff should go into the install directory, and this includes the examples, in my opinion.

Another thing which I find myself doing all the time, is to create an gate_env.sh script, which I copy into the $(CMAKE_INSTALL_PREFIX)/bin directory. This file can be sourced and this then makes sure that my environment contains all the ROOT and Geant4 stuff that was used for this particular installation. Plus of course the bin directory is prepended to PATH. This is similar to the thisroot.sh and geant4.sh scripts that you get with ROOT and Geant4 (and of course my script uses those other scripts).

tl;dr: I want to change the install dir policy as follows:

• remove the MetaIO stoff
• add the examples (IFF the users enabled example data download)
• add a script for setting the environment of this particular Gate install

we are in the process of changing the cluster tools (mainly job splitter) for having the support for SLURM resource manager.We went through your documentation page to check the compilation procedure for GATE V7.1 and it seems that we have problems understanding the documentation.

Please find the below pages:
http://wiki.opengatecollaboration.org/index.php/New_Compilation_ProcedureV7.0#Installation_of_cluster_tools (for V7.0)
http://wiki.opengatecollaboration.org/index.php/New_Compilation_Procedure (updated procedure for V6.2)

Both versions shows the following:
Copy the library to the correct place
cp /opt/simulation/gate6_1/cluster_tools/jobsplitter/tmp/Linux-g++/gjs/libgjs.so /opt/simulation/gate6_1/cluster_tools/jobsplitter/bin/Linux-g++

When we did the "make" for GATEv7.1, resulting directory structure were as follows:
-bash-4.1$ ls
gjs gjs.cc include Makefile script src tmp
The content of tmp is as follows:
-bash-4.1$ ls tmp/
GateMacfileParser.o GateSplitManager.o GateToPlatform.o gjs.o

There is no ".so" file generated here. We had a look at the source code of GATE v6.2 and we see that there is a change in the makefile.Our specific question in this situation is; we would like to test our modified job splitter script. Could you please assist us in that?

Cluster tools documentation for both the versions looks the same ( including the directory names.). It could be an issue with the documentation.

I was experiencing some problems with the OpenGL inclusion in GateImageBox.hh. The code needs to be reviewed and tested.

Another summer project: update GateSourceTPSPencilBeam.

(1) pencil beam initialization

Right now all pencil beams in a given plan are initialized at the start of the simulation as GateSourcePencilBeam objects. GSPB is not a simple struct, so for big treatment plans with many thousands of spots this takes a lot of RAM. In my current treatment case it's about 2GiB, Hermann told me that in he also saw Gate using 8 GiB due to GateSourceTPSPencilBeam. That is unpractical, for instance for simulating many (versions of) plans on a cluster. It would be better to have just a single GSPB object at any point in time. This would also model the reality much closer, where we treat with just a single pencil beam that has the same properties (it does not jump from proton to carbon, or from one set of source properties to another).

(2) spot specification text file parsing

This is a different problem related to the same code: the text file parsing code is not very robust. The number of comment lines is hard-coded and if the user accidentally inserts or removes comment lines then the rest of the file yields bogus results or is ignored altogether, WITHOUT reporting any errors. This is in particular a problem for users who generate their spot file from non-DICOM input (because for dicom there is the clitkDicomRTPlan2Gate utility in vv). Minor mistakes can lead to a waste of a lot of time.

I would like to:
(a) allow arbitrary numbers of comment lines
(b) let each line start with a keyword, which may help to catch mistakes

Wish (a) is easy to implement: just replace all the for (i=0; i<Nlines; i++) getline(buf); expressions (where Nline is some hardcoded number) with a GateReadLine function which reads lines of text and returns the first non-empty non-comment line.

Wish (b) is also easy.

Of course there LOTs of other solutions (xml, dicom) but I like my solution because it is much less invasive while still addressing the problems I raise. The old format can still be supported (backwards compatibility), the new format can for instance be triggered by an obligatory keyword in the first comment line of the file (so that first comment line should of course not be skipped). And the clitkDicomRTPlan2Gate utility in vv could be updated to enable the new format (but as long as we keep the TPS code backwards compatible, that's not urgent).

(3) Convergence/divergence

Minor issue: a pencil beam can be convergent in X but divergent in Y and vice versa. At Skandion we see this at the lowest energy, Ekin=60MeV. For a single pencil beam source one can configure this, but in the TPS pencil beam source it's currently restricted to completely divergent or completely convergent. It would be nice to flexibilize this.

I wonder when we should start requiring developers/users to compile Gate with C++11. This "new" standard is now 5 years old, there is already a newer one (C++14) and in 2017 there will be yet another one. I am not necessarily advocating that we should jump to the bleeding edge, but I do think that at some point we should decide that we do not need to keep our code 2003-compatible anymore. All the tools that we depend on (geant4, root, ITK) have provided C++11 versions already long ago.

I think that the main argument for keeping the code 2003-compatible is to be nice to users with very old systems, running Ubuntu 12/04 or even 10/04. But I think/hope that those users are getting very rare, and maybe some of them can be gently encouraged to join the modern times with a shiny new linux distro.

On the other hand, if we do not want to repeat this discussion every 3 years (because on https://isocpp.org/std/status you can see that after 2017 the standards committee won't stop innovating) then some of us might even be tempted to leapfrog directly to c++2014. I am reading Scott Meyers' "Effective Modern C++" and I get the feeling that C++14 is kind of a "bugfix release", making many of the new elements in C++11 more convenient and consistent. But you can't compile C++14 code with gcc 4.8, which I think is still very popular.

I am opening this issue because I think that there needs to be a discussion and eventually a smart & practical policy/decision/agreement/compromise about our choice of C++ standard(s). I guess we can collect facts & opinions & things to consider, and then discuss it all in Strasbourg.

In Gate there are several classes that contain only one data item which is a vector, moreover there is a whole GateListManager class from whom a lot of other classes inherits. These classes doesn't have any way of fast accessing the elements through std:vector functionalities such as iterators. Implementation of this requires a bunch of changes, class by class, but it is required for code optimization since it will speed up element accessing and list traveling. These changes were provided in pull 21, but since they were combined with other issues lose their perspective, so I can provide them as separate pull request if you agree.

I'm experiencing some problems (including crashing) when building Geant4 and Gate against Qt5, at least on Mac. For example:

It would be nice to do some more testing and debugging of Gate against Qt5 and possibly report any problems in Geant4 upstream.

Hello,

when using a voxelised source with the "setIntensity" option, the intensity is not taken into account.
Example:

/gate/source/addSource my_src voxel
/gate/source/my_src/reader/insert image
/gate/source/my_src/imageReader/translator/insert linear
/gate/source/my_src/imageReader/linearTranslator/setScale 1 MBq
/gate/source/my_src/imageReader/readFile data/my_src.mhd
/gate/source/my_src/gps/particle gamma
/gate/source/my_src/gps/monoenergy 100.0 keV
/gate/source/my_src/setIntensity 0.5

If a 1 second simulation is performed, instead of 0.5 million particles (I assume the sum of all voxels in the image is 1), we get 1 million.

One solution (1) could be to replace the line https://github.com/OpenGATE/Gate/blob/develop/source/physics/src/GateSourceVoxellized.cc#L49
G4double firstTime = GateVSource::GetNextTime(timeNow);

with

G4double firstTime = GateVSource::GetNextTime(timeNow)/GetIntensity();

But this would be specific to voxelized volume.

Another solution (2) could be line https://github.com/OpenGATE/Gate/blob/develop/source/physics/src/GateSourceMgr.cc#L341
by dividing the aTime according to the intensity.

Yet another solution (3) in the function GetNextTime : https://github.com/OpenGATE/Gate/blob/develop/source/physics/src/GateVSource.cc#L258

Before I commit something (maybe solution 2), I would like some advices ...

some ideas ?
David

New versions of ROOT are c+11 based, and GATE is not yet fully c+11 compatible.

I was able to compile using the following code modifications:

1.) I had to add -std=c++11 to CMAKE_CXX_FLAGS. In ccmake window toggle to advanced mode via [t] and add the flag, then re-configure [c] and then generate [g] before re-running make.

2.) ifstream and ofstream are not prepended by std:: as they should be without a global using namespace std. I used replace, e.g.:

#> replace ofstream std::ofstream -- source/physics/src/GateCrossSectionsTable.cc

3.) Since I used c++11 standard of c++, some CLHEP files assumed I want Thread Local Storage (TLS) enabled, which caused a mismatch between the compiled version of CLHEP (TLS disabled) and Gate portion of CLHEP (TLS enabled). To resolve, I replaced

source/externals/clhep/include/CLHEP/Utility/thread_local.h

with a new thread_local.h where CLHEP_THREAD_LOCAL is defined to an empty string:

define CLHEP_THREAD_LOCAL

UPDATE: Pull request #21 of Gate on git is supposed to be c++11 compatible. Didn't have time to verify it yet.

Andrej

Under Visual Studio 2012 I had to remove #include <unistd.h> and replace it with

#if defined(_MSC_VER)
#include <BaseTsd.h>
typedef SSIZE_T ssize_t;
#define snprintf _snprintf
#include <io.h>
#endif

to get the code from source/geometry/src/GateDMapVol.cc and GateDMaplongvol.cc to compile. The code needs to be reviewed.

Current actors, such as Dose Actor, are now dependent of the number of histories, since you accumulate the deposited energy which increases with primary event generation. This is a really odd design in the code, since every other Monte Carlo tool, soft, whatever always divide by the current number of primaries when calculating anything, making the results non-dependent of this.
Solution involves a change of paradigm, so before doing anything developers should pronounce their position regarding this issue.

Advantages
Results doesn't increase with number of primaries, but oscillate around the true value, making possible the statistical analysis.
Results can be easily scaled to real values by users who must multiply them by the real total number of histories (cumulated activity). (Currently I have to manually divide by number of histories first)
There will be no more ambiguity when trying to run a simulation with both source activity and total number of primaries set.

Disadvantages
Results will be different from what it is obtained now, so users will complain.
change of mind can be traumatic.

A number of source files include unistd.h. That doesn't work in Visual Studio 2012.

Hello,

There is a problem with the behavior of neutrons in the develop branch (at the commit 071dd73) .

To illustrate the problem I have created a little example:

/tracking/verbose 1
/gate/world/setMaterial                       G4_WATER
/gate/world/geometry/setXLength               1 cm
/gate/world/geometry/setYLength               1 cm
/gate/world/geometry/setZLength               1 cm
/gate/source/addSource gun
/gate/source/gun/gps/particle    neutron
/gate/source/gun/gps/monoenergy  1 MeV
/gate/physics/addPhysicsList          QGSP_BIC_HP_EMY
/gate/output/allowNoOutput
/gate/run/initialize
/gate/random/setEngineName MersenneTwister
/gate/random/setEngineSeed 1234
/gate/application/setTotalNumberOfPrimaries 1
/gate/application/start

With GATE v7.2 (commit 946702b) the output of tracking verbose is :

*********************************************************************************************************
* G4Track Information:   Particle = neutron,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0        0         1        0        0         0  world_phys initStep
    1        0        0       -5         1        0        5         5  OutOfWorld Transportation

And with GATE develop (commit 071dd73) the output is :

*********************************************************************************************************
* G4Track Information:   Particle = neutron,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0        0         1        0        0         0  world_phys initStep
    1        0        0 -8.28e-309         1        0 8.28e-309 8.28e-309  world_phys Decay

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 4,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0 -8.28e-309    0.0102        0        0         0  world_phys initStep
    1 0.000949 -0.000349 0.000878         0   0.0102  0.00266   0.00266  world_phys eIoni

*********************************************************************************************************
* G4Track Information:   Particle = anti_nu_e,   Track ID = 3,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0 -8.28e-309      0.79        0        0         0  world_phys initStep
    1       -5    0.458    -4.08      0.79        0     6.47      6.47  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = proton,   Track ID = 2,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0 -8.28e-309     0.956        0        0         0  world_phys initStep
    1 0.000127 0.000131   -0.023         0    0.956    0.023     0.023  world_phys hIoni

One can see that in the second case the neutron does not move during its step and then decays.

In the file GateDetectorConstruction in the creator you are using a hand created material as air, it would be better if you use an already available Air material from NIST Database, cannot use user Air since it may be not air at all, and even worse at this point the user material database is not yet loaded, so solution would be

--------------- source/geometry/src/GateDetectorConstruction.cc ---------------
index 30e5716..f61051c 100644
@@ -69,17 +69,17 @@ GateDetectorConstruction::GateDetectorConstruction()

//-------------------------------------------------------------------------
// Create default material (air) for the world
/- G4String AirName = "Air";
/- G4Material* Air = theMaterialDatabase.GetMaterial(AirName);
/- if (!Air)//will never enter here
/- {
/- G4String AirName = "worldDefaultAir";
/+ G4String AirName = "Air";
/+ G4Material* Air = G4NistManager::Instance()->FindOrBuildMaterial(AirName);
/+ if (Air==NULL)//will never enter here
/+ {
/+ AirName = "worldDefaultAir";
G4Element* N = new G4Element("worldDefaultN","N" , 7., 14.01_g/mole );
G4Element_ O = new G4Element("worldDefaultO" ,"O" , 8., 16.00_g/mole);
G4Material_ Air = new G4Material(AirName , 1.290*mg/cm3, 2);
Air->AddElement(N, 0.7);
Air->AddElement(O, 0.3);
/+ }
//-------------------------------------------------------------------------

/+ pworld = new GateBox("world", AirName, pworld_x, pworld_y, pworld_z, true);

When I run my simulation without a set number of primaries, the simulation runs normally and I obtain a nice activity curve between the start and end time. However, when I set the number of primaries (mandatory for my simulation cluster), it feels like the activity table is completely ignored in the output. The total number of events is correct, but they are evenly distributed over the run time instead of following the acitivity table:

Fig 1: Input activity

Fig 2: Output coincidences

I have a question regarding how hounsfield density interpolation is actually implemented.

Current implementation expects user to gave the initial density for material, then Gate calculates following densities to reach the following material density. However, what users often have is not the initial density but the average density for material. So using the above procedure will raise in using those materials with densities higher than it is expected.

I have tried unsuccesfully to correct this behaviour but is quite difficult because of some mathematical complications:
Let's take the following materials
air: density 1e-3 g/cm3
lung: 8e-1 g/cm3
muscle: 1.04 g/cm3
soft_tissue: 1.04 g/cm3
bone: 1.92 g/cm3

So if we use current implementation we will obtain
air materials from 1e-3 to 8e-1 g/cm3, lungs from 8e-1 to 1.04 and so on.

Using a correction new left bound densities would be:
newD = oldD - 0.5*DDiff;
but this way is also wrong because it would underestimate the mean:
the example occurs for material muscle

So my question is what is wrong with the following code???

// This procedure is to put read densities as mean density for selected material
//FIXME: Current implementation underestimate the mean density
void GateHounsfieldDensityTable::RecalculateDensities()
{
    for (unsigned int i= 1; i<mD.size()-1; ++i)
       mD[i]-=0.5*(mD[i+1] - mD[i]);
}

I compiled the latest Gate/develop (3b8fafb) but I cannot replicate the positron kinetic energy spectrum output, see below.

The positron kinetic energy is exactly the same as the brem spectrum, also confirmed in the root output files directly, the error does not come from the plotting.

The code was added in #71 by @JStrydhorst.

My system:
Ubuntu 16.04 LTS
Geant4.10.02.p02
Root 5.34.36
Gate 7.2 develop (3b8fafb), no GPU, no cluster

Thanks for any hints regarding the cause of this!

I think that a large part of the memory foot print in radiotherapy simulations comes from the dose actor. Often we want the dose distribution with a high resolution but only a small number of voxels actually has a nonzero dose. But we also want to be able run multiple instances of Gate on a multicore computer, preferably on Gate instance per core, without having to require enormous amount of RAM. On a typical computer cluster a single core job is supposed to consume at most a few GiB. But with a big CT image and maximum dose actor information the Gate process easily blows up to much more than 5 GiB. There are other RAM hogs in Gate (GateSourceTPSPencilBeam source is one, but yesterday I submitted a pull request that hopefully solves that), but DoseActor is one of the biggest I think.

Has the Gate community every considered using "sparse matrices" instead of a data vector with entries for all voxels in a dose distribution? Am I too optimistic in thinking that we can save lots of RAM with sparse matrices?

(A sparse matrix would not work for the patient CT image, obviously...)

There are a bunch of warnings about non initialized class members that are thrown by the Eclipse's syntax checker, all these can lead to potential bugs since the member can be called without being initialized in the class constructor. The code works now because there is a detailed use of these members, initializing before calling them, but for future modifications this is dangerous. This issue involves a lot of changes since there are more than 50 classes (quick count) that fail into this.

Hi,

Compilation in 32 bits can fail on 32 bits at:
https://github.com/OpenGATE/Gate/blob/develop/source/digits_hits/src/GateMaterialMuHandler.cc#L389

modelPE = (dynamic_cast<G4VEmProcess *>((processListForGamma)[i]))->SelectModelForMaterial(incidentEnergy, physicRegionNumber);
As:
G4VEmModel G4VEmProcess::SelectModelForMaterial(G4double, size_t&) const

but:
long unsigned int physicRegionNumber = 0;

On 32bits platform, size_t can be "unsigned 32bits int", and a reference to long unsigned int in 64bits cand be cast to it, so breaking the code.

Thanks.

Yannick

The linker from Microsoft Visual Studio 2012 complained about multiple definitions of sum, prod, opp, intdivint until I removed them from GateDMapoperators.ihh or made sure that the code wouldn't be included/compiled twice.

Currently you can't start Gate with two or more aliases without wrapping it in quotation marks.
Gate -a '[AliasOne,ParamOne] [AliasTwo,ParamTwo]' main.mac

But if you want to use variables in aliases this solution will not work.

How to fix it: quote the spaces between aliases
Gate -a [AliasOne,$VarOne]' '[AliasTwo,$VarTwo] main.mac

Only tested with bash shell.

The creation of a ParameterisedCollimator:

/gate/geometry/setMaterialDatabase GateMaterials.db

/gate/world/geometry/setXLength 100 cm
/gate/world/geometry/setYLength 100 cm
/gate/world/geometry/setZLength 100 cm

/gate/world/daughters/name coll
/gate/world/daughters/insert collimator
/gate/coll/geometry/setDimensionX 20. cm
/gate/coll/geometry/setDimensionY 20. cm
/gate/coll/geometry/setFocalDistanceX 60. cm
/gate/coll/geometry/setFocalDistanceY 0. cm
/gate/coll/geometry/setHeight 4. cm
/gate/coll/geometry/setSeptalThickness 0.1 cm
/gate/coll/geometry/setInnerRadius 0.05 cm
/gate/coll/setMaterial Lead
/gate/coll/vis/setColor red
/gate/coll/vis/forceWireframe

/vis/open OGL
/vis/drawVolume  

/gate/run/initialize 

results in the following error:

GateVVolume.cc (l.189): The material of the volume hole is not defined.

This problem has been found before:
http://thread.gmane.org/gmane.comp.science.opengate.user/5039

Hello,

There is a compilation error in the develop branch (at the commit 071dd73) with the option GATE_USE_ITK OFF.

Building CXX object itk-mhd/src/CMakeFiles/MetaIO.dir/metaUtils.o
In file included from Gate/source/externals/itk-mhd/src/localMetaConfiguration.h:36:0,
                 from Gate/source/externals/itk-mhd/src/metaTypes.h:12,
                 from Gate/source/externals/itk-mhd/src/metaUtils.h:34,
                 from Gate/source/externals/itk-mhd/src/metaUtils.cxx:29:
Gate/source/externals/itk-mhd/itk_zlib.h:24:27: fatal error: itkThirdParty.h: No such file or directory
 #include "itkThirdParty.h"
                           ^
compilation terminated.
make[2]: *** [itk-mhd/src/CMakeFiles/MetaIO.dir/metaUtils.o] Error 1
make[1]: *** [itk-mhd/src/CMakeFiles/MetaIO.dir/all] Error 2
make: *** [all] Error 2

Removing the line 24 of Gate/source/externals/itk-mhd/itk_zlib.h fixes the error but I don't think this is the best way to fix it.

In several occasions I have to dump the density image for debugging and academical purposes, since this is not a standard user issue I can put this new feature as an option. The option will be:
/gate/PatientName/geometry/buildAndDumpDensityImage filename

I have tested this and there is no intrusion in the rest of the code.

The code in Gate.cc that includes getopt.h and uses getopt_long(...) to read the options doesn't work with Visual Studio. I will check the support in cygwin and MinGW just in case, but one would need an alternative solution if Gate should ever work under Windows.

Some compilers fail to evaluate fabs(crystal1ID - det1_c) as in source/digits_hits/src/GateSinogram.cc for example. The compiler doesn't know whether to treat the arguments as float, double or long double.

In several places in the code you use a bunch of vectors to define properties, vectors from the same size that are always used together. So an important optimization should be to create structures and the a vector of that structures to optimize creation/deletion/insertion/extraction of elements. An example is the file GateSteppingVerbose, you have

/- std::vector<GateInfoForSteppingVerbose > theListOfTrack;
/-
/- std::vector theListOfVolumeAtTrackLevel;
/- std::vector theListOfProcessAtTrackLevel;
/- std::vector theListOfParticleAtTrackLevel;
/- std::vector<G4SliceTimer> theListOfTimerAtTrackLevel;
/- std::vector theListOfEnergyAtTrackLevel;

while you can have

/+ struct GateTrackLevel
/+ {
/+ G4SliceTimer* Timer;
/+ G4String Particle;
/+ G4String Process;
/+ G4String Volume;
/+ G4int Energy;
/+ G4double Time;
/+ };
/+ typedef std::vector GateTrackLevelVec;

and finally

/+ GateTrackLevelVec theListOfTrack;

this is used intensively in the code, so this issue require a lot of changes

M_PI is no longer part of C99 and some compilers no longer support it. It should be defined if it doesn't exist yet.

At some places it is already defined as:

source/digits_hits/src/GateToGPUImageSPECT.cc:
#define PI ( 4 * ::atan( 1 ) )

See also:

• https://its.cern.ch/jira/si/jira.issueviews:issue-html/CLHEP-125/CLHEP-125.html

I have encountered weird behavior.
In each event i'm simulating 3 gamma particles. If gamma nb. 2 or 3 interacts via Compton scattering with a detector everything is ok (like in event 26 - in attachments are both root output [t.Show(event)]
and output directly from Gate). However, if gamma nb. 1 interacts via Compton scattering number of scatterings (nCrystalCompton) is not increased (like in event 6).
This happens every time gamma nb. 1 interacts (and only for gamma 1)

I have no clue what may cause this behavior.

Event 6 - Gate.txt
Event 6 - root.txt
Event 26 - root.txt
Event 26 - Gate.txt

During vpgTLE development, I discovered that the PhaseSpaceActor does not record 0-step (or 1-step) particles, i.e. particles destroyed in their first step. You can verify this by using the GatePromptGammaAnalogActor, for the case of prompt gamma creation. This actor sees a fairly large amount of PGs in the low keV range (2-25 keV), always destroyed in the same step that they're created. The reason this actor sees them is that we query secondaries of a primary particle. The PhaseSpaceActor does not because these particles somehow never make it to the global list of particles (there is no displacement in these particles either).

I am not sure if this is important, but since these particles are in fact created and not seen by the PhaseSpaceActor, a common instrument for particle detection, I submit an issue here in case someone ever has the same problem or knows why this happens. In the end, these particles are not relevant for me, so my solution is to ignore them below a certain energy threshold (see hard-coded threshold in GatePromptGammaAnalogActor.cc and GatePromptGammaTLEActor.cc), but a better understanding may lead to a better solution.

A lot of timing functionality in Gate depends on existence of sys/time.h and timeval. All time readings and calculations should be reworked a bit to work under Windows.

FindROOT.cmake needs some taking care of. Currently it would happily try to execute a shell script root-config even on Windows. I will write more details later, but I would like to keep this bug report as a placeholder. ROOTConfig.cmake might work.

Apparantly gjs has an issue parsing the same alias more than once per line, e.g. a command like

/gate/SPECThead/placement/setTranslation {transl} {transl} 0 mm

with the parameter 'transl' e.g. '5' passed to it is parsed to

/gate/SPECThead/placement/setTranslation 5 {transl} 0 mm

instead of

/gate/SPECThead/placement/setTranslation 5 5 0 mm

Geant4 recently introduced support for multiple threads. It would make sense to check whether one can avoid reinventing the wheel and use the code from Geant4.

I have found this:

• http://web.cs.du.edu/~sturtevant/w13-sys/InstallingpthreadsforVisualStudio.pdf
  so in principle pthread can work, but it would be nice if the code would work out of the box even without the presence of that library.

It is too easy to crash gate with a "stack smashing" error.

For instance, a guest researcher here in our lab uses the alias system to define things like pathnames of input files & output directories and numbers of primaries and then runs lots of jobs with that, using condor. We did our best to avoid that different Gate processes would overwrite each other's files (final output and or intermediate files). Still, typically the first couple of jobs would run successfully, then the rest would crash. The process counter was used in the path of the output directories, so I guessed that maybe with the earlier jobs the file path names would still fit within the buffer, but every time the process counter would cross to a larger power of 10 it would use an extra character, so buffer overflows would start to happen at process number 10, or 100, or 1000, etc.. So I asked her to move/rename her directories such that the path names would be shorter. She did that, and indeed the crashes did not happen anymore.

From Googling around I learned that "stack smashing" usually happens with static arrays, like char buffer[200];. If I understood correctly, this actually only happens with gcc because gcc inserts "canaries" to detect buffer overflows, and upon detection it throws theses "smashing" exceptions. With other compilers (or with the canaries disabled in gcc) you'd just get segmentation faults or undefined behavior.

There are quite a lot of static arrays used in the Gate source code. I have not yet hunted down which of them might be responsible for the above crash case, but in general I think it's a bad programming style and I think it would be good if most of them would be replaced with safer solutions.

As illustrated by a recent discussion on gate-users [1], Gate is not designed to work correctly with MT geant4. In order to avoid unpleasant surprises I think it would be good if the build system tries to detect whether geant4 is MT or sequential, and throws an error in case of MT geant4. Documentation (wiki/README) needs to highlight this as well.

I might have some time to work on this issue later this week.

[1] http://article.gmane.org/gmane.comp.science.opengate.user/5356

The linac beam source as implemented in GateSourceLinacBeam.cc needs work.

(1) It depends on a ROOT input file with a few thousand histograms. This ROOT input file can be generated from a phase space ROOT file, but the ROOT macro to do this conversion is not yet part of Gate. I wonder if we could/should maybe implement this as an actor instead of a separate macro.

(2) The histogram names (and lots of the comments in the code) are French, it would be good for international users and developers to change that to English.

(3) The code contains several hardcoded values that maybe should be configurable or dependent on input. For instance the number of volumes, currently set to 3.

(4) The code has several magic numbers for which it is unclear if they are specific to the linac for which the code was originally developed, or that they are more generic. E.g. this code snippet (in the current develop branch, lines 270-281) is particularly mysterious (I have no clue what the French comments are trying to tell me, and why there should be any linear relationship betwen the radius and the azimuthal angle):

  //DS TODO !!!

  if (volumeNumber==0) {Phi+=14.9*r/78.5;}             // G4cout<<"  Phi+=14.9*r/78.5= "<<Phi<< Gateendl;}
  if (volumeNumber==1) {Phi+=17.*r/80.;}               // G4cout<<"  Phi+=17.*r/80.= "<<Phi<< Gateendl;}
  if (volumeNumber==2) {Phi+=27.5*r/80.;}              // G4cout<<"  Phi+=27.5*r/80.= "<<Phi<< Gateendl;}
  //}
  //else {
  // on utilise une équation de droite représentative, qui est beaucoup plus juste (technique point source, pour chacun des 3 éléments)
  //if (volumeNumber==0) {Phi=14.9*r/78.5;}             // G4cout<<"  Phi+=14.9*r/78.5= "<<Phi<< Gateendl;}
  //if (volumeNumber==1) {Phi=17.*r/80.;}               // G4cout<<"  Phi+=17.*r/80.= "<<Phi<< Gateendl;}
  //if (volumeNumber==2) {Phi=27.5*r/80.;}              // G4cout<<"  Phi+=27.5*r/80.= "<<Phi<< Gateendl;}
  // }

We are using this actor in Uppsala and maybe I'll come around to fix these issues myself some time this summer.

In order to be able to compile for MSVC I had to comment out the following line in CMakeLists.txt:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-shadow")

One should check for which compilers this flag is relevant/important.

Now there is no default value, so user must declare the density tolerance by the line

/gate/HounsfieldMaterialGenerator/SetDensityTolerance 0.1 g/cm3

If user does not declare this it throws a hidden error (no segmentation fault) that makes Gate not run but also not giving any messages or errors, so this can be annoying. A default initialization doesn't override user settings and avoid this error. So solution would be

------------ source/general/src/GateHounsfieldToMaterialsBuilder.cc ------------
index aced608..d4eaf59 100644
@@ -19,7 +19,7 @@

//-------------------------------------------------------------------------------------------------
GateHounsfieldToMaterialsBuilder::GateHounsfieldToMaterialsBuilder()
+: mDensityTol(0.1*g/cm3)
{
pMessenger = new GateHounsfieldToMaterialsBuilderMessenger(this);

in this same file there is also another issue, you declare
double dDiffMax = mDensityTable->FindMaxDensityDifference(HMin, HMax);
double n = dDiffMax/dTol;

while it should be
double n = std::max(1,dDiffMax/dTol);

So you ensure to have at least one partition for every material, even if you have zero density difference, which can happens (two materials with same density).

The line

srandom(static_cast<unsigned int>(*theRandomEngine));

from source/general/src/GateRandomEngine.cc doesn't work under Windows (MSVC).

In the file GateVImageActor in the void GateVImageActor::Construct()
you expect for the user to declare the size of the output matrix
(let's call it S), and the the user has to choose between resolution
(R) OR voxelSize (VS), being S = R * VS. This is an annoying behavior
for the user because you may know VS and R, and then you must multiply
to put in the actor the Size. So why not using any possible
combination? Solution is easy to implement.

Details

void GateVImageActor::Construct()
...
if (!mHalfSizeIsSet){
mHalfSize = ComputeBoundingBox(mVolume->GetLogicalVolume()->GetSolid());
}
if (mResolutionIsSet && mVoxelSizeIsSet) {
GateError("GateVImageActor -- Construct: Please give the
resolution OR the voxelsize (not both) for the sensor");
}
if (!mResolutionIsSet && !mVoxelSizeIsSet) {
mResolution = G4ThreeVector(1.0, 1.0, 1.0);
mResolutionIsSet = true;
}

Can be replaced by

if (!mHalfSizeIsSet){ //the user doesn't specify the size
if (mResolutionIsSet && mVoxelSizeIsSet){ //but specify resolution
and voxelsize
mHalfSize = KroneckerProduct(mResolution, mVoxelSize)/2; //compute
size as the dot product of resolution and voxelsize
}
else { // also it doesn't specify one of the resolution or
voxelsize variables
mHalfSize =
ComputeBoundingBox(mVolume->GetLogicalVolume()->GetSolid()); // so get
size from the volume the actor is attached to
}
mHalfSizeIsSet = true; // say that size is set
}
else { // the user specify the size
if (mResolutionIsSet && mVoxelSizeIsSet) { //but also the
resolution and the voxelsize so show an error
GateError("GateVImageActor -- Construct: Please give a combination
of two between" <<
" the size, the resolution and the voxelsize (not all) for the sensor");
}
}

if (!mResolutionIsSet && !mVoxelSizeIsSet) { // the size is defined
but neither the resolution nor the voxelsize, so use a default value
mResolution = G4ThreeVector(1.0, 1.0, 1.0);
mResolutionIsSet = true;
}

So now any combination of two of this variables lead to a valid Image Actor.

I ran into the same issue seen here, where I ran into the following errors when compiling with ROOT support disabled:

error: invalid use of incomplete type ‘class GateARFSD’
   if (arfSD->PrepareCreatorAttachment(this)) {
            ^
In file included from
/home/ayush/Downloads/gate_v7.0/source/geometry/src/GateVVolume.cc:29:0:
/home/ayush/Downloads/gate_v7.0/source/geometry/include/GateDetectorConstruction.hh:33:7:
error: forward declaration of ‘class GateARFSD’
 class GateARFSD;
       ^
/home/ayush/Downloads/gate_v7.0/source/geometry/src/GateVVolume.cc:639:23:
error: cannot convert ‘GateARFSD*’ to ‘G4VSensitiveDetector*’ in
assignment
   m_sensitiveDetector = arfSD;

It seems like there are still implicit ROOT dependencies that aren't guarded out. There was a patch for this back then. Wanted to check, is there a reason that patch hasn't been added?

This is an issue in the "nitpick" category.

Building GATE on MacOSX El Capitan with nomt G4.10.02, using clang; switching C++11 mode ON in cmake, the build is almost clean, except for this warning:

/Users/montecarlo/Software/CERN/GATE/Gate/source/externals/itk-mhd/MetaIO/metaOutput.cxx:579:17: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid' [-Wpotentially-evaluated-expression]
      if(typeid(*(*itStream)) == typeid(MetaFileOutputStream))
                ^

I see that typeid is used to do something that could be done way more elegantly in a proper OO manner. A small, still hackish fix would be to dynamically cast *itStream to a MetaFileOutputStream pointer, and depending on whether that cast succeeds we call this->GenerateXML(...) with or without filename argument. By using that dynamically casted pointer we don't need that C-style static cast anymore either, in line 581.

However, this code was not written by Gate developers, it was copied from ITK or VTK. I see that it is perfectly identical to MetaIO/metaOutput.cxx in ITK 4.7.1 and VTK 5.10.1. However, Kitware seems to have run into the same warnings, because in ITK 4.8.1 (and VTK 6.3.0) they have indeed replaced the typeid by a dynamic cast (but they still do the ugly C-style cast).

So I guess we should not try to patch this ourselves, but rather update the Gate MetaIO directory by copying the MetaIO directory of a more recent release of VTK. How (un)comfortable would you all be with such an operation? A recursive diff of MetaIO in current Gate/develop and VTK 6.3.0 is not terribly long, and to me most changes seem to me of the code-gardening variety.

(Of course this whole point is moot if the user has already ITK/VTK installed on her machine and can use that instead of the "external", but that is a separate discussion.)