Re: Fixes for early problems in the 64 bit version of Fluka

Dear Joe

the

' *** RUN TERMINATION FORCED FROM SOURCE ***'

message is issued if and only if the source routines return with its
(only) argument, the integer variable nomore, equal to 1.

Check your source routine, and/or if it has been compiled coherent
with the FLUKA library. Did you use the fff script with all environment
variables set? About knowing if the executable is 32 or 64 bit,
issuing "file <executable name>" will give you the answer.

Let me know if you find where the problem is, if not if they are not big
send us the relevant files to try to solve the issue.

                 Ciao
                Alfredo

+----------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.76.76119 |
| CERN-EN/STI || Fax.: +41.22.76.69474 |
| 1211 Geneva 23 || e-mail: Alfredo.Ferrari_at_cern.ch |
| Switzerland || |
+----------------------------------------------------------------------+

On Thu, 7 Jul 2011, Joseph Comfort wrote:

> Hi Alfredo,
>
> Thanks for the update. The geometry seems to work now. However, something
> else has gone wrong with the code.
>
> I collect events between stages and read them with a source.f routine from a
> file in the next stage. The latest 64-bit code processes *only 1 event*.
> The output, including lines from my code, contains:
>
> NEXT SEEDS: 0 0 0 0 0 0 1 3039
> 0 0
> Opened input ntuple file
> /home/comfort/fluka/e14_2011/nickel/ni30_01/events_n1.hbook 1512359 events
> Source: 1 1 0.36928644776344299 -0.31745356321334839
> 14.491820335388184
> Opened output ntuple file ../ni30_n001.hbook
> 1 99 99 4.7692871E-01
> 1.0000000E+30 4
> NEXT SEEDS: 537F 0 0 0 0 0 1 3039
> 0 0
> Number of source particles = 1
> *** RUN TERMINATION FORCED FROM SOURCE ***
> Feeder ended due to timeout.
>
> The file is opened and the correct number of events is reported. But there
> is some sort of a timeout.
>
> Related information:
> 1) The (latest) 32-bit version works correctly.
> 2) The previous 64-bit code, with nearly the same source.f routine,
> worked correctly for a different geometry/data configuration.
> 3) The code in item #2 (recompiled/linked) is also broken now.
>
> It's surprising and perplexing.
>
> One suggestion I might make is that it would be helpful if the code could
> print out which version (32/64 bit) it is.
>
> Thank you,
> Joe Comfort
>
Received on Fri Jul 08 2011 - 09:23:42 CEST