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 - 00:30:03 CEST