opm-core does not build about opm-core HOT 17 CLOSED

I don't have that particular setup easily available. From my own testing I can only state that OPM-Core as of 643d54e builds fine on Ubuntu 10.04 and CentOS 5. Would you mind uploading your config.log (and, possibly, the output of config.status --config) to a gist for further inspection?

from opm-core.

By the way this appears, at least superficially, to be related to rolk's issue #55.

from opm-core.

In the interest of debugging this issue further, if you have the time and inclination, would you mind doing a bit of command line investigation?

What, if anything, do you have to do to have either (or preferably both) of the following programs link and produce the expected results (b = repmat(1/3, [2, 1]))?

In Fortran

Program TestLapack
   Implicit None

   Integer, Parameter :: k8 = Kind(1.0d0)
   Integer, Parameter :: n  = 2

   Integer        :: IPiv(n), Info, nrhs, lda, ldb, m, i
   Real (Kind=k8) :: A(n,n), b(n)

   External DGESV

   A(1,1) = 2.0_k8
   A(2,1) = 1.0_k8
   A(1,2) = 1.0_k8
   A(2,2) = 2.0_k8
   b      = 1.0_k8

   m    = n
   nrhs = 1
   lda  = n
   ldb  = n

   Call DGESV (m, nrhs, A, lda, IPiv, b, ldb, Info)

   If (Info == 0) Then
      Do i = 1,n
         Write (*,*) b(i)
      End Do
   Else
      Write (*,*) 'Info = ', Info
   End If

End Program TestLapack

and in C

#include <stdio.h>

void
dgesv_(const int *n, const int *nrhs, double *A, const int *lda,
       int *ipiv, double *b, const int *ldb, int *info);

int
main(void)
{
    int i, n, nrhs, lda, ldb, info;
    int ipiv[2];
    double A[2*2] = { 2.0, 1.0, 1.0, 2.0 }, b[2] = { 1.0, 1.0 };

    n = lda = ldb = 2;
    nrhs = 1;
    dgesv_(&n, &nrhs, A, &lda, ipiv, b, &ldb, &info);

    if (info == 0) {
        for (i = 0; i < 2; i++) {
            printf("%.12f\n", b[i]);
        }
    }
    else {
        printf("info = %d\n", info);
    }

    return 0;
}

from opm-core.

Time is certainly an issue, since it could be used to secure funding. Inclination is certainly there, building opm-upscaling on RH5 and latest Ubuntu LTS is an absolute must. Failing to do so already has large impact on everybody putting the code to good use. Right now we have build issues on both platforms and it is draining all my time. Both the fortran and the c code above failed to build on Ubuntu 12.04, I will not have time to figure out why until tomorrow. This is the output:

$ gcc testlapack.c
/tmp/cco1LzYv.o: In function main': testlapack.c:(.text+0xa3): undefined reference todgesv_'
collect2: ld returned 1 exit status

$ gfortran testlapack.f
testlapack.f:1.1:

Program TestLapack
1
Error: Non-numeric character in statement label at (1)
testlapack.f:1.1:

Program TestLapack
1
Error: Unclassifiable statement at (1)
testlapack.f:2.4:

Implicit None
1
Error: Non-numeric character in statement label at (1)
testlapack.f:2.4:

Implicit None
1

... and so on for another page.

Thanks for checking it out.

from opm-core.

Thanks.

Regarding the Fortran example: I forgot to specify that it's free-form Fortran 95 so the file needs a '.f90' extension. Still, let's focus on the C example. If I compile it on my work-station using the command

$ gcc testlapack.c -llapack -lblas

I get an executable that runs and produces the expected result:

$ ./a.out 
0.333333333333
0.333333333333

Moreover, ldd informs me that

$ ldd ./a.out |sed -E 's/^[[:space:]]+/ /'
 linux-vdso.so.1 =>  (0x00007fff1252e000)
 liblapack.so.3gf => /usr/lib/atlas/liblapack.so.3gf (0x00007f4e2c1a0000)
 libblas.so.3gf => /usr/lib/atlas/libblas.so.3gf (0x00007f4e2b805000)
 libc.so.6 => /lib/libc.so.6 (0x00007f4e2b481000)
 libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f4e2b194000)
 libm.so.6 => /lib/libm.so.6 (0x00007f4e2af11000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f4e2acf9000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f4e2cdc9000)

In other words, I get the ATLAS editions of LAPACK and BLAS linked in on my work-station (Ubuntu 10.04.4 LTS). I have the liblapack3gf package installed.

If I were to do the linking more explicitly, I'd say something like

$ gcc testlapack.c -L/usr/lib/atlas -Wl,-rpath -Wl,/usr/lib/atlas \
  -l:liblapack.so.3gf -l:libblas.so.3gf

and I would still get essentially the same ldd output as before

$ ldd ./a.out |sed -E 's/^[[:space:]]+/ /'
 linux-vdso.so.1 =>  (0x00007fff68ae8000)
 liblapack.so.3gf => /usr/lib/atlas/liblapack.so.3gf (0x00007f3128d6b000)
 libblas.so.3gf => /usr/lib/atlas/libblas.so.3gf (0x00007f31283d0000)
 libc.so.6 => /lib/libc.so.6 (0x00007f312802c000)
 libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f3127d3f000)
 libm.so.6 => /lib/libm.so.6 (0x00007f3127abc000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f31278a4000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f3129974000)

If neither of these commands work in your case, I think I will need to see the config.log file from OPM-Core's build directory. You can send it to me off-line if you so desire.

from opm-core.

Linking with lapack and blas did the trick. I got the following:
From C
$ ./a.out
0.333333333333
0.333333333333
From Fortran 90:
$ ./a.out
0.33333333333333337
0.33333333333333331

This is ldd from the fortran version:
$ ldd a.out
linux-vdso.so.1 => (0x00007fff1fdff000)
liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007f8575c42000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f857592b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f857556b000)
libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f8575002000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8574dec000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8574bce000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f85748d4000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f857469e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f857687c000)

from opm-core.

Good.

This means that there is at least one working LAPACK/BLAS pair on your system. Unfortunately, this also means that we will have to dig a little deeper to establish what is actually happening when building OPM-Core.

Earlier you noted that commit 643d54e leads to build failure. This is speculation: Is there possibly some adverse interaction with SuperLU going on? Did you use git bisect to find that particular commit? If so, do you have SuperLU on your system? If so, is that (SuperLU) library found during OPM-Core's ./configure process?

To answer these questions I think I will need the config.log output as well as the actual configure script (all 900k of it). Would you mind putting these files together in a '.tar.gz' and sending it to me off-line?

from opm-core.

Just an update: Roland Kaufmann (@rolk) came to visit our office today and we now think we know what's happening. Apparently, there is some kind of incompatibility between Ubuntu 12.04's libsuperlu-dev's BLAS requirements (which is satisfied by the libblas-dev package) and the BLAS features provided by 12.04's atlas package (libatlas-base-dev or some such). Briefly, the former cannot be linked into a package that already uses the latter.

We are working on a fix or work-around.

from opm-core.

@alfbr @bska
The way around this which I had best success with was linking SuperLU statically, i.e.

./configure --with-superlu-lib

or

dunecontrol --configure-opts='--with-superlu-lib' --module=opm-core autogen : configure

You may have to add the changesets in #62 (before you run configure) to make it compile.

Note that this is a (somewhat unsatisfying) work-around: However, if I tried to force it to use the reference BLAS all over, I got strange linker errors (which I haven't figured out yet).

from opm-core.

It somehow seems that adding the changesets above enable you to build with the reference BLAS by default (linking dynamically to SuperLU), although I am not at the moment quite able to explain why only these libraries pulled in ATLAS and not the main library (it may also be that I have now configured my machine into a non-replicable state), so please test if you are able to make a build after pulling the changesets but before trying to use the static libraries.

from opm-core.

Can someone provide a Makefile and config.log? I would like to see what is actually found.

from opm-core.

@alfbr This pretty much looks like a mixup of your system. The default for lapack seems to be atlas and the default for blas is not. You might want to resolve this (if you have sudo rights) by:

sudo update-alternatives --config libblas.so.´´´
and selecting compatible versions.

On my system this was even more broken. Even selecting new alternatives did not change the symbolic links. I had to rm the links manually before running the above command.

If you do not have root rights you will have to provide the libs to configure using
```configure --with-blas=/usr/lib/atlas-base/atlas/libblas.so.3 --with-lapack=/usr/lib/atlas-base/atlas/liblapack.so.3´´´

from opm-core.

On my system the superlu dependencies then looks like this:

        linux-vdso.so.1 =>  (0x00007fff055ff000)
        libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f81c835a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f81c80d8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f81c7d50000)
        libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f81c7a3a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f81c7824000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f81c7607000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f81c8c61000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f81c73d2000)
mblatt@legolas:/tmp/opm-core$ ls -l /usr/lib/libblas.so.3gf
lrwxrwxrwx 1 root root 32 Aug  9 09:11 /usr/lib/libblas.so.3gf -> /etc/alternatives/libblas.so.3gf
mblatt@legolas:/tmp/opm-core$ ls -l /etc/alternatives/libblas.so.3gf
lrwxrwxrwx 1 root root 38 Okt 11 12:21 /etc/alternatives/libblas.so.3gf -> /usr/lib/atlas-base/atlas/libblas.so.3
mblatt@legolas:/tmp/opm-core$ ´´´

from opm-core.

Does merging @rolk's changes in request #62 fix (or at least work around) this issue?

from opm-core.

The issue was discovered on a fresh Ubuntu 12.04 install with a student here. He should be by tomorrow with the computer. I can of course test on one of my own Ubuntu boxes too. Thanks for the efforts, I will report back as soon as possible.

from opm-core.

Tested on a 12.04 box at home, it now builds opm-core. Opm-porsol fails, but I need to check more on that tomorrow, will return with an update then.

from opm-core.

Ok, I tested on three different Ubuntu 12.04 boxes with different issues on all three. I suspected all three were related to various earlier build efforts, so I made a virtual KVM image of vanilla Ubuntu 12.04.1 server edition. The build went through just fine on it today. Huge thanks to all of you who helped out, it is fantastic to see how the community grows and how the aggregated abilities grows with it.

from opm-core.