RE: tracking or geometry problem?

Dear Makis,

indeed you did not do anything stupid. The unfortunate problem is that
also free format cards turn out to be (unintentionally) limited to 80
characters. So your ROT-DEFI cards are not interpreted correctly.
Then, for the time being, the increaded precision allowed by the free
format has to be reserved for the WHATs actually needing it (especially
the rotation angle), without breaking the 80 character card limit.

Cheers

Francesco

**************************************************
Francesco Cerutti
CERN-EN/STI
CH-1211 Geneva 23
Switzerland
tel. ++41 22 7678962
fax ++41 22 7668854

On Sat, 28 Aug 2010, Chrysostomos Valderanis wrote:

> Dear Francesco,
>
> Thank you very much for your answer! You remark about the increased accuracy
> through the use of the FREE card for the ROT-DEFI was really enlightening.
> Unfortunately I can not implement it correctly. In order to write the cards
> in free format I filled all the values which where asumed in fixed format
> input. Flair seems to interpret correctly the cards. But whem I look at the
> Fluka output file, under the coordinate transformations section, I see
> different transformations. The net outcome is that in the free format
> version of my input nothing works due to geometry errors.
> I guess I did something stupid in the way I write the ROT-DEFI cards in free
> format, but I cannot locate it.
>
> Any hint?
> Makis
>
>
>
> ____________________________________________________________________________
> From: Francesco Cerutti
> Sent: Thu 26/08/2010 18:55
> To: Chrysostomos Valderanis
> Cc: fluka-discuss_at_fluka.org
> Subject: Re: tracking or geometry problem?
>
>
> Dear Makis,
>
> > 1. Since only tracking is required in my code and no fluctuations exist
> (ie
> > pencil beam), I though that the boundary crossings of two events are going
> > to be *exactly* the same. As you can see from the logfile this is not the
> > case. What am I missing?
>
> actually the initial step is randomized, in order to avoid unnatural step
> effects for transport in a material. We are now going to remove this
> randomization for transport in vacuum. Anyway, you can already get quite
> identical trajectories by setting the tracking precision through the
> MGNFIELD card (WHAT(1-2-3)), and the STEPSIZE card too. See
> https://www.fluka.org/free_download/course/mumbai2009/Lectures/IonizationTr
> ansport1009.pdf
> (from slide 29 onwards)
>
> > 2.The proton is not crossing all the boundaries I was hoping to. As you
> can
> > see from the logfile there is a region succesion that is aborted at line
> > 265. the proton is exiting a region I was hoping to enter first. The net
> > result of this is that the proton is not seeing the full magnetic length
> and
> > gets a wrong direction. I checked with the geometry and didn't find
> anything
> > unusual. Is there anything else to check?
>
> There are in fact some problems in your geometry. In particular, the Q1TR
> transformations do not bring the Q1En container exactly upon the QSLQ0En
> prototype. In order to do that, the z-coordinate of the Q1En vertex should
> be 3993.96549586196, and not 3994.012495861956, being an accuracy worse
> than 1e-5 totally unacceptable (indeed you need much better). With this
> correction, you will see the same problem occurring later along your
> magnet string, for analogous reasons.
> Otherwise, note that you can increase the accuracy of the transformation
> definitions by using the free format (only) for the ROT-DEFI cards (for this
> purpose, insert a FREE card and a FIXED card just before and after -
> respectively - the ROT-DEFI card list).
>
> Ciao
>
> Francesco
>
>
Received on Mon Aug 30 2010 - 11:06:54 CEST