Date: Tue, 7 Jul 2015 20:23:51 +0200
Ciao Oscar,
then I understood correctly (rare event with this heatwave which is
crossing central Europe).
You for sure already had a look here:
https://indico.cern.ch/event/365567/contribution/3/material/slides/0.pdf
but I think it might not be straightforward to get the full picture
immediately.
The ROT-DEFI cards define a transformation which can be applied to binning,
lattices and directives.
The key issue is that the *start_transform* (etc) directives are very
different from the ROTPRBIN card. The ROTPRBIN will require the direct
transformation, and as a matter of fact it will transform the *"position of
the tracked particle before scoring with respect to the defined binning*".
The geometrical directives will instead transform the bodies (runtime or at
initialization depending on the directive) and accepts as argument both the
direct rotation (+rot5) or the inverse(in your case -rot5).
This is why when defining a ROT-DEFI the bese idea is to tune it on the
USRBIN first as the geometrical directives can handle also the inverse one.
There's a nice way to check it with Flair. If you add new visualization
layer (layer then "+" button on the UI) you can superimpose the outline of
the usrbin on the geometry (and apply a ROT-DEFI) by selcting the "USRBIN"
option and then checking the "USRBIN from input". (See attached screenshot)
In conclusion
> $start_transform -rot5
plus
>
> *...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....
> ROT-DEFI 200. +22.5 rot5
>
should do the magic for you.
> Best,
V.
[image: Inline image 1]
On Tue, Jul 7, 2015 at 3:04 PM, Oscar Frasciello <
oscar.frasciello_at_lnf.infn.it> wrote:
> Ciao Vittorio,
> first of all thanks for your reply. I agree with all your comments about
> the geometry of my problem, however let me point out that I never had any
> "crah" in the performed runs, so no problems related to geometry
> definitions. However, these latter can be improved and better described, I
> will do it according to your suggestions.
>
> What I found difficult to understand in your message is the key issue
> about my USRBIN. Probably I did not explain the simulation goal in a clear
> way, sorry for that. I want to score dose values after beam interaction
> with the target, just before the oblique wall (in region C100, USRBIN 0n)
> and just after it (in region C51, USRBIN 1n), where "just after" means,
> say, 1cm. More critical is that I want to score doses on a linear grid
> aligned with the oblique wall, because the Physics involved should
> determine maximum doses to be expected at about 45° wrt the beam direction.
> So my question to you: why should rot5 be an indirect transformation from
> the point of view of ROTPRBIN? Does your comment mean that ROTPRBIN needs a
> transformation that is NOT the same of any applied to any element of the
> geometry? Where does the FLUKA manual exploits this detail?
>
> I sadly acknowledge I find the solution still too far from my eyes...
> Best regards,
> Oscar
>
> Oscar Frasciello
> Istituto Nazionale di Fisica Nucleare
> Laboratori Nazionali di Frascati
> Accelerator Division
> Via Enrico Fermi 40
> 00044 Frascati (RM) Italy
> Tel. office: +39 06 9403 2710
> Tel. Tenocode: +39 06 9403 8114
> Fax Accelerator Division: +39 06 94032256
> email: oscar.frasciello_at_lnf.infn.it
>
> Il 06/07/2015 22:16, Vittorio Boccone ha scritto:
>
> Ciao Oscar,
> Allow me to start with a few geometry consideration (which are always
> useful)
>
> - You define a few regions just with bare-rotated-touching RCCs (*C60*,
> *C65* *C68* for example). This might generate rounding problem at the
> interface between the two regions, when the code will need to determine
> whether a particle is in a region or outside. A safer implementation could
> be easily deployed by using a longer RCC cut by a plane. In your particular
> case the cutting place could be used in the generation of all those
> regions, and will remove the risk of tedious crashes related to the
> geometry definitions.
> - Bodies which undergo the same transformation can be grouped together
> .
> - Then you mention:
> > ROTPRBIN WHAT(6) is wrongly set to 0.0 instead of 1.0.
> If you use flair just delete the field.
> - Your second *ROT-DEFI* card is also pretty useless as no angle is
> specified.
>
>
> Coming finally to your problem. If I understand correctly your *'n1'*
> *USRBIN* should appear at the interface between *C40* and *C51*. The good
> news is that you were almost there. The *ROTPRBIN* card only accept
> direct transformations, while the *star_transform* directive can both
> work with the direct and indirect transformations.
> The solution then will be in front of your eyes: define the the inverse
> of *rot5*, use *-rot5* for the *star_transform* directive use *rot5* for
> the *ROTPRBIN*.
>
> Hope it helps.
> Best,
> Vittorio
>
>
> On Mon, Jul 6, 2015 at 2:15 PM, Oscar Frasciello <
> oscar.frasciello_at_lnf.infn.it> wrote:
>
>> Dear all,
>> I noticed that in the input file I sent in card ROTPRBIN WHAT(6) is
>> wrongly set to 0.0 instead of 1.0. However it does not affect my question,
>> because of running it with the correct WHAT(6)=1.0 returns to give the same
>> wrong results in scored doses.
>> Sorry and thanks again for your support.
>> Cheers
>> Oscar
>>
>> Oscar Frasciello
>> Istituto Nazionale di Fisica Nucleare
>> Laboratori Nazionali di Frascati
>> Accelerator Division
>> Via Enrico Fermi 40
>> 00044 Frascati (RM) Italy
>> Tel. office: +39 06 9403 2710
>> Tel. Tenocode: +39 06 9403 8114
>> Fax Accelerator Division: +39 06 94032256
>> email: oscar.frasciello_at_lnf.infn.it
>>
>> Il 06/07/2015 11:05, Oscar Frasciello ha scritto:
>>
>> Dear FLUKA experts,
>> I'm trying to put a USRBIN grid aligned with the rotated shielding wall
>> of the geometry described in the attached input file. Up to my FLUKA
>> ROTPRBIN card usage understanding, I applied the rotation rot5 to the
>> needed USRBIN (0n and 1n). Of course the rotation is the same applied to
>> the rotated wall. The scored outcomes are absolutely not consistent with
>> the Physics of the problem, whereas a control USRBIN (2n) in which
>> appropriate coordinates where manually set gives correct results. My first
>> hint was that ROTDEFI card could not be applied to catesian binned USRBIN,
>> but a read in FLUKA MANUAL (7.20, card ROT-DEFI) that:
>>
>> "FLUKA binnings (spatial meshes independent of the problem
>> geometry,
>> designed to score average or event-by-event quantities) are
>> generally defined as Cartesian structures parallel to the
>> coordinate axes, or as cylindrical structures parallel to the
>> z-axis. However, it is possible to define binnings with any
>> arbitrary position and direction in space, by means of
>> transformations described by commands ROT-DEFIni and ROTPRBIN.
>> Command ROT-DEFIni defines rotations/translations to be
>> applied
>> to binnings (requested by the user by means of EVENTBIN or
>> USRBIN)."
>>
>> My guess is that for some reason ROTPRBIN is not correctly working. What
>> am I missing? Is there anything I am wrongly understanding?
>>
>> Best regards,
>> Oscar
>>
>> --
>> Oscar Frasciello
>> Istituto Nazionale di Fisica Nucleare
>> Laboratori Nazionali di Frascati
>> Accelerator Division
>> Via Enrico Fermi 40
>> 00044 Frascati (RM) Italy
>> Tel. office: +39 06 9403 2710
>> Tel. Tenocode: +39 06 9403 8114
>> Fax Accelerator Division: +39 06 94032256
>> email: oscar.frasciello_at_lnf.infn.it
>>
>>
>>
>
>
__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
(image/png attachment: image.png)