armadillo requested size is too large - c++

I am using armadillo4.300.0. I am operating on a dense matrix of size 2840260x103. I am loading this matrix from a .csv file of size approximately 3.7GB. I have enabled "ARMA_64BIT_WORD" in my application as well as config.hpp under armadillo_bits directory.
#if !defined(ARMA_64BIT_WORD)
#define ARMA_64BIT_WORD
#endif
I am compiling with gcc49 and running on ubuntu 12.04. When I run I am getting the following error. Interestingly, the application occasionally runs too. For eg., if I keep trying for some 10 times, it runs sometime.
error: Mat::init(): requested size is too large
terminate called after throwing an instance of 'std::logic_error'
what(): Mat::init(): requested size is too large
Do I need to take care of something else?
Ramki.

This problem is solved with the Intel MKL library, when we compile with the -DMKL_ILP64 -m64. Typically we focus only on link flags. But it is important to note that these flags must be enabled during compile phase on the gcc command as well. I am not sure how to enable this on openmpi library. Also the lib armadillo.so must link with mkl_ilp64 instead of mkl_lp64. Follow the instruction below.
Building and installing armadillo :
export CXX=icpc
export CC=icpc
export PATH=$PATH:/home/ramki/intel/bin:
Edit $armadillo_root/cmake_aux/Modules/ARMA_FindMKL.cmake, include the PATHS correctly.
Edit $armadillo_root/cmake_aux/Modules/ARMA_FindMKL.cmake, change mkl_lp64 to mkl_ilp64
Edit $armadillo_root/CMakeLists.txt and (1) Change CMAKE_SHARED_LINKER_FLAGS to include the link line by intel link advisor and (2) Change CMAKE_CXX_FLAGS as given by intel link advisor
Run ./configure and make sure MKL library is used for blas and lapack, icpc to be the compiler and the rest to be alright.
Run make .
Verify the linked libraries by running ldd libarmadillo.so. Mainly verify whether it is linked with mkl_ilp64 library and mkl blas and lapack libraries.
Now run make install DESTDIR=local path.
This should work.

Related

can't compile or-tools examples on Mac due to "make: *** No rule to make target `run'."

I have installed Google's or-tools on my Mac running 11.1 (Big Sur). When I run make test_cc, I get a long list with different results and also some messenges like ---- Integer programming example with CPLEX ---- Supports for solver CPLEX not linked in.
However, if I try an example from https://developers.google.com/optimization/introduction/cpp, I get the above error (see header) when trying to make and run the program (I have copy pasted the complete program). I have executed the make command with
Death-Star:or-tools me$ make run SOURCE=../Routing/Routing/main.cpp. ls ../Routing/Routing/main.cpp shows the file.
What have I done wrong?
or-tools version is 8.1.8487

Installing HDF5 library on Cygwin: "make check" stuck at testswmr.sh, no error message

I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry

CMakeLists Issue: bad_alloc error when calling resize() on thrust::device_vector

I am new to thrust library and trying to use it in my project. Here is a very simple code example. It can be compiled without any problem. However, when I try to run it, it gives me an error:
terminate called after throwing an instance of 'thrust::system::detail::bad_alloc'
what(): std::bad_alloc: unknown error
along with a warning:
nvlink warning : SM Arch ('sm_20') not found in ...
The project can be reproduced by using the following two files.
test.cpp
#include <thrust/device_vector.h>
int main(){
thrust::device_vector<int> x;
x.resize(10);
}
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.9)
project(test_project)
find_package(CUDA QUIET REQUIRED)
list(APPEND CUDA_NVCC_FLAGS "-std=c++11;-arch=compute_52")
set(CUDA_SEPARABLE_COMPILATION ON)
cuda_add_executable("cuda_test" "test.cu")
After some testing, it is obvious that if the line "set(CUDA_SEPARABLE_COMPILATION ON)" is removed, the program runs without problem. But I really need separable compilation activated for my project.
Any help or hint would be appreciated.
UPDATE:
Requested by #RobertCrovella, here are some more infos.
The CUDA version is 7.5, which is newly installed on UBUNTU 14.04 with GTX980. I did not update the Thrust library after that.
The following is the actual command generated by cmake by using "make VERBOSE=1".
CMake script with separable compilation
CMake script without separable compilation
UPDATE 2:
The same error is confirmed by #merelyMark. Since both the code and the CMakeLists file are extremely simple, is it possible that this is a bug in Thrust / CUDA ? [EDIT] No.
UPDATE 3:
Pointed out by #RobertCrovella, thrust library is working fine with proper cmake comands. Now the question: how can I generate those commands using CMakeLists?
Apologies in advance, I don't have enough points to add a comment, but I can confirm the behavior on my rig. This compiles properly on my machine with an E5-1650 v3 and a Quadro M4000 with CUDA 7.5 and Ubuntu 14.04.3. I get one warning error:
nvlink warning : SM Arch ('sm_20') not found in ...
I can confirm the behavior when I run it:
./cuda_test
terminate called after throwing an instance of 'thrust::system::detail::bad_alloc'
what(): std::bad_alloc: unknown error
Aborted (core dumped)
I agree with #RobertCrovella, I'm not really sure what you're trying to accomplish here.
Here's my VERBOSE output for separable compilation.
Here's my VERBOSE output without separable compilation.

Unable to run Woden Physics Example in Pharo

I am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?

How to compile CodeBlocks MingW in Windows to Ubuntu or Centos

Is there a way to compile with MingW with CodeBlocks in Windows so they can be used in Ubuntu or Centos distros?
I've tried compiling with GNU GCC option then got the output file with .o extensions under obj/Release/ folder.
When I run I get this error under my Vagrant Ubuntu machine:
-bash: ./main.o: cannot execute binary file
How can I compile it so it runs on my Linux machines?
The technical term for what you're trying to accomplish is cross-compilation. For that, you need to build a specific cross-compiler using GCC sources. If you still want to keep MinGW, there is a page explaining the steps needed to create a ARM cross-compiler : http://www.mingw.org/wiki/HostedCrossCompilerHOWTO. (you'll have to modify the target)
List of targets supported by GCC :
armv5te-android-gcc armv5te-linux-rvct armv5te-linux-gcc
armv5te-none-rvct
armv6-darwin-gcc armv6-linux-rvct armv6-linux-gcc
armv6-none-rvct
armv7-android-gcc armv7-darwin-gcc armv7-linux-rvct
armv7-linux-gcc armv7-none-rvct
mips32-linux-gcc
ppc32-darwin8-gcc ppc32-darwin9-gcc ppc32-linux-gcc
ppc64-darwin8-gcc ppc64-darwin9-gcc ppc64-linux-gcc
sparc-solaris-gcc
x86-android-gcc x86-darwin8-gcc x86-darwin8-icc
x86-darwin9-gcc x86-darwin9-icc x86-darwin10-gcc
x86-darwin11-gcc x86-darwin12-gcc x86-linux-gcc
x86-linux-icc x86-os2-gcc x86-solaris-gcc
x86-win32-gcc x86-win32-vs7 x86-win32-vs8
x86-win32-vs9
x86_64-darwin9-gcc x86_64-darwin10-gcc x86_64-darwin11-gcc
x86_64-darwin12-gcc x86_64-linux-gcc x86_64-linux-icc
x86_64-solaris-gcc x86_64-win64-gcc x86_64-win64-vs8
x86_64-win64-vs9
universal-darwin8-gcc universal-darwin9-gcc universal-darwin10-gcc
universal-darwin11-gcc universal-darwin12-gcc
generic-gnu
There is only one big caveat : since Windows is not POSIX compliant, I don't think you can use signals or pthreads.
Finally, brace yourself because it's a tedious task to build a cx-compiler (lots of obscure bugs). That's why profesionnal devs pays $$$ for "plug'n'play" solutions.
EDIT : this MXE project can be useful to you