search

SimVascular / svSolver

Separate repository for svSolver
14 stars 23 forks source link

BuildWithMake needs 'make' twice to make svsolver executable (CentOS) #49

Open aekaanshv opened 5 years ago

aekaanshv commented 5 years ago

I am building svSolver on the Stampede cluster which uses centOS. Following the BuildWithMake instructions (upto and including 6. in the README-build-linux.txt file) gives first creates only three executables in the Bin/ directory:

svpost.exe svpost-gcc-gfortran.exe svpre-gcc-gfortran.exe

I found that I needed to run make one extra time to actually build the svSolver executables:

svsolver-gcc-gfortran-mpich.exe svsolver-mpich.exe

ktbolt commented 5 years ago

@aekaanshv Why are you using make? Does CMake not work?

aekaanshv commented 5 years ago

I've mostly used BuildWithMake for svSolver on the clusters.

I did try CMake as well on Stampede, but I run into the following error out of SimVascularMacros.cmake:584 (message) :

The operating system does not have any available per-built binaries. See the build documentation to build your own. Call Stack (most recent call first): CMakeExternals/SvExtOptions.cmake:66 (sv_externals_add_new_external) CMakeLists.txt:94 (include)

My best guess is that it's not able to detect the version/details of Centos on Stampede- maybe something to do with LSB?

ktbolt commented 5 years ago

The BuildWithMake hard codes the externals to centos_6/gnu-4.4/2016.09.18. CMake tries to figure out which externals to download using lsb_release.

What does running lsb_release return?

aekaanshv commented 5 years ago

lsb_release returns:

LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch

ktbolt commented 5 years ago

sorry, make that lsb_release -d

vvedula22 commented 5 years ago

I have seen some of these issues earlier. I will try with CMake tomorrow on both Stampede2 and Sherlock and keep you updated.

aekaanshv commented 5 years ago

@ktbolt : For what its' worth, I get:

$ lsb_release -d Description: CentOS Linux release 7.6.1810 (Core)

vvedula22 commented 5 years ago

I tried compiling using CMake on both Sherlock and Stampede2. LSB version is not an issue but I face another error related to externals:

CMake Error at /work/02716/vedula/sharedSW/svSolver/src/Code/CMake/SimVascularMacros.cmake:584 (message): The operating system does not have any available per-built binaries. See the build documentation to build your own. Call Stack (most recent call first): CMakeExternals/SvExtOptions.cmake:66 (sv_externals_add_new_external) CMakeLists.txt:94 (include)

aekaanshv commented 5 years ago

@vvedula22 - That's the same error I got. I was assuming it had to do with SV not finding the externals. Quoting @ktbolt :

The BuildWithMake hard codes the externals to centos_6/gnu-4.4/2016.09.18. CMake tries to figure out which externals to download using lsb_release.

ktbolt commented 5 years ago

I am wondering if CMake is the best choice for building the solvers.

svSolver has about 3000 lines of CMake code, not really very automated, and it has trouble finding a Fortran compiler.

aekaanshv commented 5 years ago

I'm wondering if its' because Stampede2 uses CentOS 7.6 instead of CentOS 6?

ktbolt commented 5 years ago

That's the problem I guess, we don't have externals for CentOS 7.

aekaanshv commented 5 years ago

CentOS 6 externals seem to work fine for me when I use the BuildWithMake pathway. Maybe it's ok to route CMake to the same externals when it wants CentOS 7 ?

vvedula22 commented 5 years ago

I am little unclear how this thing works. Are the externals explicitly provided in SimVascular which the BuildWithMake is hard coded to use if the System's externals are not available? If so, following Aekaansh's suggestion can we pass the path to externals as command line arguments to cmake?

On Tue, Sep 17, 2019, 7:56 PM Aekaansh Verma notifications@github.com wrote:

CentOS 6 externals seem to work fine for me when I use the BuildWithMake pathway. Maybe it's ok to route CMake to the same externals when it wants CentOS 7 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SimVascular/svSolver/issues/49?email_source=notifications&email_token=AEFM5X2SGDFUHNWLOODHAFTQKGKFDA5CNFSM4IXIXIX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66UFIY#issuecomment-532497059, or mute the thread https://github.com/notifications/unsubscribe-auth/AEFM5X3MGPZTNNWNW4ONSHDQKGKFDANCNFSM4IXIXIXQ .

ktbolt commented 5 years ago

The externals are stored on http://simvascular.stanford.edu/downloads/public/svsolver/externals/. There are downloads for specific OS and complier versions, e.g. http://simvascular.stanford.edu/downloads/public/svsolver/externals/linux/centos_6/gnu-4.4/2016.09.18/.

BuildWithMake hard codes this directory.

In theory you could set the externals version (you can do this in SV) but there is no single version CMake variable, the external version to download is created from several CMake varaiables: OS, compiler, etc. that is determined by CMake.

Maybe if we passed in those variables we could set the external version or set the final variable and check to see if it is set or add externals for CentOS 7.