Message: Re: triggering hadronic Inelastic interactions inside ModelTrigger Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: triggering hadronic Inelastic interactions inside ModelTrigger 

Forum: Fast Simulation, Transportation & Others
Re: None triggering hadronic Inelastic interactions inside ModelTrigger (Soon Yung Jun)
Date: 10 May, 2007
From: Marc Verderi <Marc Verderi>

Dear Soon,

     It is true that your request is "not standard" but I think your  
approach may work. However I have two surprises I will explain below.

     First about the approch. The "ModelTrigger" method is called at a  
stage in the G4SteppingManager where no interaction (modification of  
the primary or secondary creation) has occured yet. At this stage,  
only the step lenght is estiamted. However, the G4Step information,  
about the process limiting the step is updated.
     The important point here is to ensure that your  
G4FastSimulationProcess appeared just before the G4Transportation: ie  
after all other processes. This ordering is the one in the  
"GetPhysicalInteractionLength" loop of the G4SteppingMananger. If  
"PionPlusInelastic" limits the step, then your condition:

     if( procName == "PionPlusInelastic")

should be fulfilled.

     Then, as the interaction has not occured yet at this stage, and  
since your parameterisation will take over without letting a chance to  
this interaction to occur, the primary track will not be affected by  
other processes.

     At this stage, I believe you do not need to test other  
information. One point of "performance" however: checking a string  
might not be optimal. If you could keep and check the process pointer,  
that would be more efficient.


     Now my surprises. I am confused about the fact that:

                    (*secondary).size() > 0

can be fulfilled at the "ModelTrigger" stage. As I wrote above, since  
no interaction occured yet at this stage, I would expect no  
secondaries at this stage. Could you confirm that your condition

     if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
        trigger = true;
     }

was fulfilled ?

     Also, you say that in the DoIt method of the fast simulation  
model, you see the primary track after interaction. As I said above,  
if the fast simulation model is triggered, nothing should happen to  
the primary after the call to ModelTrigger and the call to the DoIt  
one (I'm asking, as this would be a bug...).

     Could you let me know if you confirm that you see a change of  
state of the primary track between the ModelTrigger and DoIt methods ?

Regards,
Marc


Soon Yung Jun <syjun@fnal.gov> a écrit :

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/26"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
>
> Hi G4FastSimulation expert:
>
> I want to trigger a fast simulation model at the point of a particular
> hadronic interaction, for an example, at the first hadronic inelastic
> interaction inside an envelope.  Below is a snipet of my code
> implemented inside ModelTrigger with geant4.8.2.p01
>
> ---------------------------------------------------------------------->
>
> G4bool trigger = false;
>
> G4StepPoint* postStep =   
> fastTrack.GetPrimaryTrack()->GetStep()->GetPostStepPoint();
> G4String procName = postStep->GetProcessDefinedStep()->GetProcessName();
> G4TrackVector* secondary =   
> fastTrack.GetPrimaryTrack()->GetStep()->GetSecondary();
>
> if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
>   trigger = true;
>   //should delete secondaries
>   //fastTrack.GetPrimaryTrack()->GetStep()->DeleteSecondaryVector();
> }
>
> return trigger;
>
> <----------------------------------------------------------------------
>
> The problem that I encountered is that the kinetic energy of the fastTrack
> (i.e., fastTrack.GetPrimaryTrack()->GetKineticEnergy()) in the "DoIt"
> method is the energy after the hadronic interaction (i.e., after loosing
> primary energy).  Since I want to
> parameterize the hadronic shower (energy) with a fast simulation model,
> the condition that I implemented in ModelTrigger is actually one
> step "behind" the step where the parameterized physics should be
> triggered.  It seems that this may be a general problem if the condition
> in ModelTrigger depends on a specific physics process.  Is there any
> fundamental logistics to get around this problem?
> Thanks for your help.
>
> Regards,
> ---Soon
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 None: Re: triggering hadronic Inelastic interactions inside ModelTrigger   (Soon Yung Jun - 10 May, 2007)
(_ Feedback: Re: triggering hadronic Inelastic interactions inside ModelTrigger   (John Apostolakis - 26 Jun, 2007)
 Add Message Add Message
to: "Re: triggering hadronic Inelastic interactions inside ModelTrigger"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]