[Rivet] [LHAPDF] Internal compiler error

Andy Buckley andy.buckley at durham.ac.uk
Thu Dec 11 12:17:52 GMT 2008


James Monk wrote:
> Hi,
> 
> I can confirm I also see this problem in LHAPDF 5.6 using gfortran  
> (gcc 4.4) from hpc.sourceforge.net.  Did you, Chistopher, also get  
> gfortran from hpc?    I attach my config.log to http://www.hep.ucl.ac.uk/~jmonk/lhapdf/config.log
> 
> However, I have no such problems with lhapdf 5.3.1, which I think is  
> fine to use with Rivet.

The neural net PDFs (the "NNPDF" in the error) are new in 5.6.0, so I
think that any version up to 5.5.x should be okay. This will need to be
investigated and fixed for LHAPDF 5.6.1.

> I notice that a difference in the build  
> options between the two is that 5.6 adds -ffree-form to gfortran  
> compilation.  I googled free-form to try and discover what it does,  
> and a lot of the hits are bug discussions for OS X!  In any case, free- 
> form specifies that he code is using a new (post fortran 90) dialect  
> of fortran.  I would have thought LHAPDF would want to be compatible  
> with g77, in which case free-form should not be necessary.

Actually, the core LHAPDF infrastructure code was moved to F90 in
version 5.5.0 (I think) to resolve a fundamental problem with common
block initialisation in the modern world of shared libraries (how the
BLOCK DATA initialisation actually works is very, very ugly, and doesn't
port to non-monolithic code --- F90 modules solve the problem). Due to
LCG restrictions, we backtracked and hacked in a sort-of-reliable way to
initialise the common blocks, but the free-form source formatting remains.

Andy

-- 
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org


More information about the Rivet mailing list