Make Error (Opensuse 15, Cuda 10)

[nicolin]

Make Error (Opensuse 15, Cuda 10)

[Oblomov]

Hello, can you paste the output of make echo=1 plain=1 -j1?

[nicolin]

Hi sure here it is: nicolin@linux-ff2q:~/Downloads/gpusph-4.1> make echo=1 plain=1 -j1 Makefile:41: Unable to determine GPUSPH version MPI compiler not found, multi-node will NOT be supported HDF5 library not found, HDF5 input will NOT be supported [SCRIPTS] list-cuda-cc /usr/local/cuda/bin/nvcc -ccbin=g++ -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DUSE_HDF5=0 -D__COMPUTE__=0 -Wno-deprecated-gpu-targets -D__NVCC_VERSION__=100 -std=c++11 --compiler-options -m64,-O3 -o scripts/list-cuda-cc scripts/list-cuda-cc.cc /usr/local/lib -L/usr/local/lib -L/usr/local/cuda/lib64 -L/usr/local/cuda/samples/common/lib/linux/x86_64/ nvcc fatal : Don't know what to do with '/usr/local/lib' [CC] XProblem.o g++ -isystem /usr/local/cuda/include -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DUSE_HDF5=0 -D__COMPUTE__=0 -m64 -std=c++11 -O3 -c -o build/XProblem.o src/XProblem.cc In file included from src/GlobalData.h:58:0, from src/XProblem.cc:43: src/linearization.h:38:36: fatal error: linearization_select.opt: No such file or directory #include "linearization_select.opt" ^ compilation terminated.

…

On Sat, Mar 2, 2019 at 5:23 PM Oblomov ***@***.***> wrote: Hello, can you paste the output of make echo=1 plain=1 -j1? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF2nnWi3KFtwfew4DPkTi5qmgI7PJeD4ks5vSrOOgaJpZM4bZydq> .

[Oblomov]

You have a spurious /usr/local/lib and I do not understand where it's coming from. Do you have a Makefile.local ? If so, what is its contents? Also, can you show the output of make show?

[nicolin]

Hi, i did not change anything, just downloaded and tried to make. Here is the output of make show: Makefile:41: Unable to determine GPUSPH version MPI compiler not found, multi-node will NOT be supported HDF5 library not found, HDF5 input will NOT be supported [SCRIPTS] list-cuda-ccnvcc fatal : Don't know what to do with '/usr/local/lib' GPUSPH version: unknown-version Platform: Linux Architecture: x86_64 Current dir: /home/nicolin/Downloads/gpusph-4.1 This Makefile: /home/nicolin/Downloads/gpusph-4.1/Makefile Problem: DamBreak3D Linearization: yzx Snapshot file: ./GPUSPH-unknown-version-.tgz Target binary: dist/linux/x86_64/GPUSPH Sources dir: src src/cuda src/geometries src/problems src/writers Options dir: options Objects dir: build build/cuda build/geometries build/problems build/writers build/problems/user Scripts dir: scripts Docs dir: docs Doxygen conf: ./Doxygen_settings Verbose: Debug: CXX: g++ MPICXX: g++ nvcc: /usr/local/cuda/bin/nvcc -ccbin=g++ nvcc version: 10.0 LINKER: /usr/local/cuda/bin/nvcc -ccbin=g++ Compute cap.: Fastmath: 0 USE_MPI: 0 USE_HDF5: 0 USE_CHRONO: 0 default paths: /usr/include/c++/4.8 /usr/include/c++/4.8/x86_64-suse-linux /usr/include/c++/4.8/backward /usr/lib64/gcc/x86_64-suse-linux/4.8/include /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed /usr/x86_64-suse-linux/include /usr/include INCPATH: -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions LIBPATH: /usr/local/lib -L/usr/local/lib -L/usr/local/cuda/lib64 -L/usr/local/cuda/samples/common/lib/linux/x86_64/ LIBS: -lcudart -lpthread -lrt LDFLAGS: /usr/local/lib -L/usr/local/lib -L/usr/local/cuda/lib64 -L/usr/local/cuda/samples/common/lib/linux/x86_64/ CPPFLAGS: -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DUSE_HDF5=0 -D__COMPUTE__=0 CXXFLAGS: -m64 -std=c++11 -O3 CUFLAGS: -D__NVCC_VERSION__=100 --generate-line-info -std=c++11 --compiler-options -m64,-O3 nicolin@linux-ff2q:~/Downloads/gpusph-4.1> make show Makefile:41: Unable to determine GPUSPH version MPI compiler not found, multi-node will NOT be supported HDF5 library not found, HDF5 input will NOT be supported [SCRIPTS] list-cuda-ccnvcc fatal : Don't know what to do with '/usr/local/lib' GPUSPH version: unknown-version Platform: Linux Architecture: x86_64 Current dir: /home/nicolin/Downloads/gpusph-4.1 This Makefile: /home/nicolin/Downloads/gpusph-4.1/Makefile Problem: DamBreak3D Linearization: yzx Snapshot file: ./GPUSPH-unknown-version-.tgz Target binary: dist/linux/x86_64/GPUSPH Sources dir: src src/cuda src/geometries src/problems src/writers Options dir: options Objects dir: build build/cuda build/geometries build/problems build/writers build/problems/user Scripts dir: scripts Docs dir: docs Doxygen conf: ./Doxygen_settings Verbose: Debug: CXX: g++ MPICXX: g++ nvcc: /usr/local/cuda/bin/nvcc -ccbin=g++ nvcc version: 10.0 LINKER: /usr/local/cuda/bin/nvcc -ccbin=g++ Compute cap.: Fastmath: 0 USE_MPI: 0 USE_HDF5: 0 USE_CHRONO: 0 default paths: /usr/include/c++/4.8 /usr/include/c++/4.8/x86_64-suse-linux /usr/include/c++/4.8/backward /usr/lib64/gcc/x86_64-suse-linux/4.8/include /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed /usr/x86_64-suse-linux/include /usr/include INCPATH: -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions LIBPATH: /usr/local/lib -L/usr/local/lib -L/usr/local/cuda/lib64 -L/usr/local/cuda/samples/common/lib/linux/x86_64/ LIBS: -lcudart -lpthread -lrt LDFLAGS: /usr/local/lib -L/usr/local/lib -L/usr/local/cuda/lib64 -L/usr/local/cuda/samples/common/lib/linux/x86_64/ CPPFLAGS: -Isrc -Isrc/cuda -Isrc/geometries -Isrc/problems -Isrc/writers -Isrc/problems/user -Ioptions -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DUSE_HDF5=0 -D__COMPUTE__=0 CXXFLAGS: -m64 -std=c++11 -O3 CUFLAGS: -D__NVCC_VERSION__=100 --generate-line-info -std=c++11 --compiler-options -m64,-O3

…

On Sat, Mar 2, 2019 at 5:28 PM Oblomov ***@***.***> wrote: You have a spurious /usr/local/lib and I do not understand where it's coming from. Do you have a Makefile.local ? If so, what is its contents? Also, can you show the output of make show? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF2nnX4b6kiCqW62-j1nfDkXUkOi8nN6ks5vSrSsgaJpZM4bZydq> .

[Oblomov]

Oh, I see what's happening. You have the LIBPATH environment variable set, and the Makefile is picking it upto set its own variable. Can you try running LIBPATH= make ?

[nicolin]

Thanks, it is building now. PS: I will be looking at coupling it to my DEM code, we already have a coupling to DualSphysics but the are accuracy problems with it for the hindered settling problem 1/15 DEM particle to SPH ratio is needed to get it close to experiment. So for real applications it requires too many SPH particles. https://www.researchgate.net/project/Blaze-DEM-A-Large-Scale-GPU-Based-DEM-code

…

On Sat, Mar 2, 2019 at 6:06 PM Oblomov ***@***.***> wrote: Oh, I see what's happening. You have the LIBPATH environment variable set, and the Makefile is picking it upto set its own variable. Can you try running LIBPATH= make ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF2nnRyAgbAaJz7usclz59nhNmszj5-Pks5vSr2-gaJpZM4bZydq> .

[Oblomov]

This looks very interesting. Feel free to let us know if you need any assistance with the coupling.

You might also want to look into the next branch as basis for your work, it has noticeably progressed since the last release, and will see some powerful changes in the upcoming days which should make integration with other frameworks easier.

[nicolin]

Thanks, do let me know when i can access the next branch. A) The easiest coupling would be using volume fraction, so SPH gets a pointer to an array with void fraction values in cells and then returns a fluid velocity in each cell. For large scale applications the void fraction method is the only feasible option. B) For a fully resolved coupling, each DEM particle ( sphere or polyhedron) would need to be meshed with SPH particles and then each step the particle orientation and position will be updated. Unless youll do this on the fly ? We would need to work together on how this geometric detail is handled for each particle etc. Note that i do have a fully resolved SPH solver using gradient correction so 1st order accurate inside my code ( see attached document). However such a detailed simulation can only be done for a few thousands of DEM particles if the simulation is to be run in a month. PS: If anyone from your team will be at GTC in a few weeks do let me know. I have an invited talk there. https://gputechconf2019.smarteventscloud.com/connect/sessionDetail.ww?SESSION_ID=272264 Cheers

…

On Sat, Mar 2, 2019 at 6:23 PM Oblomov ***@***.***> wrote: This looks very interesting. Feel free to let us know if you need any assistance with the coupling. You might also want to look into the next branch as basis for your work, it has noticeably progressed since the last release, and will see some powerful changes in the upcoming days which should make integration with other frameworks easier. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF2nnfR2gCtizo-2VCYwBmqvgG-0m-S-ks5vSsGmgaJpZM4bZydq> .

[Oblomov]

The next branch has been made public a few months ago, so if you clone the repository you will be able to access it.

Option A) looks very similar to what we already do with GPUSPH to support rigid bodies using Chrono. The key part is a segmented scan that collects the per-object contribution, and we could use something similar in your case.

Option B) should also be possible, again by introducing appropriate hooks before the integration kernel (which would then just set the particles' data based on the hooks results).

We're also currently looking into setting up a Discourse instance, that will be much more appropriate forum to discuss these kind of stuff than the GitHub issues ;-)

[nicolin]

Thanks will do.