TGeant3 compilation error+question

Hi, I am not sure whether this is the correct place for VMC questions but here it goes. Trying to activate #define COLLECT_TRACKS in TGeant3gu.cxx to be able to draw tracks with TGeo GEANT3 brings out a compilation error, fixable by adding
#include “TDatabasePDG.h”

Now the question: I get these series of error messages
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=3
Error: no parent track with id=2
Error: no parent track with id=2
What is the root cause, how to fix/look into or disable this? I get visualization output which seems to be correct, although all events are overlapped at the moment I write this, probably need to clear the canvas somehow?) Thanks,
filimon

Hi Filimon,

Please update GEANT3 from the trunk and try again.

Regards,

Hi Andrei,
I get this error with ROOT 5.26/00b.
TGeant3/TGeant3gu.cxx: In function ‘void gustep_()’:
TGeant3/TGeant3gu.cxx:758: error: ‘class TGeoManager’ has no member named ‘FindTrackWithId’
Does 5.27/02 work with it or should I use the trunk?

Hi,
5.27/02 will do.

Hi Andrei, thanks the change solved the excessive screen output issue. cheers,
filimon

Hi, I have observed a big performance impact when enabling this option, in one of my simulations ~3-4x, in fact it is visible without a profiler. This is maybe expected because the operation is on every step but what is rather problematic is the fact that one has to recompile the library to switch between the two use-cases. Would you consider introducing a switch with the form of a TGeant3TGeo ctor parameter that would enable internally the check of a boolean flag of whether or not to do the track collection? ie change the
#if defined (COLLECT_TRACKS)
to
if(fCollectTracks)
(and probably move some redundant checks to the ctor when setting the value e.g. gMC->IsRootGeometrySupported() should be cached somehow to kTRUE for TGeant3TGeo I assume (ok, this is probably even optimized out by the compiler but I put it as an example, in fact all the other statements look as much optimized as they can be))
To conclude, this change would provide an easy way to do
mc->Run(1) (visual check) and mc->Run(10000) (production) without having to recompile. cheers,
filimon

Hi, coming back to the above issue, is it foreseen to provide a workaround? Any answer would be appreciated.
Another issue. On my application I define a TGeoUniformMagField(0, 0, 0) to set in gMC->SetMagField. Now, obviously I intent no magnetic field presence with this (at least in these startup tests). Geant4 behaves correctly, however in Geant3 I get all the hints that a magnetic field is present along z-axis. For example,
kElectron and KMuonPlus moving along x-axis with px~0.2GeV get deflected in opposite directions along y-axis. The particle gun distance from the detector is such that the deflection is visible (300 cm from detector along x axis). kGammas do not deflect as expected. As I say this only happens in G3 VMC. Could it be that I need to set an additional TGeant3TGeo-only specific command to disable the magnetic field? The above results occur either with gMC->SetMagField(myfield) initialized as above and also with gMC->SetMagField(0). In any case, this does not seem to be very intuitive since one would expect to define the magnetic field only by the gMC->Set… Could it be that there is an option in my application that could affect this? This would be strange because this works as expected with G4 VMC (no deflection). Thanks,
filimon

Hi Filimon,

I implemented gMC->SetCollectTracks(flag) and gMC->IsCollecttracks(). You have to update $ROOTSYS/montecarlo and geant3. Disabled by default, works only for GEANT3 for the moment. For setting the field one can do:

TGeoGlobalMagField::Instance()->SetField(new TGeoUniformMagField(0,0,0))
TGeoGlobalMagField::Instance()->Lock() // to protect against field changes
gMC->SetMagField(TGeoGlobalMagField::Instance()->GetField());

Note that for G3, the field definition is inside TGeant3gu.cxx in function gufld which accessed the field as set above. Make sure you do not have a custom version of TGeant3gu.cxx having this messed up.

Cheers,
Andrei

Hi Andrei, thanks for the change in G3 visual, I will give it a try asap (probably during the weekend when everyone else is on the beach, great!)
Regarding the magnetic field, in fact I got hurt badly by g2root translating an old G3 geometry to TGeo. There was a magnetic field on z-axis declared which passed on the TGeoMedium declarations and overwrote my TVirtualMagField declaration. Anyway, this is fixed and understood now… But since you mention is, what is the advantage in using the two statements

TGeoGlobalMagField::Instance()->SetField(new TGeoUniformMagField(0,0,0))
TGeoGlobalMagField::Instance()->Lock() // to protect against field changes

before the last one gMC->SetMagField(…), which I already use anw directly with a TVirtualMagField-derived class?

Now, I do not know whether this is the correct place for the rest but here it goes

  1. As I can understand there is no mechanism for sensitive volume definition in TGeo (probably would not make sense to have sth like gsvol by itself anyway). From your experience, would it make sense to have a “sensitive” attribute on the TGeoVolume class, to check in the step manager like follows

Int_t copyNo=-1, volId=gMC->CurrentVolID(copyNo); // This is the standard example for VMC
bool isSensitive=gGeoManager->GetIsSensitive(copyNo); // Proposal
// Do stuff if sensitive

or does it suffice to check whether the volid is somewhere in our code defined as sensitive (ALICE does this, I do this, but somehow I would prefer a more “standardized way”, for example a gGeoManager hash collection of sensitive volids with the appropriate interface to set and retrieve sensitive volumes by name and integer id). You get the picture. Maybe Rene can comment on the sense and general usefulness on this also.

  1. Really G3-related: We get really bad results in our sampling lead/organic scint calorimeter with “LOSS” to the default value 2 (more detailed simulation). LOSS=1 agrees with both data and G4 simulation. I would like to try and turn on/off the DRAY and STRA switches before getting back to you with more details but at this point I would like just to ask whether anyone has experienced something similar too. cheers,
    filimon

Hi Filimon,

Setting the field to a global field manager gives a very good placeholder to access it from the application even if not in a simulation environment. This is the preferred way of access and can be used consistently in simulation and reconstruction as it implies only a dependency on the geometry. Locking is a good practice to protect from undesired runtime field changes.

For the sensitive flag, I tend to agree with its necessity. Problem is that there is no flag left at the level of the TGeoVolume class so we would need to add a new data member. Instead of adding a bool just to mark sensitivity, I would go rather for a pointer to an object giving more functionality - like TGeoRegion, that can allow also for better interfacing with GEANT4. But this need a bit of a thought before implementing, so I cannot promise it for tomorrow.

Regarding your point 2, I let G3 experts comment.

Cheers,

Hi Andrei,
thanks for the info on the magnetic field. I agree with your comments on the sensitive volumes, in fact I am working on something myself, towards an association of a sensitive volume to a specific type of “hit”, this would be good for the use-case I have in mind. Maybe I have something to show in CHEP’10. Anyway, as it has been proven in ALICE, the simple scheme with integer predefined volume ids as sensitive works very efficiently for the moment. cheers,
filimon