Hello,
I am attempting to connect two bodies with a revolute joint, so that one is stationary and the other rotates around it along a single axis (the y-axis, in GPUSPH). I am trying to implement the ChLinkLockRevolute constraint using chrono, and I have a couple of questions.
Here is the code so far for the joint:
// revolute joint
// Make a new ChLinkRevolute
auto rev_joint = std::make_shared< ::chrono::ChLinkLockRevolute >(); // create the link
auto a1 = getGeometryInfo(flap)->ptr->GetBody(); // get info for the body that will be rotating
auto a2 = getGeometryInfo(base)->ptr->GetBody(); // get info for stationary body
rev_joint->SetName("RevoluteConstraint"); // set name of restraint
// Initialize revolute joint
rev_joint->Initialize(a1, a2, ChCoordsys<>(ChVector<>(piston_x + flap_width/2, piston_width/2, base_height + (0.564-0.458)/2), chrono::Q_from_AngAxis(CH_C_PI / 2, VECT_Y)));
// Add the link to the physical system
m_bodies_physical_system->AddLink( rev_joint );
The first question is when I try to compile this, I get an error that says:
error: identifier "ChCoordsys" is undefined
But I have the following scripts included at the top of my code:
#include "chrono/core/ChCoordsys.h"
#include "chrono/physics/ChLinkLock.h"
So I feel like ChCoordsys should be defined by that? I’m also quite new to C++ and am still trying to understand all of these things. It’s pretty clear that the initialization step is what is causing me problems, so any help with that would be great!
I also am confused about the coordinate systems for each body. If I want the link to allow rotation about the y-axis that is defined in GPUSPH, does that also mean that chrono knows that is the y-axis?
I hope these questions make sense, any guidance is greatly appreciated! Thank you!
Hello @brittlyd,
Everything that belongs to Project Chrono should be called from the chrono namespace. So, similarly to ::chrono::ChLinkLockRevolute, it should be ::chrono::ChCoordsys. The same holds for ChVector.
Concerning the axes, everything created in Project Chrono by GPUSPH maintains the coordinates adopted within GPUSPH. So yes, the reference systems are in correspondence.
Hope this answers your questions,
Vito
Hi @vito.zago,
Thank you so much for your help! That helped a lot. My code now compiles and I ran it for just two time steps to see if there were any problems. The code ran, but then I received an error that looks like this:
*** Error in `./LydonPeriodicWaveTankWASIRF': corrupted size vs. prev_size: 0x0000000001298c00 ***
And then it lists the following:
======= Backtrace: =========
/lib64/libc.so.6(+0x80c37)[0x7f88233cec37]
/lib64/libc.so.6(+0x8120e)[0x7f88233cf20e]
./LydonPeriodicWaveTankWASIRF[0x54bdd4]
./LydonPeriodicWaveTankWASIRF[0x43eacf]
./LydonPeriodicWaveTankWASIRF[0x4c20c5]
./LydonPeriodicWaveTankWASIRF[0x48ef1f]
./LydonPeriodicWaveTankWASIRF[0x413560]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8823370555]
./LydonPeriodicWaveTankWASIRF[0x41413f]
======= Memory map: ========
00400000-007e8000 r-xp 00000000 103:0b 548019797 /home/blydon/gpusph/dist/linux/x86_64/LydonPeriodicWaveTankWASIRF
009e8000-009e9000 r--p 003e8000 103:0b 548019797 /home/blydon/gpusph/dist/linux/x86_64/LydonPeriodicWaveTankWASIRF
009e9000-009eb000 rw-p 003e9000 103:0b 548019797 /home/blydon/gpusph/dist/linux/x86_64/LydonPeriodicWaveTankWASIRF
009eb000-009ed000 rw-p 00000000 00:00 0
01265000-02336000 rw-p 00000000 00:00 0 [heap]
200000000-500200000 ---p 00000000 00:00 0
7f87ec000000-7f87ec021000 rw-p 00000000 00:00 0
7f87ec021000-7f87f0000000 ---p 00000000 00:00 0
7f87f0000000-7f87f0021000 rw-p 00000000 00:00 0
7f87f0021000-7f87f4000000 ---p 00000000 00:00 0
7f87f4000000-7f87f4021000 rw-p 00000000 00:00 0
7f87f4021000-7f87f8000000 ---p 00000000 00:00 0
7f87f8000000-7f87f8b4e000 rw-p 00000000 00:00 0
7f87f8b4e000-7f87fc000000 ---p 00000000 00:00 0
7f87fc000000-7f87fcc92000 rw-p 00000000 00:00 0
7f87fcc92000-7f8800000000 ---p 00000000 00:00 0
7f8800000000-7f8810000000 ---p 00000000 00:00 0
7f8812000000-7f8818000000 ---p 00000000 00:00 0
7f8818000000-7f8818cbe000 rw-p 00000000 00:00 0
7f8818cbe000-7f881c000000 ---p 00000000 00:00 0
7f881c71d000-7f881c71e000 ---p 00000000 00:00 0
7f881c71e000-7f881cf1e000 rw-p 00000000 00:00 0
7f881df20000-7f881df21000 ---p 00000000 00:00 0
7f881df21000-7f881e721000 rw-p 00000000 00:00 0
7f881e721000-7f881f9fc000 r-xp 00000000 103:0a 33628135 /usr/lib64/libcuda.so.460.27.04
7f881f9fc000-7f881fbfb000 ---p 012db000 103:0a 33628135 /usr/lib64/libcuda.so.460.27.04
7f881fbfb000-7f881fcd0000 r--p 012da000 103:0a 33628135 /usr/lib64/libcuda.so.460.27.04
7f881fcd0000-7f881fdda000 rw-p 013af000 103:0a 33628135 /usr/lib64/libcuda.so.460.27.04
7f881fdda000-7f881fdf6000 rw-p 00000000 00:00 0
7f881fdf6000-7f881fdf7000 ---p 00000000 00:00 0
7f881fdf7000-7f88205f7000 rw-p 00000000 00:00 0
7f88205f7000-7f88205f8000 ---p 00000000 00:00 0
7f88205f8000-7f8820df8000 rw-p 00000000 00:00 0
7f8820df8000-7f8820df9000 ---p 00000000 00:00 0
7f8820df9000-7f88215f9000 rw-p 00000000 00:00 0
7f8821e73000-7f8822674000 rw-p 00000000 00:00 0
7f8822c76000-7f8823128000 rw-p 00000000 00:00 0
7f8823128000-7f882314d000 r-xp 00000000 103:0a 33759534 /usr/lib64/libgomp.so.1.0.0
7f882314d000-7f882334c000 ---p 00025000 103:0a 33759534 /usr/lib64/libgomp.so.1.0.0
7f882334c000-7f882334d000 r--p 00024000 103:0a 33759534 /usr/lib64/libgomp.so.1.0.0
7f882334d000-7f882334e000 rw-p 00025000 103:0a 33759534 /usr/lib64/libgomp.so.1.0.0
7f882334e000-7f8823512000 r-xp 00000000 103:0a 33758824 /usr/lib64/libc-2.17.so
7f8823512000-7f8823711000 ---p 001c4000 103:0a 33758824 /usr/lib64/libc-2.17.so
7f8823711000-7f8823715000 r--p 001c3000 103:0a 33758824 /usr/lib64/libc-2.17.so
7f8823715000-7f8823717000 rw-p 001c7000 103:0a 33758824 /usr/lib64/libc-2.17.so
7f8823717000-7f882371c000 rw-p 00000000 00:00 0
7f882371c000-7f8823731000 r-xp 00000000 103:0a 33554510 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8823731000-7f8823930000 ---p 00015000 103:0a 33554510 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8823930000-7f8823931000 r--p 00014000 103:0a 33554510 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8823931000-7f8823932000 rw-p 00015000 103:0a 33554510 /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8823932000-7f8823a33000 r-xp 00000000 103:0a 33758832 /usr/lib64/libm-2.17.so
7f8823a33000-7f8823c32000 ---p 00101000 103:0a 33758832 /usr/lib64/libm-2.17.so
7f8823c32000-7f8823c33000 r--p 00100000 103:0a 33758832 /usr/lib64/libm-2.17.so
7f8823c33000-7f8823c34000 rw-p 00101000 103:0a 33758832 /usr/lib64/libm-2.17.so
7f8823c34000-7f8823d1d000 r-xp 00000000 103:0a 33758896 /usr/lib64/libstdc++.so.6.0.19
7f8823d1d000-7f8823f1d000 ---p 000e9000 103:0a 33758896 /usr/lib64/libstdc++.so.6.0.19
7f8823f1d000-7f8823f25000 r--p 000e9000 103:0a 33758896 /usr/lib64/libstdc++.so.6.0.19
7f8823f25000-7f8823f27000 rw-p 000f1000 103:0a 33758896 /usr/lib64/libstdc++.so.6.0.19
7f8823f27000-7f8823f3c000 rw-p 00000000 00:00 0
7f8823f3c000-7f8823f3e000 r-xp 00000000 103:0a 33758830 /usr/lib64/libdl-2.17.so
7f8823f3e000-7f882413e000 ---p 00002000 103:0a 33758830 /usr/lib64/libdl-2.17.so
7f882413e000-7f882413f000 r--p 00002000 103:0a 33758830 /usr/lib64/libdl-2.17.so
7f882413f000-7f8824140000 rw-p 00003000 103:0a 33758830 /usr/lib64/libdl-2.17.so
7f8824140000-7f8826e7c000 r-xp 00000000 103:0b 537940048 /home/blydon/chrono/build/lib/libChronoEngine.so
7f8826e7c000-7f882707b000 ---p 02d3c000 103:0b 537940048 /home/blydon/chrono/build/lib/libChronoEngine.so
7f882707b000-7f88270cc000 r--p 02d3b000 103:0b 537940048 /home/blydon/chrono/build/lib/libChronoEngine.so
7f88270cc000-7f8827192000 rw-p 02d8c000 103:0b 537940048 /home/blydon/chrono/build/lib/libChronoEngine.so
7f8827192000-7f882719a000 rw-p 00000000 00:00 0
7f882719a000-7f88271a1000 r-xp 00000000 103:0a 33758861 /usr/lib64/librt-2.17.so
7f88271a1000-7f88273a0000 ---p 00007000 103:0a 33758861 /usr/lib64/librt-2.17.so
7f88273a0000-7f88273a1000 r--p 00006000 103:0a 33758861 /usr/lib64/librt-2.17.so
7f88273a1000-7f88273a2000 rw-p 00007000 103:0a 33758861 /usr/lib64/librt-2.17.so
7f88273a2000-7f88273b9000 r-xp 00000000 103:0a 33758856 /usr/lib64/libpthread-2.17.so
7f88273b9000-7f88275b8000 ---p 00017000 103:0a 33758856 /usr/lib64/libpthread-2.17.so
7f88275b8000-7f88275b9000 r--p 00016000 103:0a 33758856 /usr/lib64/libpthread-2.17.soAborted (core dumped)
I’m not sure how to proceed, I assume it’s a memory issue but I’m not sure if it as an issue with the code, or where things are located on my computer or something like that?
Any guidance on this issue would be greatly appreciated!
Thank you,
Brittany
Hello @brittlyd,
this is possibly an issue due to Chrono and GPUSPH being built with different CPU architectural flags. Can you try adding CXXFLAGS += -march=native at the end of your Makefile.local? (If you don’t have the file, just create it with that line.)
Then rebuild your problem from scratch (make clean followed by make LydonPeriodicWaveTankWASIRF)
Hi @giuseppe.bilotta ,
I tried adding that command and I rebuilt my problem from scratch and am still getting the same error. Do you have any idea of what else it could be?
Thank you so much for your help!
Brittany
Hello @brittlyd,
if I understand correctly, this issue only happens at the end of the simulation, is this correct?
One thing you could try to see where the issue might be could be to build the host code in debug mode (CPPFLAGS+=-g in Makefile.local, and rebuild after a make clean) and without OpenMP support, then running under gdb or valgrind to see if we get more accurate information about which piece of code is causing the issue.