Hi Roland and Frank,
Thanks for all the comments! I'm looking forward to trying this out.
Once I manage to compile Lorene and produce some data, I'll have a go at importing the data into the toolkit. There's probably going to be a learning curve, but I don't mind spending some time on this. If I manage to get it working, I'll add to the wiki.
Gwyneth
On Tue, Mar 7, 2017 at 4:41 PM, Roland Haas rhaas@illinois.edu wrote:
Hello Gwyneth,
Lorene contains an executable for mixed binaries in Codes/bin_bh_ns which seems to be the one used to produce the public data (I guess). I couldn't quite get it to work right now (tried for 15 minutes so not very long) and could not quite figure out what it wants for its initial data file argument (the output is s French but most comments in the file are in English).
I take it back. This works for me:
- create a local_settings file eg based on Local_settings_examples/local_settings_linux_gcc-4_x86-64
- compile lorene making sure that all libraries are present so that Lib/liblorenef77.a is build (needs pgplo)
- make lorene
- cd Codes/Bin_ns_bh
- make coal_ns_bh init_ns_bh lit_bin_ns_bh
- ./init_ns_bh par_init.d
- ./coal_ns_bh par_coal.d statiques.dat
you could try this with the example file in Lorene itself or the files in the public bhns data first (http://www.lorene.obspm.fr/data/binBHNS.html)
If you make this work and would report back that would be great. You could for example add this to the ET wiki at https://docs.einsteintoolkit.org/et-docs/Main_Page after creating a wiki account.
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://keys.gnupg.net.
On Tue, Mar 7, 2017 at 4:41 PM, Roland Haas rhaas@illinois.edu wrote:
Hello Gwyneth,
Lorene contains an executable for mixed binaries in Codes/bin_bh_ns which seems to be the one used to produce the public data (I guess). I couldn't quite get it to work right now (tried for 15 minutes so not very long) and could not quite figure out what it wants for its initial data file argument (the output is s French but most comments in the file are in English).
I take it back. This works for me:
- create a local_settings file eg based on Local_settings_examples/local_settings_linux_gcc-4_x86-64
- compile lorene making sure that all libraries are present so that Lib/liblorenef77.a is build (needs pgplo)
- make lorene
- cd Codes/Bin_ns_bh
- make coal_ns_bh init_ns_bh lit_bin_ns_bh
- ./init_ns_bh par_init.d
- ./coal_ns_bh par_coal.d statiques.dat
you could try this with the example file in Lorene itself or the files in the public bhns data first (http://www.lorene.obspm.fr/data/binBHNS.html)
If you make this work and would report back that would be great. You could for example add this to the ET wiki at https://docs.einsteintoolkit.org/et-docs/Main_Page after creating a wiki account.
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://keys.gnupg.net.
Hello Gwyneth, Frank, all,
Thanks for all the comments! I'm looking forward to trying this out.
Once I manage to compile Lorene and produce some data, I'll have a go at importing the data into the toolkit. There's probably going to be a learning curve, but I don't mind spending some time on this. If I manage to get it working, I'll add to the wiki.
I was pointed out to me by a kind person that there is indeed a simpler way to get at "some" bhns initial data. You can use a combination of the TOVSolver and TwoPunctures thorns to obtain such a one as shown in the test parfile arrangements/EinsteinInitialData/TwoPunctures/test/bhns_eval.par
You will probably have to run with quite high values for npoints_A and npoints_B (easily >60) to obtain any reasonable value for the constraints.
This will not generate great (or even good) initial data since at the very least the star will be out of hydrostatic equilibrium so will start to oscillate noticeably when the simulation stars. Second the example parfile has the star at rest. You can give it a velocity via TOVSolver's TOV_Velocity_x[0] etc parameters though then you will not even strictly satisfy the initial data constraints for the metric since TOVSolver does not take the fluid into account when solving for the momentum constraint. Finally there is no help provided to obtain quasicircular orbits at all, so you are stuck with eg starting from the Newtonian velocity and see what happens.
As said, not great initial data for BHNS but something that you could at least play with while learning how to use LORENE or getting access to better data produced by other codes.
Yours, Roland
Thanks Roland! This is going to be useful; I didn't know about that parameter file.
I've been trying to compile Lorene, but am getting errors like:
Undefined symbols for architecture x86_64: __gfortran_os_error", referenced from: _poiss2d_ in liblorenef77_g.a(poisson2d.o) _poiss2di_ in liblorenef77_g.a(poisson2di.o)
The initial "make" works fine. The errors only appear when I "make test" or "make coal_ns_bh init_ns_bh lit_bin_ns_bh" in the Codes/Bin_ns_bh directory. Did you by any chance run into something like this?
I'm using the MacPorts universal version of gcc 6.3.0 and am compiling with g++ and gfortran. I've tried setting -m64 and -m32, but neither works. I probably need to change something in my local settings file, but so far I haven't been able to figure out what.
Gwyneth
On Thu, Mar 9, 2017 at 6:58 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Gwyneth, Frank, all,
Thanks for all the comments! I'm looking forward to trying this out.
Once I manage to compile Lorene and produce some data, I'll have a go at importing the data into the toolkit. There's probably going to be a learning curve, but I don't mind spending some time on this. If I manage
to
get it working, I'll add to the wiki.
I was pointed out to me by a kind person that there is indeed a simpler way to get at "some" bhns initial data. You can use a combination of the TOVSolver and TwoPunctures thorns to obtain such a one as shown in the test parfile arrangements/EinsteinInitialData/TwoPunctures/test/bhns_eval.par
You will probably have to run with quite high values for npoints_A and npoints_B (easily >60) to obtain any reasonable value for the constraints.
This will not generate great (or even good) initial data since at the very least the star will be out of hydrostatic equilibrium so will start to oscillate noticeably when the simulation stars. Second the example parfile has the star at rest. You can give it a velocity via TOVSolver's TOV_Velocity_x[0] etc parameters though then you will not even strictly satisfy the initial data constraints for the metric since TOVSolver does not take the fluid into account when solving for the momentum constraint. Finally there is no help provided to obtain quasicircular orbits at all, so you are stuck with eg starting from the Newtonian velocity and see what happens.
As said, not great initial data for BHNS but something that you could at least play with while learning how to use LORENE or getting access to better data produced by other codes.
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://keys.gnupg.net.
Hello Gwyneth,
Thanks Roland! This is going to be useful; I didn't know about that parameter file.
I've been trying to compile Lorene, but am getting errors like:
Undefined symbols for architecture x86_64: __gfortran_os_error", referenced from: _poiss2d_ in liblorenef77_g.a(poisson2d.o) _poiss2di_ in liblorenef77_g.a(poisson2di.o)
The initial "make" works fine. The errors only appear when I "make test" or "make coal_ns_bh init_ns_bh lit_bin_ns_bh" in the Codes/Bin_ns_bh directory. Did you by any chance run into something like this?
I'm using the MacPorts universal version of gcc 6.3.0 and am compiling with g++ and gfortran. I've tried setting -m64 and -m32, but neither works. I probably need to change something in my local settings file, but so far I haven't been able to figure out what.
As a guess: you may have to add -lgfotran to your LIB_CXX settings in local_settings, ie:
ifeq ($(FFT_DIR),FFTW3) LIB_CXX = -lfftw3 -lgfortran -lstdc++ -lm else LIB_CXX = -lgfortran -lstdc++ -lm endif
Yours, Roland
Thanks Roland! Adding -lgfortran to LIB_CXX eliminated most of the "undefined symbols" errors.
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.
Gwyneth
On Sun, Mar 12, 2017 at 8:30 PM, Roland Haas <roland.haas@physics.gatech.edu
wrote:
Hello Gwyneth,
Thanks Roland! This is going to be useful; I didn't know about that parameter file.
I've been trying to compile Lorene, but am getting errors like:
Undefined symbols for architecture x86_64: __gfortran_os_error", referenced from: _poiss2d_ in liblorenef77_g.a(poisson2d.o) _poiss2di_ in liblorenef77_g.a(poisson2di.o)
The initial "make" works fine. The errors only appear when I "make test"
or
"make coal_ns_bh init_ns_bh lit_bin_ns_bh" in the Codes/Bin_ns_bh directory. Did you by any chance run into something like this?
I'm using the MacPorts universal version of gcc 6.3.0 and am compiling
with
g++ and gfortran. I've tried setting -m64 and -m32, but neither works. I probably need to change something in my local settings file, but so far I haven't been able to figure out what.
As a guess: you may have to add -lgfotran to your LIB_CXX settings in local_settings, ie:
ifeq ($(FFT_DIR),FFTW3) LIB_CXX = -lfftw3 -lgfortran -lstdc++ -lm else LIB_CXX = -lgfortran -lstdc++ -lm endif
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
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
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
I've realized that I get the OpenBLAS error regardless of whether or not I set OPENBLAS_DIR=BUILD. So I think there's something wrong with my optionlist.
The optionlist worked previously, but it's been a while since I tried compiling the Einstein Toolkit on my laptop. In between the successful compiles and now, I installed gcc-6 via MacPorts (which is currently my default version). Perhaps this could be causing trouble.
My laptop is a bit of a mess: I'm using both MacPorts and Homebrew, have multiple versions of things, and am generally unsure about what is linked to what. I'm actually tempted to do a factory reset, choose a single package manager (and stick to it), and do fresh checkouts of everything I need.
On Tue, Mar 14, 2017 at 10:41 AM, Gwyneth Allwright allgwy001@myuct.ac.za wrote:
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
Hello Gwyneth,
hmm, so you are on a Mac and have macports installed. I don't have such a laptop (I only have homebrew installed) but looking at the file repos/simfactory2/mdb/optionlists/osx-macports.cfg then it does contain LAPACK_DIR and LAPACK_LIBS line. Note that LORENE (for the coal executable) does not use Cactus' option list but its own local_settings file (just untar the tarfile in ExternalLibraries/LORENE/dist manually and compile in there).
So you should be able to use
-Wl,-framework,Accelerate
in LDFLAGS (or similar) in local_settings to get Lorene to work.
Similarly for Cactus if you need LAPACK.
For BLAS and LAPACK: please try and compile like so:
make sim-realclean VERBOSE=yes simfactory/bin/sim build sim 2>&1 | tee make.log
and attach the full output of this (in make.log) as well as ideally the content of configs/sim/config-info and configs/sim/bindings/Configuration/Capabilities/make.{BLAS,LAPACK}.{defn,deps}
I've realized that I get the OpenBLAS error regardless of whether or not I set OPENBLAS_DIR=BUILD. So I think there's something wrong with my optionlist.
Just to be sure: you have made sure that the new option list is actually being used? You may have to do something like this:
simfactory/bin/sim build --reconfig --optionlist path-to-your-option-list.cfg
Yours, Roland
On Tue, Mar 14, 2017 at 08:51:15AM -0500, Roland Haas wrote:
Note that LORENE (for the coal executable) does not use Cactus' option list but its own local_settings file (just untar the tarfile in ExternalLibraries/LORENE/dist manually and compile in there).
When you compile LORENE, Cactus does create a local_settings file for you, and should include the necessary paths. If that is not quite working, it is a bug. I do see in there, e.g.,:
LIB_LAPACK = ${LAPACK_LIBS} ${BLAS_LIBS}
and LDFLAGS are added in several places.
Frank
Hi Roland, Frank, Ian,
Thanks for all your help, and sorry for taking so long to respond. In the end I decided to wipe everything and start over. It was a good opportunity to clean up my hard drive and upgrade to the latest macOS!
I'm now using Homebrew only. Both the Einstein Toolkit and Lorene compile without hiccups. Roland, I was able to go through all the steps for getting the initial data that you described.
The only issue I'm experiencing is with running my Einstein Toolkit compilations using the mpirun command.
I tried:
mpirun -np 2 <exe file> <parameter file>
and got:
[Gwyneths-MacBook-Air.local:16392] [[60663,0],0] ORTE_ERROR_LOG: Bad parameter in file orted/pmix/pmix_server.c at line 262 [Gwyneths-MacBook-Air.local:16392] [[60663,0],0] ORTE_ERROR_LOG: Bad parameter in file ess_hnp_module.c at line 666 -------------------------------------------------------------------------- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer):
pmix server init failed --> Returned value Bad parameter (-5) instead of ORTE_SUCCESS --------------------------------------------------------------------------
I installed Open MPI via Homebrew and used osx-homebrew.cfg for my compilation. It has MPI_DIR = /usr/local.
Incidentally: I modified arrangements/Carpet/CarpetLib/src/defs.hh as Ian suggested, and got that bboxset2 is used on my laptop (for this compilation, at least). (I'll reply properly to my other thread about the potential Carpet bug soon -- I'd like to check whether or not the error appears on my laptop for the new compilation.)
Gwyneth
On Tue, Mar 14, 2017 at 3:51 PM, Roland Haas rhaas@illinois.edu wrote:
Hello Gwyneth,
hmm, so you are on a Mac and have macports installed. I don't have such a laptop (I only have homebrew installed) but looking at the file repos/simfactory2/mdb/optionlists/osx-macports.cfg then it does contain LAPACK_DIR and LAPACK_LIBS line. Note that LORENE (for the coal executable) does not use Cactus' option list but its own local_settings file (just untar the tarfile in ExternalLibraries/LORENE/dist manually and compile in there).
So you should be able to use
-Wl,-framework,Accelerate
in LDFLAGS (or similar) in local_settings to get Lorene to work.
Similarly for Cactus if you need LAPACK.
For BLAS and LAPACK: please try and compile like so:
make sim-realclean VERBOSE=yes simfactory/bin/sim build sim 2>&1 | tee make.log
and attach the full output of this (in make.log) as well as ideally the content of configs/sim/config-info and configs/sim/bindings/Configuration/Capabilities/make.{BLAS,L APACK}.{defn,deps}
I've realized that I get the OpenBLAS error regardless of whether or not
I
set OPENBLAS_DIR=BUILD. So I think there's something wrong with my optionlist.
Just to be sure: you have made sure that the new option list is actually being used? You may have to do something like this:
simfactory/bin/sim build --reconfig --optionlist path-to-your-option-list.cfg
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 .
On 14 Mar 2017, at 10:39, Gwyneth Allwright allgwy001@myuct.ac.za wrote:
I've realized that I get the OpenBLAS error regardless of whether or not I set OPENBLAS_DIR=BUILD. So I think there's something wrong with my optionlist.
The optionlist worked previously, but it's been a while since I tried compiling the Einstein Toolkit on my laptop. In between the successful compiles and now, I installed gcc-6 via MacPorts (which is currently my default version). Perhaps this could be causing trouble.
My laptop is a bit of a mess: I'm using both MacPorts and Homebrew, have multiple versions of things, and am generally unsure about what is linked to what. I'm actually tempted to do a factory reset, choose a single package manager (and stick to it), and do fresh checkouts of everything I need.
Hi,
You probably don't need to do a complete reinstall. MacPorts installs into /opt/local only, so if you wipe that (or move it), and then reinstall MacPorts, you are guaranteed not to have the old versions used. It's possible you have other things installed in /opt/local, but I don't think it's very common. I believe homebrew goes into /usr/local, but it's more common to find other packages which like to install themselves there, so be careful with removing it.
On Mon, Mar 13, 2017 at 01:51:40PM +0200, Gwyneth Allwright wrote:
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.
Hi,
A note on terminology here: what Lorene means with "development version" is the package that includes the header files, not a version still in development. If you were to install Lapack by hand you usually get both, but distributions often split them because the majority of users only ever needs the library itself. You only need the header files if you compile against the library, not if you only run something that uses it.
Thus, a release from last year is perfectly fine. Depending on what distribution you use, "development" packages (meant for development using them) are sometimes called package-dev or package-devel.
Frank
users@lists.einsteintoolkit.org
-
Frank Loeffler -
Gwyneth Allwright -
Ian Hinder -
Roland Haas -
Roland Haas