[DFTB-Plus-User] Compiling dftb+ (1.2/1.2.1) with AMD Open64 4.5.1 compiler. Error on SELECT CASE (type(string))

[Nick Papior Andersen]

Hi all.

I am currently trying to build my own executable to get the best
performance and extensions for my platform.
I have tried searching the list for information without luck.

So what I have done is used a make file as the following:

I have created sysmakes/make.x86_64-open64 with contents:
# >>>> Start of content: sysmakes/make.x86_64-open64
FC90 = openf95-4.5.1
FC90OPT = -O2 -m64 -mp
CPP = cpp -traditional
CPPOPT = -DDEBUG=$(DEBUG) #-DEXTERNALERFC
CPPPOST = $(ROOT)/utils/fpp/fpp.sh nocntln # have also tried "general"
LN = $(FC90) -static
LNOPT = $(FC90OPT)
ATLASDIR = /applications/nicpasoft/acml/5.1.0/open64_64_mp/lib
LIBOPT = -L$(ATLASDIR)
# How to link specific libraries
LIB_LAPACK = -lacml_mp
LIB_BLAS = $(LIB_LAPACK)
# <<< End of sysmakes/make.x86_64-open64

I then edit Makefile.user to use make.x86_64-open64.

So far so good. The compilation of the executable is completed flawless if
I edit the fpp utils-files to create continuation lines at 119 chars (due
to default in Open64 compiler). I have tried with both "general" and
"nocntln" in fpp processing. They both "worked".

I compile using:
make distclean
make
make test

On "make test" it all (almost) goes wrong. I get the following output:
 ==============================================================================
TEST SUMMARY
------------------------------------------------------------------------------
Match:
non-scc/Si_2 scc/C4H8_3rdfull
non-scc/GaAs_2 scc/C4H8_3rdfull-damp
non-scc/CH4 scc/H2O2_3rdfull
non-scc/HBDI-neutral scc/H2O2_3rdfull-damp
non-scc/HBDI-cationic spin/H2O
non-scc/decapentaene spin/H2O-periodic
non-scc/10-0Ctube spin/GaAs_2
non-scc/10-10Ctube spin/H2
non-scc/Si41C23N35 spin/Fe4
non-scc/Si_384 md/Si_8
non-scc/Si_216 md/H3
scc/GaAs_2 md/Si_8-thermostat
scc/SiC_64 md/Si_8-thermostat2
scc/C60 md/Si_8_restart
scc/H3 md/Si_8_NHC
scc/H2O-extchrg md/Si_8_NHC_restart
scc/H2O-extchrg-periodic md/SiH-surface
scc/H2O-extchrg-blur md/ice_Ic
scc/2H2O-3rdorder md/H2O-extfield
scc/H2O+CH3COOH-3rdorder dispersion/DNA-damped
scc/H2O-extchrg-direct dispersion/2H2O_uff
scc/H2O-extfield spinorbit/GaAs_2
scc/10-0Ctube-extfield spinorbit/Si_2
scc/C2H6_3rdfull spinorbit/Fe2_dual
scc/C2H6_3rdfull-damp

Not run:
spin/Fe4_noncolinear geoopt/Cchain_lattice
geoopt/H2O md/Si_8-tempprofile
geoopt/H2O-constr md/DNA
geoopt/H2O-nonscc dispersion/2H2O
geoopt/Vsi+O-nonscc dispersion/DNA
geoopt/Vsi+O derivatives/C6H6_scc
geoopt/Si_2_latconst dftb+u/Fe4
geoopt/Si_2_lattice dftb+u/GaAs_2
geoopt/GaAs_8_latconst dftb+u/CH3
geoopt/diamond_presure spinorbit/Fe2
geoopt/diamond_isotropic spinorbit/EuN
------------------------------------------------------------------------------
Status: FAIL
------------------------------------------------------------------------------
Details in:
_autotest/stderror.log
_autotest/tagdiff.log
==============================================================================

All "Not run" are having the "TODO" mark. I attached an out file which
contains the last lines of the output files after the ERROR statement for
all the runs with TODO.
 A few of them, for simplicity:
>>>>>>> geoopt/Cchain_lattice:
ERROR!
-> Invalid driver 'ConjugateGradient'
Path: dftb_in/Driver
Line: 12-17 (File: dftb_in.hsd)

<<<<<<< geoopt/Cchain_lattice

>>>>>>> md/DNA:
ERROR!
-> Invalid method for PolarRadiusCharge.
Path:
dftb_in/Hamiltonian/DFTB/Dispersion/SlaterKirkwood/PolarRadiusCharge/HybridDependentPol
Line: 99-124 (File: dftb_in.hsd)

<<<<<<< md/DNA

Ok, so the reason for these TODO marks are that the comparison of the
SELECT CASE statements are not comparing correctly.
I checked all cases in the code where this error came through. In all cases
it was due to a comparison performed by either of the following two
statements:

SELECT CASE (char(buffer))
or
SELECT CASE (tolower(char(buffer)))

buffer is in both cases: TYPE(string)

I am not fully sure whether this is a bug in the compiler (I do not suspect
this) or a bug in the string module (ext_lib/m_strings.f90).

However, from my own experience with CHARACTER there will be problems with
allocatable characters which are not initialised. In that case they are not
defaultet to a BLANK char but a 0-length ""-value. There are a few cases
were this could occur in the m_strings library, for instance if an
allocated character , which is then undefined, gets assigned to a
type(string). This will copy over the undefined value to the string and
hence not initialized to ' '.

Below is an example of what I suspect goes wrong.
There are two ways of comparing the arrays, and they are in fact very
different in behaviour! Which is quite unintended (I believe).
Consider a program as this:
  program sc
   character(len=2) :: a
   character , pointer :: b(:) => null()
   allocate(b(2))

   a = 'A' ! a is actually now 'A '
   b(1) = 'A' ! b is actually now 'A' and an undefined char!

   select case(a)
   case('A')
     print *,"Success"
   end select

   select case(transfer(b,a)) ! They have same length so this will do
   case('A')
     print *,"This will not execute" ! And this is extremely weird, but due
to b(2) not existing in the case statement! It is undefined.
   case default
     print *,"Error"
   end select
 end program sc

It seems that it cannot do comparisons of type(string) in select case
statements if any of the chars are undefined. I tried explicitly creating a
char array and do

cbuf = char(buffer) ; select case(cbuf)

which then worked (however, this can not be generalised to the above
statements). I am not entirely sure why and how it was bypassed.

Have anybody seen this? And ever better, a solution?

Sadly my gfortran compiler on the system is too old to comply with the F95
extensions used so I would very much like to stay with the open64 compiler.
It should be noted that I have tried with no optimization as well, just to
rule that one out. Still no success.

Kind regards Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.dftb-plus.info/pipermail/dftb-plus-user/attachments/20120720/330f8f68/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.dat
Type: application/octet-stream
Size: 3627 bytes
Desc: not available
URL: <http://www.dftb-plus.info/pipermail/dftb-plus-user/attachments/20120720/330f8f68/attachment.obj>