search

MCSclimate / MCT

Model Coupling Tookit
Other
43 stars 18 forks source link

Update configure to autoconf 2.70 #66

Closed rljacob closed 3 years ago

rljacob commented 3 years ago

Update configure.ac and configure to autoconf 2.70

Remove referances and special handling for: EarthSimulator, BG/P, T3E, ifort 7 and earlier.

Also update version number to match MCT.

Fixes #67

rljacob commented 3 years ago

Unfortunately, this did not fix #67

rljacob commented 3 years ago

What version of ifx are you using?

andreapiacentini commented 3 years ago

What version of ifx are you using?

ifx --version
ifx (IFORT) 2021.1 Beta 20201113

icx --version
Intel(R) oneAPI DPC++ Compiler 2021.1 (2020.10.0.1113)

mpirun --version
Intel(R) MPI Library for Linux* OS, Version 2021.1 Build 20201112 (id: b9c9d2fc5)

With my last commit it works for me both for

./configure FC=ifx CC=icx

and

./configure MPIFC="mpifort -fc=ifx" FC=ifx CC=icx

Therefore I hope it fixes #67

rljacob commented 3 years ago

Yes that worked for me too! Thanks.

Can you put your mpi-serial changes in a PR directly to mpi-serial? https://github.com/MCSclimate/mpi-serial

andreapiacentini commented 3 years ago

Done on mpi-serial. Please, @rljacob can you check that it's ok for you? B.t.w., happy new year. Andrea

andreapiacentini commented 3 years ago

I tried to understand why updating autoconf to 2.70 fixed the ifx (intel oneAPI fortran) issue in mpi-serial standalone, but it did not work for MCT. The reason is that MCT redefines its own set of fortran detection macros in m4/fortran.m4 and this set has priority on the fortran.m4 provided by autoconf: that's why MCT was agnostic of the autoconf upgrade, at least for fortran. Is there any reason for MCT to keep a private copy of fortran.m4, drifting away from the official one when autoconf evolves? The git log of this file is very short. It was created with

commit c48a617f30afa53576cd3a7f0ccb2189100e5745
Author: Robert Jacob <jacob@mcs.anl.gov>
Date:   Fri Jan 13 02:33:03 2012 +0000

    Update build system to the one provided by Jim Edwards.  Among other things,
    it allows use of autoconf 2.60+.  MCT was stuck using autoconf 2.59

    This initial check in does not have all the defined variables of the previous version.
    However there is now native support in autoconf for Fortran compiler version checking
    and C-Fortran name mangling.

had some white space cleaning in 2017 and the home made fix for oneAPI a few days ago. At a first glance, comparing it with the 2.69 fortran.m4 I did not spot any specific treatment (there is only a small difference on the handling of the -list and -lnuma options but I don't know which compiler they could refer to). The 2.70 fortran.m4 introduced the correct handling of oneAPI ifx. @rljacob , can you find out why the custom fortran.m4 was needed and, in case, just give a try simply dropping the MCT m4/fortran.m4 (then you need to autoreconf -vif with the 2.70 autotools) ? On my side I have tested it on a Fedora 26 linux PC with intel18 (and intelmpi), oneAPI ifx (and its mpi), pgi17 with openmpi and pgi18 with mpich, then again with the same compilers but with --enable-mpiserial, and also on my MacBook (Mojave OS X) with gnu 10 compilers and openmpi 4.0.5. All ok here.

rljacob commented 3 years ago

Happy New Year, @andreapiacentini

MCT switched to autoconf before they had good Fortran support. The custom macros in m4/fortran.m4 are from that time. I can't recall if @jedwards4b wrote those for MCT or for another software package. I'll try removing them.

andreapiacentini commented 3 years ago

Happy n new year to @jedwards4b too! Indeed, we certainly need the customized m4/acx_mpi.m4 and m4/ax_fc_version.m4. About fortran.m4, if the treatment of the -list and -lnuma options is needed (cf. line 782), we should replace MCT/m4/fortran.m4 with the one from autotools 2.70 (natively dealing with oneAPI ifx) https://github.com/autotools-mirror/autoconf/blob/master/lib/autoconf/fortran.m4 and add the two options on top of it

rljacob commented 3 years ago

I tried removing m4/fortran.m4 and it still worked. I think we should do that and not maintain our own copy.

rljacob commented 3 years ago

Here's something I don't understand: If I remove m4/fortran.m4 and edit aclocal.m4 and then rerun autoconf, the resulting configure needs config.guess and config.sub. I have to add those for configure to run.

jayeshkrishna commented 3 years ago

If you use older versions of autotools (autoconf 2.68?) to generate configure you might not need the config.[guess|sub] scripts.

rljacob commented 3 years ago

The system fortran.m4 generates a configure that expects "config.sub" to be available. Its still worth it to not have our own fortran.m4.

rljacob commented 3 years ago

@andreapiacentini this is ready for final testing.

andreapiacentini commented 3 years ago

Validated once more on a Fedora 26 linux PC with intel18 (and intelmpi), oneAPI ifx (and its mpi), pgi17 with openmpi and pgi18 with mpich, then again with the same compilers but with --enable-mpiserial, and also on my MacBook (Mojave OS X) with gnu 10 compilers and openmpi 4.0.5. All ok here. About validating it in OASIS, I can ask Sophie & Co. They can, for the moment, add the local mct_mod.F90 and manually modify the Makefile while waiting for the mct_mod (whatever the name) introduction in mct. I'll write it in the other thread as well, but there are less than 10 oasis routines using mct_mod. Feel free to rename it accordingly to CIME requirements, if needed, and OASIS will easily follow.