Re: (no subject)

From: Ivana Hrivnacova <ihrivnac_at_mail.cern.ch>
Date: Thu, 2 Jun 2005 12:19:28 +0200 (CEST)

 Dear Dimitry,  

 With the last update of the VMC examples,  there was added visualization of tracks via TGeo;  however this is demonstarted only on Geant3.  

 In case of Geant3, collecting track points  for visualization is already implemented in TGeant3  package; you need only to recompile geant3 library  with a special flag (COLLECT_TRACKS) set.  You should use the latest geant3 version (1.2)  as it includes some fixes for this.  

 Your approach is more general, as using only VMC,  you get the code working with also with other MCs.  It may be interesting also for other users  to extend some VMC example with your code.  To avoid searching of the track and speed up  you can keep the pointer of the created TGeoTrack  and use it later for filling the points.  These are just implementation details, that we can  discuss offline.    

>1. G4 places and traces all tracks sequentially: 1,2,3,4,...N
> G3 seems not to follow this rule and it tracks them like:
1,5,12,2,25...

 This is due to different use of the VMC stack in Geant3 and Geant4.  See more details at:
 http://root.cern.ch/root/vmc/Geant4VMC.html  In case of Geant4, the secondary track is put in the VMC stack  when it starts tracking, that's why their order in the stack  corresponds to the order in tracking. However this is not true  for primaries. They are stacked in front of the stack but  go to tracking in the inversed order.

> (in g4config.in /mcPhysics/setHadron 1 if I am not mistaken here) it
takes quite
> a lot of time
> to remove all tracks from gGeoManager. Is it an expected behaviour?
 

  The Geant4 default cuts are lower than those in Geant3 so when including   hadronics physics the number of created tracks can be significantly   higher than in case of Geant3. It could be the reason.   

  Best regards,   

 Ivana

-- 
==============================================================
e-mail:  Ivana.Hrivnacova_at_cern.ch
address: Institut Physique Nucleaire, 91406 Orsay, France
phone:   (33) 01 69 15 65 94
==============================================================


On Wed, 1 Jun 2005, Dmitry Naumov wrote:


> Dear VMC group,
>
> I suppose that VMC interface to G3, G4 via root also assumes that a user can
> desire to use root visualization of both the detector and the tracks produced.
> If
> this is correct than I think that TGeoTrack is a tool created for
> visualization of tracks.
> I am trying to use it like:
>
> MCApplication::PreTrack()
> Int_t id = fStack->GetCurrentTrackNumber();
> Int_t pdgcode = gMC->TrackPid();
> TLorentzVector position;
> gMC->TrackPosition(position);
> fStack->PreTrack(id, pdgcode, position);
>
> and in
> void MCStack::PreTrack(Int_t id, Int_t pdgcode, TLorentzVector position) {
> //
> //
> //
> if (!gGeoManager) Fatal("PreTrack","No gGeoManager");
> gGeoManager->AddTrack(id,pdgcode);
> TGeoTrack *newtrack = (TGeoTrack*)gGeoManager->GetTrackOfId(id);
> newtrack->AddPoint(position.X(),position.Y(),position.Z(),position.T());
> <skip>
>
> Also to update I refer to the track via its Uid. In principle it works but
> there are however
> some things where I am not sure if I use them propely:
>
> 1. G4 places and traces all tracks sequentially: 1,2,3,4,...N
> G3 seems not to follow this rule and it tracks them like: 1,5,12,2,25...
>
> This forces me to use gGeoManager->GetTrackOfId(id) which is quite time
> consuming.
> gGeoManager->GetTrack(id) works only for G4 and make crash for G3 because
> of
> difference in the tracking sequence.
>
> 2. When the tracks are drawn I obviuosly need to reset them for the next
> event. This I do with:
>
> gGeoManager->ClearTracks();
> This method deletes all objects from gGeoManager::fTracks For energies of 1
> TeV and with hadronic switch on
> (in g4config.in /mcPhysics/setHadron 1 if I am not mistaken here) it takes
> quite a lot of time
> to remove all tracks from gGeoManager. Is it an expected behaviour?
>
> Thank you in advance,
> Dmitry
>
>
>
>
>
Received on Thu Jun 02 2005 - 12:19:39 MEST

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:55:21 MET