Hello Oliver, Thank you for your reply.
I have tried with AppleClang without OpenMP, and the installation was successfully completed. Thank you. With that, I tried my OEM code, but the irregular t_field errors (discussed previously in emails with ARTS users and Simon Pfreundschuh) still occurred. I have tried with Homebrew Clang or GCC compilers and without the fortran and netCDF supports as well, and the errors still persisted. I am starting to question that the externally installed compilers or the packages might not be the problem. Maybe it has something more to do with some fundamental or built-in feature of Mac that is different from Ubuntu. What it may actually be, I could not guess. If anyone has tried the development version's OEM on Mac (or Macbook), with the test file "ARTS/controlfiles/artscomponents/oem/TestOEM.arts", with the retrieval quantity switched from O3 vmr to temperature, with the number of frequencies and the number of pressure layers reduced to about 20 (f_grid, p_gird, and p_ret_grid), and was successful without irregularly occurring errors for t_field during OEM, please let me know. Regards, Byungsuk Lee On Mon, Oct 15, 2018 at 3:45 PM Oliver Lemke <oliver.le...@uni-hamburg.de> wrote: > Hi Byungsuk, > > > On 8 Oct 2018, at 07:26, Byungsuk Lee <cbl6...@gmail.com> wrote: > > > > Hello Oliver, > > > > Thank you for your reply. > > > > 1) I don't think there is any Intel-related library in my PATH. Could > any of them below be an Intel library? Below are some of the lines from > CMakeCache.txt after cmake command using Apple Clang v10 and GNU gfortran > v8.2.0: > > [snip] > > //Details about finding OpenMP > > FIND_PACKAGE_MESSAGE_DETAILS_OpenMP:INTERNAL=[TRUE][TRUE][TRUE][c > ][v3.1()] > > //Details about finding OpenMP_C > > FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_C:INTERNAL=[-Xclang > -fopenmp][/usr/local/lib/libomp.dylib][v3.1()] > > //Details about finding OpenMP_CXX > > FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_CXX:INTERNAL=[-Xclang > -fopenmp][/usr/local/lib/libomp.dylib][v3.1()] > > //Details about finding OpenMP_Fortran > > > FIND_PACKAGE_MESSAGE_DETAILS_OpenMP_Fortran:INTERNAL=[-fopenmp][/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/libgomp.dylib][v4.5()] > > [snip] > > Doesn't look like any Intel related libraries are present. I guess > /usr/local/lib/libomp.dylib comes from brew? You could try to do a > compilation without the Fortran, NetCDF and OpenMP features. I don't think > you need any of the Fortran modules for your calculation. You can disable > OpenMP with 'cmake -DNO_OPENMP=1 ..'. Just to see if that fixes the > compilation errors. > > > 2) After installing ARTS with Homebrew llvm clang/clang++: > > export CC=/usr/local/opt/llvm/bin/clang > > export CXX=/usr/local/opt/llvm/bin/clang++ > > export FC=/usr/local/opt/gcc/bin/gfortran > > cmake -DENABLE_C_API=1 > -DARTS_XML_DATA_PATH=/Users/BLee/Desktop/ARTS/arts-xml-data-dev > -DENABLE_FORTRAN=1 -DENABLE_NETCDF=1 .. > > make -j4 > > > > I get the following from typing "otool -L src/arts": > > src/arts: > > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.2.11) > > /usr/local/opt/netcdf/lib/libnetcdf.13.dylib (compatibility > version 13.0.0, current version 13.0.0) > > > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate > (compatibility version 1.0.0, current version 4.0.0) > > /usr/local/opt/gcc/lib/gcc/8/libgfortran.5.dylib (compatibility > version 6.0.0, current version 6.0.0) > > /usr/local/lib/gcc/8/libgcc_s.1.dylib (compatibility version > 1.0.0, current version 1.0.0) > > /usr/local/opt/gcc/lib/gcc/8/libquadmath.0.dylib (compatibility > version 1.0.0, current version 1.0.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1252.50.4) > > /usr/local/opt/libomp/lib/libomp.dylib (compatibility version > 5.0.0, current version 5.0.0) > > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current > version 400.9.0) > > > > I am guessing that the Accelerate framework is properly included? > > Yes, that looks correct. > > Cheers, > Oliver > > > > Thank you, > > > > Byungsuk Lee > > > > > > > > On Thu, Oct 4, 2018 at 5:49 PM Oliver Lemke <oliver.le...@uni-hamburg.de> > wrote: > > Hi Byungsuk, > > > > > On 2 Oct 2018, at 11:39, Byungsuk Lee <cbl6...@gmail.com> wrote: > > > > > > Dear Jonas and Oliver, > > > > > > Thank you for your replies. I wanted to give you a sort of status > report regarding the use of ARTS on my Mac. > > > > > > 1) I checked ARTS/build/CMakeCache.txt and confirmed that no conda > package was used, other than CONDA_PROG:FILEPATH=... which I think is > irrelevant. > > > > > > 2) I tried compiling with gcc/g++ instead, both from Homebrew and from > manually installing tar.gz files from the gnu website for a few different > versions, but the same irregular invalid t_field errors in OEM happened. > Plus, at the cmake stage, they constantly produced a failure message for > "Wno-return-type-c-linkage" as follows, about which I am curious why. This > doesn't happen with clang/clang++. > > > > > > ... > > > -- Performing Test CCFLAG_Wno-sign-conversion > > > -- Performing Test CCFLAG_Wno-sign-conversion - Success > > > -- Performing Test CXXFLAG_Wno-sign-conversion > > > -- Performing Test CXXFLAG_Wno-sign-conversion - Success > > > -- Performing Test CCFLAG_Wno-unknown-pragmas > > > -- Performing Test CCFLAG_Wno-unknown-pragmas - Success > > > -- Performing Test CXXFLAG_Wno-unknown-pragmas > > > -- Performing Test CXXFLAG_Wno-unknown-pragmas - Success > > > -- Performing Test CCFLAG_Wno-return-type-c-linkage > > > -- Performing Test CCFLAG_Wno-return-type-c-linkage - Failed > > > -- Performing Test CXXFLAG_Wno-return-type-c-linkage > > > -- Performing Test CXXFLAG_Wno-return-type-c-linkage - Failed > > > -- Performing Test CCFLAG_Wno-strict-overflow > > > -- Performing Test CCFLAG_Wno-strict-overflow - Success > > > -- Performing Test CXXFLAG_Wno-strict-overflow > > > -- Performing Test CXXFLAG_Wno-strict-overflow - Success > > > ... > > > > Some compilers don't support the flag no-return-type-c-linkage. That is > totally fine and the reason that we test its existence with cmake before > enabling it. > > > > > 3) Instead of the clang/clang++ from Homebrew llvm with which I > initially installed ARTS, I thought I could instead try using Mac's command > line tools clang/clang++ (AppleClang v10), but they failed at the make > stage with the following error which I am not sure how to tackle. > > > > > > ... > > > [ 43%] Linking CXX executable make_auto_workspace_h > > > Undefined symbols for architecture x86_64: > > > "___kmpc_critical", referenced from: > > > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > > > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > > > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > > > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in > file.cc.o > > > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > > > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in > file.cc.o > > > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > > > ... > > > "___kmpc_end_critical", referenced from: > > > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > > > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > > > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > > > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in > file.cc.o > > > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > > > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in > file.cc.o > > > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > > > ... > > > "___kmpc_global_thread_num", referenced from: > > > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > > > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > > > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > > > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in > file.cc.o > > > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > > > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in > file.cc.o > > > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > > > ... > > > ld: symbol(s) not found for architecture x86_64 > > > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > make[2]: *** [src/make_auto_workspace_h] Error 1 > > > make[1]: *** [src/CMakeFiles/make_auto_workspace_h.dir/all] Error 2 > > > [ 43%] Building CXX object > src/CMakeFiles/test_gridded_fields.dir/test_gridded_fields.cc.o > > > [ 43%] Building CXX object > src/CMakeFiles/test_legendre.dir/test_legendre.cc.o > > > [ 43%] Linking CXX executable test_legendre > > > [ 43%] Built target test_legendre > > > [ 43%] Linking CXX executable test_gridded_fields > > > [ 43%] Built target test_gridded_fields > > > make: *** [all] Error 2 > > > ... > > > > This is interesting. The __kmpc_* Symbols come from the Intel Math > Kernel Library. These errors usually indicate that the Intel Threading > library was enabled, but the Intel OpenMP Library was not linked. Which > makes sense because Apple's Clang does not support OpenMP. But we might be > on to something here. The Intel MKL should involved here at all. Do you > have an Intel compiler set up in your PATH? > > > > > 4) I tried using Homebrew lapack instead of Mac's default > Accelerate.framework but the same irregular OEM error happened. > > > > > > I have tried several things as above hoping to pinpoint where the > error stems from (compiler, package, or something else?) but am so far > unsuccessful and encountered additional errors that I hope someone could > explain. Thank you. > > > > Are you sure that you're actually compiling against Lapack / Accelerate > and not accidentally always against MKL? What you're seeing in 3) makes me > a bit suspicious. Can you please check with 'otool -L src/arts' which > libraries your ARTS executable is actually linked against? > > > > cheers, > > /oliver > > > > > > > > > >
_______________________________________________ arts_users.mi mailing list arts_users.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
