Hi Roland,

You mentioned that I could try linking in the BLAS library from ATLAS. But running "locate libatlas.dylib" doesn't return anything. However, I do get results for libblas.dylib and liblapack.dylib.

I should've been clear about this: I'm trying all these things on my laptop (OS X 10.10.5), not on a cluster. So it's easier to build different versions of things if necessary.

Both my OpenBLAS and BLAS+LAPACK (Einstein Toolkit version) compilations failed. For OpenBLAS, I get the error:

make[3]: *** [ScalarBoundary.c.o] Error 1
make[2]: *** [make.checked] Error 2
make[1]: *** [/Users/user/Cactus/configs/ET_OpenBLAS/lib/libthorn_Boundary.a] Error 2
make[1]: *** Waiting for unfinished jobs....
COMPILING configs/ET_OpenBLAS/bindings/build/ADMMass/cctk_ThornBindings.c
Creating /Users/user/Cactus/configs/ET_OpenBLAS/lib/libthorn_ADMMass.a
make: *** [ET_OpenBLAS] Error 2

For BLAS+LAPACK, I get:

------------------------------------------------------
There were 2 errors during execution of the CST
These must be corrected before compilation can proceed
------------------------------------------------------

------------------------------------------------------
Warnings were generated during execution of the CST
------------------------------------------------------

CST error 1:
  -> Configuration script for thorn BLAS returned exit code 2
     (no error message)

CST error 2:
  -> Configuration script for thorn LAPACK returned exit code 2
     (no error message)

------------------------------------------------------

make[1]: *** [/Users/user/Cactus/configs/ET_BLAS/config-data/make.thornlist] Error 1
make: *** [ET_BLAS] Error 2

Do you have any idea what could be going wrong?

Gwyneth


On Mon, Mar 13, 2017 at 2:39 PM, Roland Haas <rhaas@illinois.edu> wrote:
Hello Gwyneth,

> Thanks Roland! Adding -lgfortran to LIB_CXX eliminated most of the
> "undefined symbols" errors.
Good to hear.

> The ones that remain are related to liblapack.a and liblorene_g.a. For
> example:
>
> Undefined symbols for architecture x86_64:
>   "_ATL_cGetNB", referenced from:
>       _ATL_ilaenv in liblapack.a(ATL_ilaenv.o)
>
> I guess there's still some problem with the libraries.
>
> Apparently one needs the development version of Lapack for a
> successful Lorene compilation
> (http://www.lorene.obspm.fr/prerequisites.html), but I think I only
> have the December 2016 release. I'll see if adding the development
> version makes a difference.
This symbol (_ATL_cGetNB) seems to be from Atlas
(https://www.google.com/search?q=ATL_cGetNB) a self-tuning LAPACK
variant.

There seems to be a bug in some versions of LAPACK on redhat
systems that can cause this (at least this is what the google results
seem to indicate). In that case you may want to contact your local
cluster admin to ask about a corrected version of ATALAS/LAPACK.

A workaround may be to explicitly link in the blas library from atlas
usually called libatlas .

If you are using the system LAPACK, you can try and see if compiling
(one of the versions of) LAPACK included in the Einstein Toolkit lets
you continue.

There are two options: 1. use OpenBLAS which is a fast LAPACK+BLAS
library 2. use the reference LAPACK and BLAS wich will almost always
work but are much (factor or 10 or more) slower than optimized
versions. Speed of course only matters to you if you rely on BLAS for
speed (and not much in the ET does).

To compile OpenBLAS please do the following:

* make sure that ExternalLibraries/OpenBLAS appears in your thornlist
  (and is not commented out)
* make sure that ExternalLibraries/BLAS and ExternalLibraries/LAPACK do
  *not* appear in your thorn list
* set the options: OPENBLAS_DIR=BUILD in your option list and recompile

If compiling OpenBLAS fails then you can also try the reference
LAPACK+BLAS:

* make sure that ExternalLibraries/OpenBLAS does *not* appear in your
  thornlist
* make sure that ExternalLibraries/BLAS and ExternalLibraries/LAPACK do
  appear in your thorn list
* set the options: BLAS_DIR=BUILD and LAPACK_DIR=BUILD in your option
  list and recompile

Yours,
Roland


--
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
Disclaimer - University of Cape Town This e-mail is subject to UCT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. If this e-mail is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via csirt@uct.ac.za

_______________________________________________
Users mailing list
Users@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users