Fortran trouble.

Hi again,

I am having real trouble with the Fortran compiled models and model drivers.

On my Mac, I guess it is known not to work. I have a relatively old gfortran that can compile the KIM API itself, but crashes with an “illegal text relocation” when it tries to link a model. I do not dare to upgrade, as rumours say that then I can not even compile the API. I can live with not having these models on my mac, but any workaround would be welcome.

On the department Linux cluster the situation is worse. There, we run Centos Linux 6.6 and have gcc version 4.4.7 20120313. According to the KIM makefile, that is too old a gfortran compiler. Disabling the check, I can again compile the API, but compiling models fail with an "internal compiler error”, so I guess the check was there for a reason :slight_smile:

We also have Intel compilers on the cluster, version 13.0.1 20121010. If I set the KIM API to use Intel compilers, then I get a problem linking C++ files with the fortran compiler (is that even expected to work?). It happens already when compiling the API. The error is below.

As you can see, the first error is duplicate definition of main, that is the kind of problem one would expect when the fortran compiler tries to link a program already containing a main function. Is there some way to force the API to link with the C++ compiler (in that case probably some Fortran libraries need to be passed to the linker, I can probably find them if need be)?

In a virtual machine running Lubuntu 32 bits, everything just works fine.

Best regards

Jakob

Hi Jakob,

Thanks for your report and I'm sorry for the difficulties!

Unfortunately, many of the compile suites have been slow to implement and debug the full Fortran 2003 standard... So, we are left with a rather "jagged landscape" of systems on which the KIM API can be confidently used. Anyway, I'll try to provide help and information where I can.

First off. Take a look at the "OS Setup for the KIM API" pages

https://openkim.org/os-setup-for-kim-api/

that have recently become available on the openkim.org site. (In particular for the mac; see also below.)

More below:

Hi again,

I am having real trouble with the Fortran compiled models and model drivers.

On my Mac, I guess it is known not to work. I have a relatively old gfortran that can compile the KIM API itself, but crashes with an “illegal text relocation” when it tries to link a model. I do not dare to upgrade, as rumours say that then I can not even compile the API. I can live with not having these models on my mac, but any workaround would be welcome.

Yeah, the "illegal text relocation" issue is a bug in gfortran. It has been reported to the gfortran team:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888

The good news is that there has been recent effort to fix this bug, but it has not yet been resolved. The bad news is that the fix will appear in gfortran 4.9.0 (I'm not sure if this will be ported to anything older...)

Fortunately, there is a partial workaround. It requires compiling on the mac in 64bit mode and a set of special compile flags. See the INSTALL file notes and the Makefile.KIM_Config file for the mac at the bottom of this page:

https://openkim.org/os-setup-for-kim-api/mac/

On the department Linux cluster the situation is worse. There, we run Centos Linux 6.6 and have gcc version 4.4.7 20120313. According to the KIM makefile, that is too old a gfortran compiler. Disabling the check, I can again compile the API, but compiling models fail with an "internal compiler error”, so I guess the check was there for a reason :slight_smile:

Yes, the Fortran 2003 support in 4.4.X is incomplete and buggy. You might have luck using kim-api-v1.4.X (with cray pointers) and older version of the openkim.org Models if you absolutely need to run on this type of system...

We also have Intel compilers on the cluster, version 13.0.1 20121010. If I set the KIM API to use Intel compilers, then I get a problem linking C++ files with the fortran compiler (is that even expected to work?). It happens already when compiling the API. The error is below.

As you can see, the first error is duplicate definition of main, that is the kind of problem one would expect when the fortran compiler tries to link a program already containing a main function. Is there some way to force the API to link with the C++ compiler (in that case probably some Fortran libraries need to be passed to the linker, I can probably find them if need be)?

*******************************************************************************
** Building... src/utils **
*******************************************************************************
make --no-print-directory -C /home/niflheim/schiotz/development/kim-api/src/utils all
Creating... descriptor-file-match.o.
icpc -fPIC -I/home/niflheim/schiotz/development/kim-api/src -D KIM_ARCHTYPE=1 -D KIM_LINK_VALUE=2 -c -O3 -g -Wall -ansi -pedantic descriptor-file-match.cpp
Creating... kim-api-v1-descriptor-file-match.
ifort -o kim-api-v1-descriptor-file-match descriptor-file-match.o ../libkim-api-v1.6.3+INTEL.linux.64bit.dynamic-load.so
descriptor-file-match.o: In function `main':
/home/niflheim/schiotz/development/kim-api-v1.6.3/src/utils/descriptor-file-match.cpp:40: multiple definition of `main'
/home/opt/common/intel-compilers-2013.1.117/compiler/lib/intel64/for_main.o:/export/users/nbtester/efi2linux_nightly/branch-13_0/20121011_000000/libdev/frtl/src/libfor/for_main.c:(.text+0x0): first defined here
/home/opt/common/intel-compilers-2013.1.117/compiler/lib/intel64/for_main.o: In function `main':
/export/users/nbtester/efi2linux_nightly/branch-13_0/20121011_000000/libdev/frtl/src/libfor/for_main.c:(.text+0x38): undefined reference to `MAIN__'
make[1]: *** [kim-api-v1-descriptor-file-match] Error 1
make: *** [utils-all] Error 2

You've discovered a build system bug that is know and fixed, but not yet released. The attached patch file should show you how to correct this bug until it is officially released....

Cheers,

Ryan

intel-patch-for-kim-api-v1.6.3.patch (1.73 KB)

Dear Ryan,

Thank you very much for your kind reply. I will try your suggestions for the Mac during the weekend.

So far, I have tried the patch you sent for Linux using Intel compilers. The API then compiles. One model drivers and one stand-alone model fail to compile, it looks like it is the Intel compiler that finds a dubious or even illegal construction in the source code, but my Fortran stinks, so I cannot really check it. So far I will just remove them. The errors are below, in case you want to do something about it. I do not particularly need the Lennard-Jones driver, but the AIREBO one would be nice to have.

Everything else compile fine with the Intel compiler, and the majority of the resulting models load fine into Asap, and behaves well (the minority that fails fail on a 32 bit linux too).

Best regards

Jakob

The errors are below, in case you want to do something about it. I do not particularly need the Lennard-Jones driver, but the AIREBO one would be nice to have.

...

*******************************************************************************
** Building... Model Driver... Pair_Lennard_Jones_Shifted__MD_498634107543_001**
*******************************************************************************

Right, this is a simple bug that got overlooked due to (apparently) the less strict type checking of gfortran vs. Intel.

You can easily fix this by changing the call to "kim_api_setm_data()" on line 697 to "kim_api_setm_method()".

I've alerted the Model Driver maintainer (our friend Ellad) to this bug and we'll get a new revision (Pair_Lennard_Jones_Shifted__MD_498634107543_002) of the driver (and updated associated Models) posted at some point. Thanks!

*******************************************************************************
** Building... Model.......... model_ArCHHeXe_BOP_AIREBO__MO_154399806462_001**
*******************************************************************************

Yeah. This is "known" in many ways. The AIREBO Model Driver is build from Steve Stuart's code base which was originally FORTRAN 77 code. So, there are a lot of legacy code issues in making this work with modern compilers.

Fortunately, Steve and a number of other REBO, AIREBO, etc. developers participated in our most recent KCC (KIM Content Carnival) at the University of Maryland. They made significant progress on cleaning up and consolidating a Model Driver version that will support many variants of this family of Models. So, we expect to have an update to this driver "soon" too.

Everything else compile fine with the Intel compiler, and the majority of the resulting models load fine into Asap, and behaves well (the minority that fails fail on a 32 bit linux too).

Do you want to share which ones are failing? It might be good information to have. There may be some simple issues that can be cleaned up immediately.

Cheers,

Ryan

Do you want to share which ones are failing? It might be good information to have. There may be some simple issues that can be cleaned up immediately.

Of course. I will collect data on this next week, and submit it. I have convinced myself during the day that it is at least in some cases the model that is defective, not Asap. In other cases the jury is still out :slight_smile:

I tried out your trick with gcc48 on the Mac. Unfortunately, that requires building for 32 bit, and since Asap is loaded into Python, and Python is 64 bit then so is Asap, and so must the KIM Potentials be. Unfortunately. I guess I just have to make do without the fortran models on my mac - not really a big deal.

Best regards

Jakob

Ah, ... Right. Yep. For now there seems to be no (easy) solution.

Cheers,

Ryan

Dear Ryan,

I’m new to KIM and I’m trying to get it working on my Mac, 64 bit. As far as I can tell, this thread seems to be saying you cannot yet successfully have KIM 64 bit installed on a mac? And if that’s the case, and only 32 bit works, then it cannot work with LAMMPS or other 64 bit programs? Is that true?

Pardon my ignorance if I’m misunderstanding. I would greatly appreciate a clarification and maybe an update on the problem.

Thanks very much,
Blake

Hi Blake,

Currently, due to a bug in gfortran (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888) I do not know of a way to compile the KIM API in 64bit mode on the mac.

However, this does not mean it can't be used with LAMMPS or other programs. It just means that those programs must be compiled in 32bit mode. It is reasonably straight forward to compile LAMMPS in 32bit and link it with the KIM API on the mac (you will need to change the LAMMPS Makefile to use the same compiler as used with the KIM API. You can use the `kim-api-build-config --cxx` command, for example.)

Cheers,

Ryan