Modify

Opened 6 years ago

Last modified 10 months ago

#1170 new defect

ExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS inconsistently

Reported by: Roland Haas Owned by:
Priority: minor Milestone:
Component: EinsteinToolkit thorn Version:
Keywords: ExternalLibraries Cc:

Description

This is a companion ticket to #1006.

Different thorns (eg. MPI and HDF5 and LAPACK) handle XXX_DIR and XXX_INC_DIRS etc differently. MPI for example sets the include path to $MPI_DIR/include if MPI_INC_DIRS is not explicitly set and to MPI_INC_DIRS if it is set. HDF5 has no HDF5_INC_DIRS option and always sets the include path to HDF5_DIR/include. LAPACK has not INC_DIRS option and sets the linker path to LAPACK_DIR while the other two thorns set it to XXX_DIR/lib (unless overridden by MPI_LIB_DIRS in the case of MPI).

I would be good to present a uniform set of option for all these thorns.

Attachments (0)

Change History (7)

comment:1 Changed 6 years ago by Erik Schnetter

There are many different MPI implementations, and they all differ in the way in which they install their include and library directories. Hence thorn MPI needs to provide much flexibility.

There is only one HDF5 library, and it is installed in the same way on all systems we've encountered so far, hence no HDF5_INC_DIRS option has been necessary yet.

LAPACK and BLAS do not provide any include files, hence they do not need this option (it would be unused). We could add LAPACK_LIB_DIR, but then we don't need LAPACK_DIR any more, since it would exactly override it.

In short: the current setup makes very much sense for each library. We can unify this, which would be cleaner, but would likely not gain any new functionality from it.

comment:2 Changed 6 years ago by Roland Haas

Well yes. I have to admit that the cause for this was the C interface to LAPACK which I would have expected to provide an include file. However at least MKL has no likely named include file (which very much surprises me). Does the C interface to LAPACK provide no include file? I did not use this myself, just encountered it when helping out a local user (Luke Roberts) who wanted to use the LAPACK routines in MKL from C and had problems getting the compiler to find #include <mkl.h> (admittedly that is a mkl include file and not a LAPACK include file). I admit I never, ever used LAPACK before (C or Fortran interface).

I am not saying that the interface makes no sense for any library separately. I wanted to point out that something (namely the set of options and their meaning) that from a user perspective looks like a uniform interface that should act similar for all ExternalLibraries (since they all do the same thing: provide access to some externally developed library) does in fact take different options with different meanings for different libraries.

I fully agree that this is not pressing, but would like to take the opportunity of trying to unify this piece of the interface when we unify the handling of /usr . Whenever that happens :-)

comment:3 Changed 6 years ago by Erik Schnetter

LAPACK has no C interface. You can call it from C, but you have to think in Fortran 77 if you want to do so, which means e.g. living without prototypes.

I recommend using CLAPACK. This is available e.g. from netlib.org. The include file is called "clapack.h".

The performance of LAPACK/BLAS comes from BLAS, so you would link against CLAPACK first, and MKL (providing BLAS) later. You can easily build CLAPACK yourself; it is not very performance critical.

comment:4 Changed 6 years ago by Roland Haas

MKL seems to provide C prototypes for the (Fortran) LAPACK routines in its file mkl_lapack.h eg

void CBDSQR( char* uplo, MKL_INT* n, MKL_INT* ncvt, MKL_INT* nru, MKL_INT* ncc, float* d, float* e, MKL_Complex8* vt, MKL_INT* ldvt, MKL_Complex8* u, MKL_INT* ldu, MKL_Complex8* c, MKL_INT* ldc, float* rwork, MKL_INT* info );

which would already be useful. If there is no standard (or even pseudo-standard) for such a file to be present then it is of course no use :-(. The world is not a nice place if you want to use LAPACK from C it seems (CLAPACK of course excepted). I retract my premature claim that there was a C interface to LAPACK.

comment:5 Changed 6 years ago by Ian Hinder

Summary: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistentlyExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently

comment:6 Changed 6 years ago by Ian Hinder

Summary: ExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistentlyExternalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS inconsistently

comment:7 Changed 10 months ago by Roland Haas

This is all still the case. There have been some efforts to clean up the ExternalLibraries and a wiki page created for the efforts: https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external_libraries

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
Next status will be 'confirmed'.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.