Unable to compile next on Marconi

[Michael Hardman]

For the purpose of resolving the conflicts in the branch features/simple-hyperviscosity with next, I am attempting to check out a version of next and compile it on Marconi. I find the following error messages. I am able to compile origin/master, so there is no problem with my environment. Could you please advise on how to fix this? My commands and error message are below. Any help appreciated, Michael

‌

\$ git clone https://bitbucket.org/gyrokinetics/gs2.git --recurse-submodules gs2

\$ cd gs2

\$ git checkout next

\$ ./build_gs2

Compiling : /marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/generated_src/spfunc.f90

/marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/generated_src/spfunc.f90(52): error #6404: This name does not have a type, and must have an explicit type. [J0]

public :: j0, j1

• -----------^

/marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/generated_src/spfunc.f90(52): error #6404: This name does not have a type, and must have an explicit type. [J1]

public :: j0, j1

• ---------------^

/marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/generated_src/spfunc.f90(53): error #6404: This name does not have a type, and must have an explicit type. [ERF_EXT]

public :: erf_ext

• -----------^

compilation aborted for /marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/generated_src/spfunc.f90 (code 1)

make: *** [/marconi/home/userexternal/mhardman/git_gs2_trunk/gs2/objs/spfunc.o] Error 1

make: *** Waiting for unfinished jobs....

make: *** wait: No child processes. Stop.

[Joseph Parker]

Hi Michael, I don’t have access to Marconi at the moment, so I can’t be hands-on help, but I think it’s most likely that your branch and next have diverged in utils too. Could you try explicitly checking out utils’ next and trying with that?

cd exernal/utils
git checkout next
git pull

If that doesn’t work, the discussion here may be helpful: Ollie Beeke had problems compiling that got solved semi-recently: https://bitbucket.org/gyrokinetics/makefiles/issues/5/cannot-compile-on-marconi-with-2018

You could do a distclean, try checking out the most recent version of Makefiles (inside the Makefiles folder: git checkout master, git pull) and try again?

[Michael Hardman]

Hi Joseph,

I have tried your suggestions and unfortunately they do not fix the issue. Both utils and makefiles had detached heads, reattaching to next and master, respectively, did not fix the issue. It seems that Ollie's problem was fixed by explicitly defining HDF5 flags. Those are already present in my makefile.

I find it unlikely that I will fix this myself -- would you be willing to debug it with me via zoom at your convenience?

Alternatively can you suggest a command that will check out next directly from $ git clone, attaching the correct externals?

Thanks for your help!

[David Dickinson]

I’m not aware of anything significant changing between master and next in utils which would lead to this, so this is surprising. I’m not really familiar with the build_gs2 script but I think it should be equivalent to just running make gs2 . The only suggestion I’d have currently is to run make submodules after checking out next and before you run ./build_gs2 but I don’t really expect this to help.

[Peter Hill]

Hi Michael, which compiler (and its version) are you using? If make test_make works, please could you paste the output? Also, please could you attach generated_src/spfunc.f90? There’s a lot of #ifdefs in spfunc.fpp, so it would be useful to see exactly what it’s trying to compile

[Michael Hardman]

Thank you for your suggestions. Taking the version of next in the above (broken) state and running

‌

$ make -I Makefiles distclean
$ make -I Makefiles submodules
$ make -I Makefiles

succeeded in compiling. I am surprised that this worked given that the manual attempts to redirect utils to next failed. Given that I now have a version that compiles, what information can I provide you to help you understand why this happened?

I do not understand git well enough to understand the details of how the external repositories are handled. I daresay this will be the case for most users. If it is possible to automate the missing “make submodules” step that will surely save some anxiety for users down the line. To overcome this headache with my own development branch I made named branches of Makefiles and utils (on this bitbucket) which I maintain independently of the trunk versions. Whilst this is not automated, I do know the lines of code that I have to write in order to get the exact Makefiles and utils that are consistent with gs2 version.

‌

[David Dickinson]

I’m glad to hear that this worked, although similarly surprised that this did help.

I think there are at least two things we can do to make this easier

1. Add make submodules into the build process used by build_gs2
2. Add some clear documentation to the README which advises running make submodules whenever the user switches branch

I believe we could force make submodules to always be run when we build gs2 but I think this isn’t something we always want to do, for example if we’re testing changes to code in utils etc.

For us to understand what went wrong I think the information Peter suggested would be most useful for us.

‌

[Michael Hardman]

$ test -I Makefiles test_make > test_make.out.txt

[Michael Hardman]

generated_src/spfunc.f90

[Michael Hardman]

define STANDARD_SYSTEM_CONFIGURATION

module purge;\

module load env-skl;\

module load intel/pe-xe-2018--binary;\

module load intelmpi/2018--binary;\

module load zlib/1.2.8--gnu--6.1.0;\

module load szip/2.1--gnu--6.1.0;\

module load hdf5/1.10.4--intelmpi--2018--binary;\

module load netcdf/4.6.1--intelmpi--2018--binary;\

module load netcdff/4.4.4--intelmpi--2018--binary;\

module load fftw/3.3.7--intelmpi--2018--binary;\

module load profile/advanced;\

module load petsc/3.8.3_complex--intelmpi--2018--binary;\

module load profile/archive;\

module load slepc/3.8.2_complex--intelmpi--2018--binary;\

module load lapack;\

module load blas;\

unset PETSC_ARCH;\

echo Module configuration complete;\

export MAKEFLAGS='-j -IMakefiles';\

export TESTEXEC='mpirun -n 48';

endef

‌

[Michael Hardman]

mpiifort --version
ifort (IFORT) 18.0.5 20180823
Copyright (C) 1985-2018 Intel Corporation. All rights reserved.

[Peter Hill]

Thanks Michael, it looks like when using build_gs2, some preprocessor options are not getting defined correctly. I’m not sure why this would be different between master and next. If you have chance, please could you check if adding USE_F200X_INTRINSICS = on to Makefile.marconi makes it work?

[David Dickinson]

Has this issue been resolved?

‌

[David Dickinson]

8.1-RC appears to build out of the box on Marconi with the following modules loaded

Currently Loaded Modulefiles:
 1) profile/base               3) intelmpi/2018--binary                5) szip/2.1--gnu--6.1.0     7) hdf5/1.10.4--intelmpi--2018--binary    9) netcdff/4.4.4--intelmpi--2018--binary  
 2) intel/pe-xe-2018--binary   4) fftw/3.3.7--intelmpi--2018--binary   6) zlib/1.2.8--gnu--6.1.0   8) netcdf/4.6.1--intelmpi--2018--binary  10) mkl/2018--binary 

running the following sequence

git clone https://bitbucket.org/gyrokinetics/gs2
cd gs2
git checkout origin/8.1-RC
make submodules
make -j gs2