abinit 7.8.2: use of port groups

[cram5431@…]

I have seen that the ABINIT port was updated some time ago to the 7.8.2 version from the portfile of the version 7.4.3 (see [125582]). It is suggested that we could use the compiler and MPI port groups. I had already done this work in the ticket #42926 (which was closed prematurely) proposing an update to version 7.6.2. In addition this portfile seemed much more portable (in my tests).

Suggestion: merge #42926 in ABINIT 7.8.2 ?

[dstrubbe (David Strubbe)]

Ok, why don't you make a merged Portfile? What do you mean by calling the Portfile more "portable"?

[cram5431@…]

Portfile rev 1

[cram5431@…]

Portfile rev0 vs rev1

[cram5431@…]

Patch: correct a syntax error in openMP directives

[cram5431@…]

Hi, The "merged" portfile is enclosed

• It uses port groups and includes some improvements (fftw3...)
• It contains all your mods (bigDFT deletion, libXC 2.1.0 patch, ...).

I added a new patch needed for the "threads" variant.

By portable, I meant that we (ABINIT developers) have tested the Portfile in various situations on our "test farm" and this new version (with port groups) behave much better.

Does this one still fail under Mountain Lion ?

BTW: libxc port is missing a gcc49 variant (could help to compile abinit with gcc49); you are the maintainer of this port, right ? Could you add it or should I ?

[dstrubbe (David Strubbe)]

I have made libxc use the compilers portgroup and thus it now offers gcc49.

I am confused by some of the changes you made. Why the references to fftw-3-single? This port was not necessary before, and it does not seem to be used in the flags passed to configure. Also, you have rewritten quite a bit of functionality that is handled by the compilers and mpi portgroups, such as the logic about current_mpi and sequential, and the pre-fetch block.

Since you speak of testing on your test farm, can you try to make a working test phase for this Portfile? What sort of problem did you find before with the Portfile, that now it behaves much better?

I don't think there is a need to increase the revision: someone upgrading from a previously installed version would get exactly the same installation, wouldn't they?

[cram5431@…]

New version of the Portfile

[cram5431@…]

Hi,

Thanks for the libxc changes.

Also, I have suppressed the revision tag.

Yes, fftw-3-single port is now mandatory to compile ABINIT using fftw. It's actually used (see "-lfftwf" in the link line). In fact the GW section of ABINIT may use single precision. I have tried this: "sudo port uninstall fftw-3-single;sudo port install abinit" and it fails.

I know that my use of port groups is not standard, but I havent been able to get the desired behavior with a simple use of port groups:

• If a MPI variant is given, take it
• If not, check if there is a selected MPI; if yes, take it
• If there is no defaut MPI, take mpich
• If "sequential" or "-mpi(default)" variant, take no MPI (and have a flag to add "--enable-mpi=no" on the configure line)
• Mix of variant (f.i. +mpich+gcc48) correctly interpreted

Do you have any suggestion to fulfil the above conditions with a short use of MPI/compiler port groups?

I have added a working test phase (only basics tests).

[dstrubbe (David Strubbe)]

Does the build with +fftw3 actually work for you? It fails for me, even after making your changes to that variant, like this:

:info:build mpif90-mpich-mp -ffree-form -J/opt/local/var/macports/build/_Users_dstrubbe_Software_MacPorts_macports-trunk_dports_science_abinit/abinit/work/abinit-7.8.2/src/mods   -pipe -O3 -m64  -pipe -O3 -m64   -o kss2wfk kss2wfk-kss2wfk.o  ../../src/70_gw/lib70_gw.a ../../src/69_wfdesc/lib69_wfdesc.a ../../src/67_common/lib67_common.a ../../src/66_paw/lib66_paw.a ../../src/66_wfs/lib66_wfs.a ../../src/66_fock/lib66_fock.a ../../src/65_psp/lib65_psp.a ../../src/65_nonlocal/lib65_nonlocal.a ../../src/64_atompaw/lib64_atompaw.a ../../src/62_poisson/lib62_poisson.a ../../src/62_wvl_wfs/lib62_wvl_wfs.a ../../src/62_occeig/lib62_occeig.a ../../src/62_iowfdenpot/lib62_iowfdenpot.a ../../src/62_ctqmc/lib62_ctqmc.a ../../src/61_ionetcdf/lib61_ionetcdf.a ../../src/57_iovars/lib57_iovars.a ../../src/57_iopsp_parser/lib57_iopsp_parser.a ../../src/56_xc/lib56_xc.a ../../src/56_recipspace/lib56_recipspace.a ../../src/56_mixing/lib56_mixing.a ../../src/56_io_mpi/lib56_io_mpi.a ../../src/53_abiutil/lib53_abiutil.a ../../src/53_ffts/lib53_ffts.a ../../src/53_spacepar/lib53_spacepar.a  ../../src/52_fft_mpi_noabirule/lib52_fft_mpi_noabirule.a ../../src/51_manage_mpi/lib51_manage_mpi.a ../../src/49_gw_toolbox_oop/lib49_gw_toolbox_oop.a ../../src/47_xml/lib47_xml.a ../../src/45_geomoptim/lib45_geomoptim.a ../../src/44_abitypes_defs/lib44_abitypes_defs.a ../../src/43_wvl_wrappers/lib43_wvl_wrappers.a ../../src/43_ptgroups/lib43_ptgroups.a ../../src/42_parser/lib42_parser.a ../../src/42_nlstrain/lib42_nlstrain.a ../../src/42_libpaw/lib42_libpaw.a ../../src/41_xc_lowlevel/lib41_xc_lowlevel.a ../../src/41_geometry/lib41_geometry.a ../../src/32_util/lib32_util.a ../../src/28_numeric_noabirule/lib28_numeric_noabirule.a ../../src/27_toolbox_oop/lib27_toolbox_oop.a ../../src/21_psiesta_noabirule/lib21_psiesta_noabirule.a ../../src/18_timing/lib18_timing.a ../../src/16_hideleave/lib16_hideleave.a  ../../src/14_hidewrite/lib14_hidewrite.a ../../src/12_hide_mpi/lib12_hide_mpi.a ../../src/11_memory_mpi/lib11_memory_mpi.a ../../src/11_qespresso_ext/lib11_qespresso_ext.a ../../src/10_dumpinfo/lib10_dumpinfo.a ../../src/10_defs/lib10_defs.a  ../../src/01_linalg_ext/lib01_linalg_ext.a -letsf_io_utils -letsf_io -L/opt/local/lib -lnetcdf -lnetcdff -lfftw3 -lfftw3f -llapack  -lf77blas -lcblas -latlas  
:info:build Undefined symbols for architecture x86_64:
:info:build   "_sfftw_execute_dft_", referenced from:
:info:build       ___m_fftw3_MOD_fftw3_c2c_op_spc in lib52_fft_mpi_noabirule.a(m_fftw3.o)
:info:build       ___m_fftw3_MOD_fftw3_fftpad_spc in lib52_fft_mpi_noabirule.a(m_fftw3.o)
:info:build       ___m_fftw3_MOD_fftw3_c2c_ip_spc in lib52_fft_mpi_noabirule.a(m_fftw3.o)
:info:build       ___m_fftw3_MOD_fftw3_fftrisc_sp in lib52_fft_mpi_noabirule.a(m_fftw3.o)
:info:build   "_sfftw_plan_many_dft_", referenced from:
:info:build       ___m_fftw3_MOD_cplan_many_dft in lib52_fft_mpi_noabirule.a(m_fftw3.o)

and I can see that fftw-3-single does not provide symbols with this name; there is only

$ nm /opt/local/lib/libfftw3f.a | grep execute_dft
0000000000000000 T _fftwf_execute_dft_c2r
0000000000000048 S _fftwf_execute_dft_c2r.eh
0000000000000000 T _fftwf_execute_dft_r2c
0000000000000048 S _fftwf_execute_dft_r2c.eh
0000000000000000 T _fftwf_execute_dft
0000000000000050 S _fftwf_execute_dft.eh

[cram5431@…]

Yes, the fftw3 variant works perfectly for me. I work (today) with a newly fresh install of macports under Yosemite. But it worked perfectly a few days ago under Mavericks. I remember that I had link issues with fftw-3 a few months earlier; it was due to the use of an old revision of fftw-3.

My current settings:

fftw-3 @3.3.4_0+gfortran (active)
fftw-3-single @3.3.4_0+gfortran (active)

If I look for the "missing" symbol, I find it:

$ nm /opt/local/lib/libfftw3f.a | grep execute_dft
0000000000000000 T _fftwf_execute_dft_c2r
0000000000000048 S _fftwf_execute_dft_c2r.eh
0000000000000000 T _fftwf_execute_dft_r2c
0000000000000048 S _fftwf_execute_dft_r2c.eh
0000000000000000 T _fftwf_execute_dft
0000000000000050 S _fftwf_execute_dft.eh
00000000000006d0 T _sfftw_execute_dft_
0000000000003928 S _sfftw_execute_dft_.eh
0000000000001d60 T _sfftw_execute_dft__
0000000000004100 S _sfftw_execute_dft__.eh
0000000000001160 T _sfftw_execute_dft_c2r_
0000000000003c78 S _sfftw_execute_dft_c2r_.eh
00000000000027f0 T _sfftw_execute_dft_c2r__
0000000000004450 S _sfftw_execute_dft_c2r__.eh
0000000000000c10 T _sfftw_execute_dft_r2c_
0000000000003ad0 S _sfftw_execute_dft_r2c_.eh
00000000000022a0 T _sfftw_execute_dft_r2c__
00000000000042a8 S _sfftw_execute_dft_r2c__.eh

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

cram, is the Portfile/patches in ​ftp://ftp.abinit.org/MacPorts/7.10.4/ what you want committed?

[cram5431@…]

Yes, it should work; but it has not been tested under OSX 10.11.

[dstrubbe (David Strubbe)]

New Portfile using compilers and mpi portgroups properly, updating to 7.10.5.

• Adds support for gcc5 and gcc6, and understanding of +gfortran in dependencies; support for devel MPI ports
• Great simplification of enforcement of Fortran variants etc. in pre-fetch.
• Disabled +atompaw, since it (like the +bigdft variant) downloads some code itself in the build step.
• Fixed livecheck.
• Presence of Fortran variant for fftw-3 and fftw-3-single is checked.
• Apparently OpenMPI would not use MPI2 here before; I expect this is related to a bug in OpenMPI (or its packaging) that I found with octopus, and was fixed some time ago (#39826). Now MPI2 is enabled always.
• +g95 is usable now (though not with threads).
• Removed unnecessary statement "build.cmd make" which is the default.
• cxx compiler is not specified since it does not appear to be used in abinit.

cram, please check. Also anyone who is using El Capitán, I still am on Yosemite.

[dstrubbe (David Strubbe)]

This "syntax error" patch in OpenMP for BSE haydock above seems like it is just because lines were long and the appropriate flag was not passed for the Fortran compilers.

As far as I can tell, this current usage of the compilers and MPI portgroups does everything you had listed above as your goals.

[dstrubbe (David Strubbe)]

Committed r143272.