Trouble compiling on Cray SLES-15 (AMD EPYC chips)

[Sheppard, Raymond W]

Hello,
I seem to be having an issue posting to the Installation thread of the Forum Edoardo Apra suggested I send my issue here.

I am having type mismatch errors when I try to build NWChem 6.8.1. Seemingly it is not happy with f2c in the cray-libsci module. However, I built a separate f2c from NetLib and used it, but saw no change.

My initial settings are:

rsheppar@login1:/N/soft/sles15/nwchem/build/nwchem-6.8.1/src> cat ../*.bash
#############
export NWCHEM_TOP=/N/soft/sles15/nwchem/build/nwchem-6.8.1
export NWCHEM_TARGET=LINUX64
export ARMCI_NETWORK=MPI-PR
export NWCHEM_MODULES=all
export USE_NOFSCHECK=TRUE
export USE_NOIO=TRUE
export NWCHEM_EXECUTABLE=/N/soft/sles15/nwchem/gnu/cpu/6.8.1/nwchem
export ARMCI_NETWORK=MPI-PR
export USE_64TO32=y
export USE_MPI=y
export BLAS_SIZE=4
export LAPACK_SIZE=4
export SCALAPACK_SIZE=4
export SCALAPACK=-lsci_gnu_mp
export BLASOPT=-lsci_gnu_mp
export FC=ftn
export CC=cc
export NWCHEM_MPIF_WRAP=ftn
export NWCHEM_MPIC_WRAP=cc
export NWCHEM_MPICXX_WRAP=CC

#######################

It gets picked up as:

1/src> head -30 tools/build/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Global Arrays (GA) configure 5.6.5, which was
generated by GNU Autoconf 2.69. Invocation command line was

$ ../ga-5.6.5/configure --prefix=/geode2/soft/hps/sles15/nwchem/build/nwchem-6.8.1/src/tools/install --with-tcgmsg --with-mpi --enable-peigs --enable-underscoring --disable-mpi-tests --with-scalapack=-lsci_gnu_mp --without-lapack --with-blas4=-lsci_gnu_mp --with-mpi-pr CC=cc MPICC=cc CXX=CC MPICXX=CC F77=ftn MPIF77=ftn ARMCI_DEFAULT_SHMMAX_UBOUND=131072

## --------- ##
## Platform. ##
## --------- ##

hostname = login1
uname -m = x86_64
uname -r = 5.3.18-22-default
uname -s = Linux
uname -v = #1 SMP Wed Jun 3 12:16:43 UTC 2020 (720aeba)

/usr/bin/uname -p = x86_64
/bin/uname -X = unknown

/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /opt/cray/pe/mpich/8.1.5/ofi/gnu/9.1/bin
------------------------------------------------------------

This results in this to stdout:

libtool: compile: ftn -DHAVE_CONFIG_H -I. -I../ga-5.6.5 -Ima -I../ga-5.6.5/ma -I../ga-5.6.5/LinAlg/lapack+blas -Iglobal/src -I../ga-5.6.5/global/src -I../ga-5.6.5/global/testing -I../ga-5.6.5/pario/dra -I../ga-5.6.5/pario/eaf -I../ga-5.6.5/pario/elio -I../ga-5.6.5/pario/sf -Igaf2c -I../ga-5.6.5/gaf2c -I../ga-5.6.5/tcgmsg -I../ga-5.6.5/tcgmsg/tcgmsg-mpi -I../ga-5.6.5/armci/src/include -I../ga-5.6.5/armci/tcgmsg -fdefault-integer-8 -fno-aggressive-loop-optimizations -c ../ga-5.6.5/ma/maf.F -o ma/maf.o
../ga-5.6.5/ma/maf.F:31:34:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
30 | $ MA_FALSE) return
31 | if (f2c_inform_base(MT_INT, int_mb(1), int_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(8)/CHARACTER(*)).
../ga-5.6.5/ma/maf.F:33:34:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
......
33 | if (f2c_inform_base(MT_LOG, log_mb(1), log_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (LOGICAL(8)/CHARACTER(*)).
../ga-5.6.5/ma/maf.F:35:35:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
......
35 | if (f2c_inform_base(MT_REAL, real_mb(1), real_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(4)/CHARACTER(*)).
../ga-5.6.5/ma/maf.F:37:34:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
......
37 | if (f2c_inform_base(MT_DBL, dbl_mb(1), dbl_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/CHARACTER(*)).
../ga-5.6.5/ma/maf.F:39:35:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
......
39 | if (f2c_inform_base(MT_SCPL, scpl_mb(1), scpl_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/CHARACTER(*)).
../ga-5.6.5/ma/maf.F:41:35:

29 | if (f2c_inform_base(MT_BYTE, byte_mb(1), byte_mb(2)) .eq.
| 2
......
41 | if (f2c_inform_base(MT_DCPL, dcpl_mb(1), dcpl_mb(2)) .eq.
| 1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(8)/CHARACTER(*)).
make[4]: *** [Makefile:7863: ma/maf.lo] Error 1
make[3]: *** [Makefile:8272: all-recursive] Error 1
make[2]: *** [Makefile:5166: all] Error 2
make[1]: *** [GNUmakefile:654: build/.libs/libga.a] Error 1

--------------------------------------------------------------------------

Searching "error" in the config.log shows some vaguely familiar etime and dtime errors from years past, as well as some which seem to expected (tests). I didn't see much else for error or "f2c" either. Any help would be appreciated. Thanks.
Ray

[Edoardo Aprà]

Could you provide more details about the Cray environment?

What is the output out the commands

ftn -V

module list

[jeff.science]

This is a known issue (https://github.com/GlobalArrays/ga/issues/157) that was already fixed in GA 5.7.1.  Please use a newer version of NWChem, use a newer version of GA (./get-tools-github in src/tools might help) or try to compile GA with FFLAGS=-fallow-argument-mismatch or FFLAGS=-std=legacy

Jeff

[Ray Sheppard]

Thanks Jeff.Science,

  As you might be able to see in my excerpts, but I apologize if I was not clear, these errors are coming out of NWChem version 6.8.1.  Do you really have a newer version?  I will try the compile switches you suggested.  Thanks for the help.

       Ray

[Ray Sheppard]

I guess I answered my own question.  Y'all have released version 7 that I missed.  I will try that one.  Sorry to be a problem.

On Wednesday, October 27, 2021 at 2:51:58 PM UTC-4 jeff.science wrote:

[Edoardo Aprà]

I don't think 7.0.2 is quite ready for the current Cray SW stack.

Instead of waiting for the next release, the only option is to use the master branch from the github repository.

You can download the current master branch with the command

git clone https://github.com/nwchemgit/nwchem

[Sheppard, Raymond W]

Thanks Edoardo, but I got it to build. I have only done a cpu version and I have not tested it. But building went fine. It passed over the trouble spot with just dozens of warnings that say something similar to:

Warning: Type mismatch in argument 'psi_r' at (1); passed REAL(8) to COMPLEX(8)

Which were errors in 6.8.1. It is troublesome to see them (as well as a bunch of rank mismatches), but if y'all don't mind them, I guess I don't either. I still need to do the gpu versions and test both versions. We are sort of learning as we go along. This is my first Cray that does not use a Cray OS (it is SLES 15) I still miss UNICOS and NQE. It is also my first machine with over 100 ranks on a node (128 cores). So I have a hard time separating troubles with the configuration from actual troubles (for example, I have learned it is possible to saturate I/O bandwidth on some MPI codes well short of 128 ranks). Thanks for being patient while I figure it out. When I ask another question in another 10 years, I hope whatever login system is at play will actually remember me :)
Ray

________________________________________
From: nwchem...@googlegroups.com <nwchem...@googlegroups.com> on behalf of Edoardo Aprà <edoard...@gmail.com>
Sent: Wednesday, October 27, 2021 8:33 PM
To: NWChem Forum
Subject: [External] [nwchem-forum] Re: Trouble compiling on Cray SLES-15 (AMD EPYC chips)

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

git clone https://github.com/nwchemgit/nwchem

Jeff

My initial settings are:

#######################

PATH: /opt/cray/pe/mpich/8.1.5/ofi/gnu/9.1/bin
------------------------------------------------------------

--------------------------------------------------------------------------

--
You received this message because you are subscribed to a topic in the Google Groups "NWChem Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nwchem-forum/Dwl2HhIIiXA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nwchem-forum...@googlegroups.com<mailto:nwchem-forum...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/nwchem-forum/b3d60362-9f1e-4258-aa11-9d1238eec23en%40googlegroups.com<https://groups.google.com/d/msgid/nwchem-forum/b3d60362-9f1e-4258-aa11-9d1238eec23en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[jeff.science]

Those warnings are troublesome from the perspective of a Fortran language lawyer but they do not matter in practice.  Many parts of NWChem were written during the "old days" of computing when compilers trusted programmers to write correct code, and did not complain about type mismatching etc.  These new-fangled compilers and language standards have becoming increasingly aggressive and demand that declarations not only exist, but match the usage when called.

Sadly, for the first decade or so after NWChem was created, Fortran compiler support for modern features was pretty bad, and thus many unfortunate design patterns were baked in.  For reference, when I started working on NWChem in 2006, one needed a vendor compiler license to do anything with Fortran 90+, because GCC was still using g77.  It took some years before gfortran became a high-quality modern Fortran compiler.  And, as some folks know, in 2021 it is still hard to find a rigorously compliant Fortran 2008 compiler.  Fortran 2003 is about all we can bank on.

Jeff