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 <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 - 17:41:49 CEST