Re: FLUKA2011.2.10 64 bit gfortran and RQDM 2.4 problem

From: paola sala <paola.sala_at_cern.ch>
Date: Mon, 6 Feb 2012 11:30:53 +0100

Dear Denis
The error in RQMD has been found, a respin is in preparation and will be
on the website as soon as possible.
The problem was a mismatch in the type of a function, the old g77 was
automatically casting the different types, gfortran does not.
Although we cannot be sure that no other problem may show up, the
gfortran version should be considered rather stable now.
The respin for the RQMD problem has been a bit delayed because Dr. Anna
Senger reported also about another , apparently independent, problem,
and we would have liked to solve both issues at the same time. Therefore
i take the occasion to ask Dr. Anna Senger to kindly send all the
information needed to investigate her second problem.
Best Regards
Paola

On 02/06/2012 09:23 AM, Bertini, Denis Dr. wrote:
> Dear Giuseppe,
> Dear Fluka developpers,
>
> Thanks for your precious advice about the 64 bit gfortran based FLUKA versi=
> on.
> Unfortunately on the FLUKA download server the fact that this version is st=
> ill experimental is not=20
> clearly mentioned.
>
> Anna Senger has already sent in this forum a detailed diagnostic of a trick=
> y error linked to this version.
> I want to stress it again here: We are facing on the 64 bit gfortran based=
> FLUKA serious problem related to the heavy ion low energy transport RQMD =
> 2.4
> add-on library.
>
> The programs that were running with the "old good " 32 bit g77 based versio=
> n, are now crashing systematically.
>
> The error message is always the same coming from the library:
> "
> Abort called from rrqmd reason rqmd event are being rejected too often Run=
> stopped!
> STOP rqmd event are being rejected too often
> "
> giving us no further hints .
>
> The error is reproducible for ALL gfortran flavour (4.4, 4.51, 4.6.2 ) and =
> ALL corresponding gfortran
> based version available from the server.
> If you need more details about input files used for this test and the compl=
> ete error files please refer to Anna's mail.
>
> Knowing how difficult it is to do a full check of such a complex system =
> like FLUKA on a fast changing gfortran compiler,=20
> i would recommend to put the flag "experimental" to the gfortran based FLUK=
> A version on the server.
>
> With best regards,
>
> Dr Denis Bertini
> IT - Scientific computing
> GSI Helmholtzzentrum f=FCr Schwerionenforschung GmbH
>
> Planckstra=DFe 1=20
> 64291 Darmstadt
> www.gsi.de
>
>
> Gesellschaft mit beschr=E4nkter Haftung=20
> Sitz der Gesellschaft: Darmstadt=20
> Handelsregister: Amtsgericht Darmstadt, HRB 1528
>
> Gesch=E4ftsf=FChrung: Professor Dr. Dr. h.c. mult. Horst St=F6cker,
>
> Peter Hassenbach, Dr. Hartmut Eickhoff
>
>
> Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph=20
> Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt
>
>
>
>
> On Feb 5, 2012, at 11:46 AM, Giuseppe Battistoni wrote:
>
>> I am not sure of other advantages with the 64 bit version.
>> It could be necessary, if you link FLUKA to other libraries at 64 bit.
>> =20
>> However please consider this important caveat:
>> - this 64 bit version of FLUKA is based on the gfortran compiler. Althoug=
> h this is now the standard fortran compiler
>> in linux distributions, we have not yet reached a full confidence in its =
> use with respect to the
>> g77 case.
>> We had many surprises due to problems originanting from different treatme=
> nt of rounding and from the
>> fact that there are evolutions of gfortran from version to version.
>> I repeat to you that it was found (at very high energies) a case in which=
> gfortran 4.4 caused an error,
>> which automatically disappeared with 4.5 version.
>> =20
>> Therefore I invite to consider this gfortran 64 bit version as still an e=
> xperimental distribution.
>> =20
>> Giuseppe Battistoni
>> =20
>> On 03/02/2012 20:53, Mina Nozar wrote:
>>> Dear Denis and Giuseppe,
>>> =20
>>> Hello and thank you for the information.
>>> I was successful building fluka2011.2-linux-gfor64bit-gcc451-AA.tar usin=
> g gcc version 4.4.4.
>>> =20
>>> I did a test run (as I always do with a new installation) and did a quic=
> k comparison (just cpu time) between this set of runs and
>>> the output of fluka2011.2 (32 bit). I see an improvement in the CPU time=
> .
>>> =20
>>> 32 bit:
>>> =3D=3D=3D=3D=3D=3D=3D
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-A001.out: Average=
> CPU time used to follow a primary particle: 1.905E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-A002.out: Average=
> CPU time used to follow a primary particle: 1.882E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-A003.out: Average=
> CPU time used to follow a primary particle: 1.877E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-B001.out: Average=
> CPU time used to follow a primary particle: 1.864E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-B002.out: Average=
> CPU time used to follow a primary particle: 1.861E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-B003.out: Average=
> CPU time used to follow a primary particle: 1.922E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-C001.out: Average=
> CPU time used to follow a primary particle: 1.900E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-C002.out: Average=
> CPU time used to follow a primary particle: 1.888E-03 seconds
>>> ../../fluka_2011.2.10_flair_0.9-7/fluka01/test_general-C003.out: Average=
> CPU time used to follow a primary particle: 1.885E-03 seconds
>>> =20
>>> =20
>>> 64 bit:
>>> =3D=3D=3D=3D=3D=3D=3D
>>> test_general-A001.out: Average CPU time used to follow a primary particl=
> e: 9.119E-04 seconds
>>> test_general-A002.out: Average CPU time used to follow a primary particl=
> e: 1.304E-03 seconds
>>> test_general-A003.out: Average CPU time used to follow a primary particl=
> e: 1.088E-03 seconds
>>> test_general-B001.out: Average CPU time used to follow a primary particl=
> e: 1.293E-03 seconds
>>> test_general-B002.out: Average CPU time used to follow a primary particl=
> e: 1.330E-03 seconds
>>> test_general-B003.out: Average CPU time used to follow a primary particl=
> e: 1.302E-03 seconds
>>> test_general-C001.out: Average CPU time used to follow a primary particl=
> e: 1.298E-03 seconds
>>> test_general-C002.out: Average CPU time used to follow a primary particl=
> e: 1.315E-03 seconds
>>> test_general-C003.out: Average CPU time used to follow a primary particl=
> e: 1.215E-03 seconds
>>> =20
>>> =20
>>> The machines we have been running fluka on are 64 bit machines but so fa=
> r, we have been building and running the 32 bit versions of
>>> fluka. We are trying to decide whether to move on the building and runni=
> ng the 64 build. Aside from the CPU advantage, are there
>>> other advantages to go the 64 bit route?
>>> =20
>>> =20
>>> By the way, the INSTALLATION INSTRUCTIONS in the README files for both f=
> luka2011.2-linux-gfor64bit-AA.tar
>>> fluka2011.2-linux-gfor64bit-gcc451-AA.tar
>>> state the following which is misleading. Since this is the file everyone=
> would look through for instructions on installations, can I
>>> please ask that they be updated with future releases of fluka?
>>> =20
>>> Thank you and best wishes,
>>> Mina
>>> =20
>>> =20
>>> INSTALLATION INSTRUCTIONS
>>> -------------------------
>>> Different packages can be downloaded from the FLUKA Website www.fluka.or=
> g:
>>> =20
>>> o 32 bits, requires gcc/g77 (version>=3D 3.4)
>>> - Linux x86 (tar.gz package): fluka2011.2-linuxAA.tar.gz
>>> - Linux x86 (rpm installer): fluka2011.2-i686.rpm
>>> =20
>>> o 64 bits, requires gcc/gfortran (version>=3D 4.4)
>>> - Linux x86_64 (tar.gz package): fluka2011.2-linux-gfor64bitAA.tar.gz
>>> =20
>>> =20
>>> On 12-02-02 11:58 PM, Bertini, Denis Dr. wrote:
>>>> Hi Mina
>>>> =20
>>>> if you used the gcc4.4 version then you should take the FLUKA version p=
> re-compiled with gcc451
>>>> =20
>>>> fluka2011.2-linux-gfor64bit-gcc451-AA.tar
>>>> =20
>>>> The default libraries you have choosen on the FLUKA server is compiled =
> with gfortran 4.6 which creates
>>>> uncompatible symbols as you experienced.
>>>> =20
>>>> Dr Denis Bertini
>>>> IT - Scientific computing
>>>> GSI Helmholtzzentrum f=3DFCr Schwerionenforschung GmbH
>>>> =20
>>>> Planckstra=3DDFe 1
>>>> 64291 Darmstadt
>>>> www.gsi.de
>>> =20
>>> On 12-02-02 11:55 PM, Giuseppe Battistoni wrote:
>>>> Dear Mina
>>>> Unfortunately, as previously reported in our discussion list in the las=
> t 2 o 3 months,
>>>> we have the gfortran version of FLUKA only for gfortran versions 4.5 or=
> 4.6
>>>> (fluka2011.2-linux-gfor64bit-gcc451-AA and fluka2011.2-linux-gfor64bitA=
> A respectively)
>>>> =20
>>>> We found that the us of gfortran compiler in version 4.4 (or earlier) g=
> ives rise to
>>>> important bugs.
>>>> =20
>>>> For unknown reasons gfortran developers decided to change a lot of inte=
> rnal names
>>>> in recent versions, and that is the reason of those error messages.
>>>> =20
>>>> Therefore, either you upgrade to gcc4.5 (or better gcc4.6) or you stick=
> to the old good
>>>> 32-bit g77 version.
>>>> Giuseppe Battistoni
>>> =20
>>> =20
>>>> On Feb 2, 2012, at 9:24 PM, Mina Nozar wrote:
>>>> =20
>>>>> Hi all,
>>>>> =20
>>>>> I was able to install fluka2011.2.10 and flair-0.9-7 with no problems.
>>>>> =20
>>>>> I am now trying to build the 64 bit fluka2011.2.10 binaries using fluk=
> a2011.2-linux-gfor64bitAA.tar.gz and am seeing a
>>>>> lot of error messages of the sort:
>>>>> =20
>>>>> /NOT_BACKED_UP/home/nozarm/fluka/2011.2.10-64/libflukahp.a(nunki1.o): =
> Infunction `nunki1_':
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:232: undefined reference =
> to`_gfortran_transfer_integer_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:224: undefined reference =
> to`_gfortran_transfer_character_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:224: undefined reference =
> to`_gfortran_transfer_integer_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:224: undefined reference =
> to`_gfortran_transfer_character_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:224: undefined reference =
> to`_gfortran_transfer_integer_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:225: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:225: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:225: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:225: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki1.f:226: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /NOT_BACKED_UP/home/nozarm/fluka/2011.2.10-64/libflukahp.a(nunki1.o):/=
> home/alfredo/fluprogfor/nundismvax/nunki1.f:226:
>>>>> more undefined references to `_gfortran_transfer_real_write' follow
>>>>> /NOT_BACKED_UP/home/nozarm/fluka/2011.2.10-64/libflukahp.a(nunki2.o): =
> Infunction `nunki2_':
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:824: undefined reference =
> to`_gfortran_transfer_character_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:825: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:825: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:825: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:825: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> /home/alfredo/fluprogfor/nundismvax/nunki2.f:825: undefined reference =
> to`_gfortran_transfer_real_write'
>>>>> ...
>>>>> ...
>>>>> ...
>>>>> /NOT_BACKED_UP/home/nozarm/fluka/2011.2.10-64/libflukahp.a(nunhqk.o): =
> Infunction `nunhqk_':
>>>>> /home/alfredo/fluprogfor/nundismvax/nunhqk.f:120: undefined reference =
> to`_gfortran_transfer_character_write'
>>>>> collect2: ld returned 1 exit status
>>>>> make[1]: Leaving directory `/NOT_BACKED_UP/home/nozarm/fluka/2011.2.10=
> -64/flutil'
>>>>> =20
>>>>> =20
>>>>> Any ideas as to what could be wrong?
>>>>> We have gcc4.4 installed on our 64 bit machine and I have set environm=
> ent variables
>>>>> FLUFOR to gfortran
>>>>> and
>>>>> FLUPRO to /NOT_BACKED_UP/home/nozarm/fluka/2011.2.10-64
>>>>> =20
>>>>> gcc -v
>>>>> Using built-in specs.
>>>>> Target: x86_64-redhat-linux
>>>>> Configured with: ../configure --prefix=3D3D/usr --mandir=3D3D/usr/shar=
> e/man --infodir=3D3D/usr/share/info
>>>>> --with-bugurl=3D3Dhttp://bugzilla.redhat.com/bugzilla --enable-bootstr=
> ap --enable-shared --enable-threads=3D3Dposix
>>>>> --enable-checking=3D3Drelease --with-system-zlib --enable-__cxa_atexit=
> --disable-libunwind-exceptions
>>>>> --enable-gnu-unique-object --enable-languages=3D3Dc,c++,objc,obj-c++,j=
> ava,fortran,ada --enable-java-awt=3D3Dgtk --disable-dssi
>>>>> --with-java-home=3D3D/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-=
> libgcj-multifile --enable-java-maintainer-mode
>>>>> --with-ecj-jar=3D3D/usr/share/java/eclipse-ecj.jar --disable-libjava-m=
> ultilib --with-ppl --with-cloog --with-tune=3D3Dgeneric
>>>>> --with-arch_32=3D3Di686 --build=3D3Dx86_64-redhat-linux
>>>>> Thread model: posix
>>>>> gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
>>>>> =20
>>>>> =20
>>>>> Thanks in advance,
>>>>> Mina
>>>>> =20
>>>> =20
>> =20
>> =20
>> --=20
>> Director of INFN Milano
>> via Celoria 16
>> 20133 Milano, Italy
>> tel. +39 02 50317649
>> fax +39 02 70601811
>> =20
Received on Thu Feb 09 2012 - 09:53:31 CET

This archive was generated by hypermail 2.2.0 : Thu Feb 09 2012 - 09:54:02 CET