Re: Local coordinates in a volume+external event loop

Hi Filimon,

About local coordinates, indeed, if the query is not triggered by a boundary crossing you can safely use gGeoManager->MasterToLocal() that should give you local coordinates inside the current fiber. This may not be the case on boundary crossings as the MC does *NOT* always notify the navigator of the change of touchable - to be checked in case of G4vmc though. In such case (IsEnetring) probably you have to do: gGeoManager->GetHMatrix()->MasterToLocal() (this is the matrix corresponding to the next crossed volume.

About triggering the proof progress bar, I don't know - you should ask some proof expert.

Cheers, Andrei

On 03/01/2011 12:26 PM, Filimon Roukoutakis wrote:
> Hi,
>
> On 03/01/2011 11:55 AM, Ivana Hrivnacova wrote:
>> Hi Filimon,
>>
>> See my replies below.
>>
>> Best regards,
>>
>> Ivana
>>
>> On 02/28/2011 10:54 AM, Filimon Roukoutakis wrote:
>>> Hi, I would like to retrieve the local coordinates of a hit inside a
>>> specific volume (defined through TGeo), ie the coordinates should be
>>> extending from the center of the volume (0, 0, 0) up to its boundaries
>>> (for example length and radius of a cylinder as maximum values). Is the
>>> gGeoManager->MasterToLocal the correct and fastest way to do this? (I
>>> plan to have this call in Stepping function so it should be as efficient
>>> as possible).
>>
>> I believe, this is ok when you run G3 with TGeant3TGeo and Geant4 with
>> G4Root navigation (Andrei, could you, please, confirm.)
>> Only if you would want to run also with Geant4 native navigation, than
>> you should use gMC->Gmtod(..) instead.
> Ok, thanks, we are only playing with TGeo geometries and navigation in
> my use case so this should be OK. I guess then what one expects is to
> get the x, y, z values extending up to max dimensions defined by the
> bounding box of each volume (2*dx, 2*dy, 2*dz) or is it really more
> constrained to the actual geometry of the volume?
> To give you an idea of what I am doing, we have several thousand of
> fibers placed in a bulk absorber and we need to know the point along
> each fiber where we register a hit. This cannot be accomplished by
> gMC->TrackPosition(x, y, z) because this returns the coordinates in the
> top volume, right? So the idea is to get the (z)-coordinate along the
> length of the fiber (could be the x, y, or z according to the actual
> orientation) and store it during simulation so at digitization time we
> do not need to perform this over and over again with different
> digitization params. This is why I need the MasterToLocal, hopefully it
> works as I think. I do not know whether there is a simpler approach to
> this use-case...
>>
>>
>>> Another question, there is a TVirtualMC::ProcessEvent function. Is this
>>> called at some point in the simulation? The reason I am asking is that I
>>> would like to have an external event loop for the simulation if possible
>>> but as far as I can see for example in TGeant4::ProcessRun(int)
>>> G4RunManager::BeamOn(int) is called directly (at least last time I
>>> checked some time ago). Is there a way to have an externally-driven
>>> event loop bypassing this then?
>>
>> The external event loop is not possible with VMC + Geant4;
>> user can call only gMC->ProcessRun(int) as you found. There are
>> available MCApplication::BeginEvent() and MCApplication::FinishEvent()
>> functions, where you can put the necessary actions on the event level.
>> Could you give us more details, why do you need the external event loop?
> I am combining VMC+TProofLite. It works but the user does not get an
> output while the long simulation runs (in this very first implementation
> I have). I guess the obvious solution since no external event loop is
> possible in the general case would be to move the progress indicator of
> Proof inside TVirtualMCApplication::FinishEvent(). Andrei, what would be
> the most appropriate way for both batch and graphical mode? Is there any
> Getter to accomplish this, maybe? cheers,
> filimon
>>
>>
>> Thanks,
>>> filimon
>>
>
Received on Tue Mar 01 2011 - 15:24:15 CET