Dear Mina Vittorio and all FLUKA experts,
owing to your valuable suggestions I was able to solve all my troubles
for the case under study.
Thanks a lot.
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 07/07/2015 22:38, Mina Nozar ha scritto:
> Hello Oscar,
>
> I had to struggle with a similar issue a while back. Here is a KEY
> point from Vasilis (not in the documentation but in some advanced
> geom. lecture).
>
> "the ROTPRBIN is not transforming the USRBIN to the scoring space but
> the scoring space (or the particles) to the USRBIN. So you have to use
> the inverse transformation."
>
> I have modified your input file. Take a look and see whether you can
> follow and understand it. I have also included two layers (0n and 1n)
> for you to visualize the usrbin score cards after applying the
> rotation (Rot0n_01). Check the geometry editor (XZ view and change
> the layer to 0n and 1n to see them).
>
> I added another usrbin card to be able to see the beam. Plot the xz
> view (Green plot) and save it for viewing the BeamPart distribution or
> set the Geometry to 'No' or 'Auto'.
>
> Check your biasing cards. You had C5 to Lastreg set to imp of 1, C50
> to 2048, and then increasing by a factor of two for other regions.
> Setting the importances for individual regions overrides the imp. of 1
> set in a preceding card, so that's fine. And maybe you had a reason
> for doing this... So, either ignore my changes and go with what you
> had or just double check.
>
> Hope this helps a bit,
> Mina
>
> On 15-07-07 06:04 AM, Oscar Frasciello 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 <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 Wed Jul 08 2015 - 16:39:21 CEST