Ciao Vittorio,
many many thanks! You definitely solved my problem, indeed I did not
have any look at the lecture you linked me to, so I could not appreciate
the fine usage of ROT-DEFI combined with USRBIN. The magic now is not
only the correct setup of the simulation, but also the fancy trick you
have described to check USRBIN in Flair.
Many thanks again!
Cordially,
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 07/07/2015 20:23, Vittorio Boccone ha scritto:
> 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.
>
> Inline image 1
>
> On Tue, Jul 7, 2015 at 3:04 PM, Oscar Frasciello
> <oscar.frasciello_at_lnf.infn.it <mailto: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:%2B39%2006%209403%202710>
> Tel. Tenocode:+39 06 9403 8114 <tel:%2B39%2006%209403%208114>
> Fax Accelerator Division:+39 06 94032256 <tel:%2B39%2006%2094032256>
> email:oscar.frasciello_at_lnf.infn.it <mailto: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
>> <mailto: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:%2B39%2006%209403%202710>
>> Tel. Tenocode:+39 06 9403 8114 <tel:%2B39%2006%209403%208114>
>> Fax Accelerator Division:+39 06 94032256 <tel:%2B39%2006%2094032256>
>> email:oscar.frasciello_at_lnf.infn.it <mailto: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:%2B39%2006%209403%202710>
>>> Tel. Tenocode:+39 06 9403 8114 <tel:%2B39%2006%209403%208114>
>>> Fax Accelerator Division:+39 06 94032256 <tel:%2B39%2006%2094032256>
>>> email:oscar.frasciello_at_lnf.infn.it <mailto:oscar.frasciello_at_lnf.infn.it>
>>
>>
>
>
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id=acc_info
Received on Tue Jul 07 2015 - 23:26:03 CEST