Re: Emailing: endwall_v9e001.err

From: Francesco Cerutti (Francesco.Cerutti@cern.ch)
Date: Wed Jan 24 2007 - 10:43:46 CET

  • Next message: Francesco Cerutti: "RE: lattice with new format"

    Hi Martin,

    1. the Comptn_2 messages indicate a bad cosine normalization
    (abs(1-u**2-v**2-w**2)>10^-12) which is immediately corrected.

    As for Geofar and GEOMETRY SEARCH ARRAY FULL, just quoting the manual
    (Error messages):

    2. "The following message indicates a real problem if repeated more than a
    few times:

       GEOFAR, TXYZ: 1. -0.0721463599 -0.409276348 -0.909553612
          Nfrom, Nreg, X, Y, Z 1001 3 -0.108787724 -1.26878781 8.78769155

      Geofar: Particle in region 3 (cell # 0) in position 1.000000000E+00
      0.000000000E+00 1.000000000E+00
       is now causing trouble, requesting a step of 6.258867675E-07 cm
       to direction -2.285059979E-01 -9.412338141E-01 2.487245789E-01, error
    count: 0
       [...skipped...]
       Particle index 3 total energy 5.189748600E-04 GeV Nsurf 0
      We succeeded in saving the particle: current region is n. 2 (cell #
    0)

      As it can be seen, the program has some difficulty to track a particle in
      a certain direction, and it tries to fix the problem by "nudging" the
      particle by a small amount, in case the problem is due to a rounding
      error near a boundary. If the message appears often, it is recommended to
      run the geometry debugger centreing around the position reported in order
      to find if there is an error in the geometry description".

    3. "Another geometry error message is the following:

                      ****************************************
                             GEOMETRY SEARCH ARRAY FULL
                      ****************************************

      This message indicates that insufficient memory has been allocated for
      the "contiguity list" (list of zones contiguous to each zone). This is
      not an actual error, but it is suggested that the user could optimise
      computer time by increasing the values of the NAZ variable in the
      geometry region specifications".

      About that, a more extensive explanation by Alberto Fasso' follows:

    "The message means the following.
    To save time, for each region, FLUKA sets up a list of "neighbor
    regions" to be tested first when a particle leaves any of the
    bodies making up that region.
    If the new region is not found in the list, the other regions
    are searched. When found, the region is added to the list of
    neighbors, provided there is enough space left in the array.
    The space allocated is by default 5 neighbors per region, which is
    normally more than sufficient. The value can be modified by the user
    as explained in the manual (description of region data)

      => the integer in columns 6-10 is the number of regions which can be
         entered by a particle leaving any of the bodies defined for the
         region being described (leave blank in continuation cards). This
         number is used to allocate memory, and it is not essential that it
         be exact (if left blank, it is set to 5). Any number is accepted,
         but if it is close to the actual value it may slightly improve
         tracking speed.

    Note that memory allocation is done globally, not region by region,
    I suspect that you have set those numbers to a very small value
    (1 or 2), because I always work with the default and I have never
    got that message.
    Anyway, in general, experience shows that CPU time is not
    strongly affected by this setting, unless you have an enormous number
    of regions through which FLUKA loops every time a particle exits a
    region".

    Cheers

    Francesco

    **************************************************
    Francesco Cerutti
    CERN-AB
    CH-1211 Geneva 23
    Switzerland
    tel. ++41 22 7678962
    fax ++41 22 7668854


  • Next message: Francesco Cerutti: "RE: lattice with new format"

    This archive was generated by hypermail 2.1.6 : Wed Jan 24 2007 - 14:08:31 CET