Re: [daetools-users] coolprop required?
Object-oriented equation-based modelling and optimisation software
Brought to you by:
ciroki
Menu
▾
▴
Re: [daetools-users] coolprop required?
|
From: Dragan N. <dra...@gm...> - 2017-06-27 14:20:31
|
Hello,
You are always welcome.
Yes, since it can't find the library that surely exists, something is
wrong: either the path to the library or the library name. In this case
it was the library path..
Dragan
On 27/06/17 15:45, Raymond Smith wrote:
> Oh, subtle. Yes, sure enough, that line in CMakeCache.txt has this
> line for me:
> CMAKE_INSTALL_LIBDIR:PATH=lib64
>
> And when I add that line to compile_libraries.sh and recompile with
> those commands, the compile/build runs fine, and I can run
> simulations. Very nice.
>
> Thanks!
> Ray
>
> On Tue, Jun 27, 2017 at 1:36 AM, Dragan Nikolic <dra...@gm...
> <mailto:dra...@gm...>> wrote:
>
> Hi,
>
> No problem. I found what is the error. This is from the build output:
>
> ...
> [100%] Linking C static library libsuperlu.a
> [100%] Built target superlu
> Install the project...
> -- Install configuration: "RELEASE"
> -- Installing:
> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/superlu/build/./lib64/libsuperlu.a
> ...
>
> It seems that in your system superlu automake chose to install the
> compiled libsuperlu.a library to build/lib64 and not build/lib
> folder. That's why the daetools build script cannot find it. I
> haven't seen that before. SuperLU developers switched to cmake so
> did I, too. I need to find why and to fix it in a generic way. I
> have Arch Linux virtual machine but it does not want to upgrade to
> the latest (honestly, it is 2 years old installation). In the
> meantime please go to the trunk/superlu/build folder and find
> CMAKE_INSTALL_LIBDIR in CMakeCache.txt (line 107 in my file):
>
> ...
> //No help, variable specified on the command line.
> CMAKE_INSTALL_LIBDIR:PATH=lib
> ...
>
> In my systems it is lib. Perhaps it is lib64 in your installation?
> Before I commit the update, let's test first. If it is lib64 try
> adding -DCMAKE_INSTALL_LIBDIR:PATH=lib to compile_libraries.sh
> line 1242:
>
> cmake \
> -G"${CMAKE_GENERATOR}" \
> -DCMAKE_BUILD_TYPE:STRING=RELEASE \
> -DBUILD_SHARED_LIBS:BOOL=OFF \
> -DCMAKE_INSTALL_PREFIX:PATH=. \
> *-DCMAKE_INSTALL_LIBDIR:PATH=lib \*
> ...
>
> and recompile only superlu:
>
> sh compile_libraries.sh superlu
> and
> sh compile.sh superlu
>
> Cheers
> Dragan
>
>
> On 27/06/17 05:27, Raymond Smith wrote:
>> Classic. Thanks for the help.
>>
>> That got me quite a bit farther, but I run into something else
>> later. The project seems to compile the libraries okay (I didn't
>> quickly see any glaring errors):
>> https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69
>> <https://gist.github.com/anonymous/a300a4bccd01aecb918722d6f6a62f69>
>> but the build step seems to fail not being able to find superLU:
>> https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28
>> <https://gist.github.com/anonymous/eca131a83ef624043202245777bcce28>
>>
>> And then from a python prompt
>> >>> import daetools
>> >>> import daetools.pyDAE as dae
>> work fine. But trying to run a simulation unsurprisingly leads to
>> Traceback (most recent call last):
>> File
>> "/home/raymond/docs/bazantgroup/mpetwork/mpet//bin/mpetrun.py",
>> line 5, in <module>
>> import mpet.main as main
>> File
>> "/home/raymond/docs/bazantgroup/mpetwork/mpet/mpet/main.py", line
>> 11, in <module>
>> from daetools.solvers.superlu import pySuperLU
>> File
>> "/usr/lib/python3.6/site-packages/daetools/solvers/superlu.py",
>> line 20, in <module>
>> import pySuperLU
>> ModuleNotFoundError: No module named 'pySuperLU'
>>
>> Thoughts? If this is too much of a hassle, I can boot up the
>> Debian VM and compile there using more normal compilers, etc.
>>
>> Best,
>> Ray
>>
>> On Mon, Jun 26, 2017 at 2:20 AM, Dragan Nikolic
>> <dra...@gm... <mailto:dra...@gm...>> wrote:
>>
>> Hi again,
>>
>> I found what's causing it (the fmt library in coolprop). As
>> usual, it happens when people try to reinvent a wheel :-)
>>
>> That line (1890) in coolprop/externals/cppformat/fmt/format.h:
>>
>> const unsigned CHAR_WIDTH = 1;
>>
>> defines CHAR_WIDTH which is already defined as a macro in
>> <limits.h> (I checked, the new gcc 7.1 added it, I do not
>> have it in older versions).
>>
>> I added a fix to the compile_libraries.sh build script. It
>> works for me, please check - perhaps something else pops out.
>>
>> Cheers
>> Dragan
>>
>> PS By the way, what's new with you? Did you get a new
>> position or you are still at MIT?
>>
>>
>> On 26/06/17 01:55, Raymond Smith wrote:
>>
>> Hi.
>>
>> I am trying to compile the project, and I got an error on
>> the coolprop library compile, but I don't need that
>> package, so I thought I'd just skip it:
>>
>> $ sh compile_libraries.sh boost ref_blas_lapack umfpack
>> idas superlu superlu_mt bonmin nlopt trilinos deal.ii
>>
>> $ sh compile.sh all
>>
>> However, I got a different error related to the fact that
>> coolprop wasn't compiled in the second step:
>> make[1]: Entering directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
>> compiling dllmain.cpp
>> compiling stdafx.cpp
>> compiling dae_python.cpp
>> compiling python_wraps.cpp
>> rm -f libpyCore.so.1.7.0 libpyCore.so libpyCore.so.1
>> libpyCore.so.1.7
>> linking ../release/libpyCore.so.1.7.0
>> /usr/bin/ld: cannot find -lCoolProp
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [Makefile:253:
>> ../release/libpyCore.so.1.7.0] Error 1
>> make[1]: Leaving directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/pyCore'
>> make: *** [Makefile:360: sub-pyCore-make_first-ordered]
>> Error 2
>> make: Leaving directory
>> '/home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk'
>>
>> And for reference, the error from the coolprop compile:
>> [ 22%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/Fluids/FluidLibrary.cpp.o
>> [ 24%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSBackend.cpp.o
>> [ 26%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/HelmholtzEOSMixtureBackend.cpp.o
>> [ 28%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o
>> In file included from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:194:0,
>> from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/syslimits.h:7,
>> from
>> /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed/limits.h:34,
>> from /usr/include/c++/7.1.1/climits:42,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/Eigen/Eigen/Core:251,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.h:17,
>> from
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/src/Backends/Helmholtz/MixtureDerivatives.cpp:1:
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:
>> In member function ‘void
>> fmt::internal::ArgFormatterBase<Impl,
>> Char>::visit_char(int)’:
>> /home/raymond/builds/mine_python-daetools-svn/20170625/src/trunk/coolprop/externals/cppformat/fmt/format.h:1890:20:
>> error: expected unqualified-id before numeric constant
>> const unsigned CHAR_WIDTH = 1;
>> ^
>> [ 31%] Building CXX object
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureParameters.cpp.o
>> make[2]: *** [CMakeFiles/CoolProp.dir/build.make:351:
>> CMakeFiles/CoolProp.dir/src/Backends/Helmholtz/MixtureDerivatives.cpp.o]
>> Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[1]: *** [CMakeFiles/Makefile2:100:
>> CMakeFiles/CoolProp.dir/all] Error 2
>> make: *** [Makefile:130: all] Error 2
>>
>> I'm happy to provide more output if it may be helpful.
>>
>> I'm using svn r725 (corresponding to 1.7.0) on Linux
>> using gcc 7.1.1 glibc 2.25, python 3.6.1, numpy 1.13. I
>> realize those are more recent than those used in the
>> 'official' build based on the sourceforge release page,
>> so it may be related, especially to the compiler error
>> when trying to build coolprop. That's why I was hoping to
>> simply skip that one. Is there a way to build daetools
>> without it at this point? (or an easy way to get around
>> the coolprop compile error?)
>>
>> Thanks,
>> Ray
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the
>> world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> daetools-users mailing list
>> dae...@li...
>> <mailto:dae...@li...>
>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> daetools-users mailing list
>> dae...@li...
>> <mailto:dae...@li...>
>> https://lists.sourceforge.net/lists/listinfo/daetools-users
>> <https://lists.sourceforge.net/lists/listinfo/daetools-users>
>>
>>
>
>
|
