RE: about MGDRAW and BXDRAW ?

From: Alberto Fasso' (fasso@SLAC.Stanford.EDU)
Date: Sat Jan 14 2006 - 01:26:46 CET

  • Next message: ZAPP, NEAL (JSC-SF2) (LM): "dose equivalent"

    I would like to add some clarification to the answers which have already been
    given by Giuseppe and Chris.

    1) It is true that the manual contains errors or omissions: for instance
       it is not explained how to call BXDRAW. On the other hand, the fact
       that NCASES is not listed as one of the variables in TRACKR is not
       a mistake. NCASES belongs to CASLIM, not to TRACKR, and if you want to use it
       you must remember to insert a line
          INCLUDE '(CASLIM)'
       By the way, to call BXDRAW, use any of the options that activate a call
       to MGDRAW or to ENDRAW. So, use USERDUMP with WHAT(1) = 100. and WHAT(3)
       = 2, 3, 4, 5 or 6 (any of these is ok). But delete all WRITE statements
       under entries MGDRAW and ENDRAW, if you want only a boundary crossing
       dump.

    2) Don't confuse NCASES with NCASE. NCASES is the number of primary particles
       requested in input with command START, NCASE is the number of the current
       primary. They coincide at the end of the run, if the run is not terminated
       prematurely. If you want to know which primary has generated the cirrent
       particle, NCASE is the more appropriate (NCASES is always the same!)

    3) The results of a run are normalized to total weight of primary particles, and
       not to total number of primary particles. In the second of your two-step
       runs, the total normalization weight (written on standard output) is the sum
       of the weights read from the collision tape, but the correct normalization
       should be done using the total primary weight used in the first run (not
       the total number of primaries, unless all primaries have weight 1).
       Therefore all results of the second run should be
       - multiplied by the total weight used in the second run (to undo the
         normalization), and
       - divided by the total weight used in the first run
       This can easily be done by hand, and there is no need to do a
       dangerous manipulation of WEIPRI.

    4) No need to call SODRAW. Information on the number and weight of the primaries
       is at the end of standard output. This is the only information you need:
       you don't need to know which primary has generated a given particle on the
       collision file. (So, there really no need to write NCASE, see 2 above).

    5) files flukaadd.add and emfadd.add (and lowneuadd.add) are distributed only
       with the FLUKA source code. For the standard distribution, the same
       information is found in directory flukapro. This is another piece
       of information that we should correct in the manual.

       Alberto

    On Fri, 13 Jan 2006, Giuseppe Battistoni wrote:

    Dear Maher,
    the BXDRAW entry of MGDRAW can be activated, for instance, with a
    WHAT(3)=2 in the USERDUMP card.
    However: think twice before using this for your problem in
    case you are going to make use of biasing! The management of weights might
    be a critical thing. You need at least a USRBDX estimator to check what
    your doing.

    Anyway, all infos that you mentions are accessible by the (TRACKR)
    common. Unfortunately the manual might still contain some mistake: you
    have to look inside the (TRACKR) file that is contained in the flukapro
    subdirectory inside $FLUPRO:
    $ more $FLUPRO/flukapro/\(TRACKR\) (or cat, lpr, etc.)

            Giuseppe

    On Fri, 13 Jan 2006, Chris Theis wrote:

    > Dear Maher,
    >
    > If I understand you correctly you would like to save particles entering
    > a certain region and restart with them as a kind of 2-step approach.
    > This is certainly possible but you have to be careful about a couple of
    > things. First of all, the region where you would like to save the
    > particles must be set to blackhole and no other material! The reason is
    > that you have to stop the particles at the entry point because otherwise
    > you might store particles that are back-scattered more than once and
    > this will lead to incorrect results. Second, you have to pay attention
    > to the weight of the particles as Giuseppe pointed out. Writing out the
    > weight of each particle is of course required but not enough because the
    > results should be normalized per primary. This means that in the second
    > step you have to have the information available how many primary
    > particles where started and set the WEIPRI variable accordingly.
    >
    > The variables you are looking for:
    >
    > * Number of total particles --> NCASES
    > * Weight of the track --> WTRACK
    > * Energy --> ETRACK - AM(JTRACK) (for the kinetic energy)
    > * Particle type -> Jtrack
    > * Coordinates of particle -> xsco, ysco, zsco
    > * Direction cosines --> cxtrck, cytrck, cztrck
    >
    > I already have an implementation of such a 2-step approach that takes
    > care of the aforementioned things and furthermore can be fully
    > configured via the input file. Consequently, you don't need to adapt the
    > MGDRAW routine for different geometries and regions. In case you would
    > like to use it just drop me a mail and I'll send it to you.
    >
    > Cheers
    > Chris
    >
    > ------------------------------------------------------------------------
    > --
    > Chris Theis
    > CERN/SC-RP - European Organization for Nuclear Research
    > 1211 Geneva 23, Switzerland
    > Phone: +41 22 767 8069 Office: 865-RC-030
    > e-mail: Christian.Theis@cern.ch www: http://www.cern.ch/theis
    > ------------------------------------------------------------------------
    > --
    >
    On Fri, 13 Jan 2006, Maher CHEIKH MHAMED wrote:

    > Date: Fri, 13 Jan 2006 11:34:22 +0100
    > From: Maher CHEIKH MHAMED <cheikh@ipno.in2p3.fr>
    > To: fluka-discuss@fluka.org, support@fluka.org
    > Cc: cheikh@ipno.in2p3.fr
    > Subject: about MGDRAW and BXDRAW ?
    >
    > Dear all Fluka users,
    > Firstly i will present my problem ,
    > I have many configurations of labyrinths to simulate. For this purpose
    > and in order to limit the amount of CPU time for the calculations,
    > I am trying to create a "collision tape" file, in wihch particles
    > information reaching a virtual plane which is the boundary between air
    > and the entry of the labyrinth.
    > As i understood the main informations that fluka needs to transport
    > particles crossing the virtual plane to the entry of the labyrinth are:
    > * Number of total particles
    > *Total weight of the particles
    > *Energy
    > *Particle type
    > *Coordinates of particle
    > *Direction cosines
    > So my questions are:
    > 1/ How to activate BXDRAW in the subroutine MGDRAW with the USERDUMP
    > card ? (I could not found indication in the fluka manual)
    > 2/ Since the location of the beam and the target are so far from the
    > entry of labyrinth and particles should interact with many local
    > shielding materials before reaching the entry of the labyrinth, should
    > i need information of primaries to store in the "collision tape" file
    > with SODRAW ?
    > 3/ If in the INCLUDE file TRACKR (properties of the currently
    > transported particle) i could not found all informations about
    > parameters that i may use especially (Total weight, number of total
    > particles (NTRACK ???) ?
    > In the Fluka manual 2005.6 it was mentionated ".... Files flukaadd.add
    > and emfadd.add contain a full documentation about the meaning of the
    > variables of these INCLUDE files..." but i could not found this in the
    > fluka 2005.6 package.!! how can i get it ?
    >
    > Any helps please,
    > Best regards
    > Maher
    >
    >

    -- 
    Alberto Fassò
    SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
    Phone: (1 650) 926 4762   Fax: (1 650) 926 3569
    fasso@slac.stanford.edu
    

  • Next message: ZAPP, NEAL (JSC-SF2) (LM): "dose equivalent"

    This archive was generated by hypermail 2.1.6 : Sat Jan 14 2006 - 15:31:25 CET