Hi Victor,
Having some negative slip outputs is possible, as long as the average looks
reasonable. In the paper, we reported the slip averaged across about 6
seconds, starting after we believe the wheel reached a quasi-steady
climbing stage. But if your average slip reaches 0 or negative while the
physics shouldn't be like that (aka you are not running on flat terrain or
going downhill), then it's not right.
I'd say it's either the slip calculation somehow does not reflect the
actual slip, or the simulation physics is not running as you think it is.
So you have to render the simulation scene to make sure it is not the
latter; you can also visually derive the approximate slip ratio to compare
the result you get from the log. So please do the rendering first, this is
important.
Thank you,
Ruochun
On Wednesday, September 4, 2024 at 5:38:26 PM UTC+8 Victor Michel wrote:
> Hello Ruochun,
> I come once again with a question about the WheelSlopeSlip demo.
> After looking carefully at the result of the modified demo I have been
> telling you about, I noticed something odd. A bit less than half of the
> Slip value I get in the output are negative. I attached a .txt of the
> output so you can check yourself. From my understanding, the slip ratio is
> defined as s = 1 − v∕(𝜔r) and therefore should, at least in the case of a
> 0 deg slope, have values ranging from 0 to 1 ?
> To be sure this was not a mis-input of r on my side I went to check the
> diameter of the wheel in the simulation output using ParaView and the
> diameter is indeed equal to two times the radius I inputted so I don't
> think the issue comes from there.
> Do you have an idea where those negative values could come from ? unless
> maybe I misunderstood something and those negative values are normal?
> Also as a subsequent question, in the paper that was published in January
> about DEM-E by you and your colleagues, in the part about this specific
> demo, you produced two graphs showing the relation between slip ratio and
> the slope. The output of this demo giving one slip value per time step, and
> so numerous values slope, did you use and average of all those values to
> get one value pet slope ?
> Thank you so much for your answer !
> Victor
> Le mercredi 31 juillet 2024 à 12:22:42 UTC+9, Victor Michel a écrit :
>
>> Hi Ruochun !
>>
>> I think I didn't wait long enough then, I wasn't expecting this single
>> line to take that long so I think I gave up after 8 hours, but my gpu being
>> much weaker than A100 (and I only have one) it's probably gonna take a good
>> while.
>>
>> As you said I'll try to make the problem smaller cause while I need the
>> GRC simulant for my project, I probably don't need that much. Thank you so
>> much for your help !
>>
>> Also I pulled the new version and your cmake fix works perfectly, thank
>> you for that !
>>
>> Once I finish reducing the GRC simulation size and run it I'll keep you
>> updated on the results, hoping I don't run into any other issues until then
>> !
>>
>> Thank you again for all the help you provided, you've been incredible !
>> Victor
>> Le mercredi 31 juillet 2024 à 11:47:24 UTC+9, Ruochun Zhang a écrit :
>>
>>> Hi Victor,
>>>
>>> How long did you wait before giving up here? For me, this line could
>>> easily take something like 8 hours to run on V100s or 4 hours on A100s.
>>>
>>> That said, I probably need to take back what I said about memory usage.
>>> I only tested with something like 60GB RAM and 40GB VRAM. Smaller RAM may
>>> work but I never tested. So if you already waited for a long time but still
>>> no go and you can't immediately add RAM, you could try even smaller
>>> problems, like reducing the 8 patches of particles to 2 patches... It
>>> defeats the purpose I know, but it's for testing.
>>>
>>> Finally, if you will, please pull the newest main branch then resume
>>> your test. While looking into the Part3 demo, I found it has an outdated
>>> API and fixed it. I also added the cmake fail-safe mechanism in the new
>>> upload, and I'd appreciate it if you try it out.
>>>
>>> Thank you,
>>> Ruochun
>>>
>>> On Monday, July 29, 2024 at 1:37:25 PM UTC+8 Victor Michel wrote:
>>>
>>>> Hi Ruochun,
>>>>
>>>> So I tried your fix and unfortunately it doesn't seem to work. After
>>>> working around the file a little I can tell you that the line causing the
>>>> process to get stuck is line 181 :
>>>> *DEMSim.DoDynamicsThenSync(0.3);*
>>>> However I still don't understand why it gets stuck there...
>>>>
>>>> Do you have an idea ?
>>>> Thank you again for your help !
>>>> Victor.
>>>> Le vendredi 26 juillet 2024 à 10:55:14 UTC+9, Ruochun Zhang a écrit :
>>>>
>>>>> Hi Victor,
>>>>>
>>>>> 12GB of VRAM might be enough, but I think when I tested I used at
>>>>> least 20GB. It's generally fine if all other (smaller) demos run without
>>>>> stalling. But if you are super concerned, you can try running Part3 with
>>>>> less particles. Part3 duplicates the result from Part2 and concatenate 8
>>>>> such identical patches together to form a large solil bin. The locations
>>>>> to
>>>>> put those duplicated patches are in line 127 and 128. You could just
>>>>> duplicate fewer patches: For example you can replace *y_shift_dist =
>>>>> {-0.5, 0.5}* with *y_shift_dist = {-0.5}*. With less particles it
>>>>> should run.
>>>>>
>>>>> Thank you!
>>>>> Ruochun
>>>>>
>>>>> On Friday, July 26, 2024 at 9:29:34 AM UTC+8 Victor Michel wrote:
>>>>>
>>>>>> Hi Ruochun !
>>>>>>
>>>>>> I have 32GB of RAM and 12GB of VRAM (GeForce RTX 4070 Ti). I hoped it
>>>>>> would be enough but maybe I need to add some more RAM then ?
>>>>>>
>>>>>> Thank you so much for your help.
>>>>>> Victor
>>>>>>
>>>>>> Le vendredi 26 juillet 2024 à 00:10:36 UTC+9, Ruochun Zhang a écrit :
>>>>>>
>>>>>>> Hi Victor,
>>>>>>>
>>>>>>> First, sorry that the path in Part3 is an oversight. You do have to
>>>>>>> copy that over from Part2's output folder, which makes it quite
>>>>>>> inconsistent. I'll change that in the next update. Right now, your fix
>>>>>>> suffices.
>>>>>>>
>>>>>>> About the stalling, because Part3 is quite a big simulation and it
>>>>>>> freezes at the beginning, the most likely reason is the memory ran out.
>>>>>>> How
>>>>>>> much RAM and VRAM do you have and if it's on a cluster, how much memory
>>>>>>> did
>>>>>>> you request?
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Ruochun
>>>>>>>
>>>>>>> On Thursday, July 25, 2024 at 10:58:15 AM UTC+8 Victor Michel wrote:
>>>>>>>
>>>>>>>> Hi Ruochun
>>>>>>>>
>>>>>>>> I was trying the different demos (SingleSphereCollide, Mixer,
>>>>>>>> Sieve, Centrifuge) and they were running just fine until I tried the
>>>>>>>> GRC_Prep_Part3. I of course ran the part 1 and 2 previously and they
>>>>>>>> ran
>>>>>>>> without any issue, but when trying to run part 3 it gives me an error
>>>>>>>> when
>>>>>>>> trying to locate the file GRC_3e6.csv
>>>>>>>>
>>>>>>>> After checking the code for part 3 I realized that the subfolder
>>>>>>>> for that file wasn't added to the path when calling it, so I just
>>>>>>>> copied
>>>>>>>> all the files from the GRCPrep_Part2 folder directly into the bin in
>>>>>>>> hope
>>>>>>>> it would fix the issue. Which it kinda did since now I dont get the
>>>>>>>> error
>>>>>>>> anymore and the process starts but then it seems to get stuck (I
>>>>>>>> joined a
>>>>>>>> screenshot of the point it gets stuck at.)
>>>>>>>>
>>>>>>>> Since it's not an error anymore I'm wondering if maybe it may have
>>>>>>>> something to do with the little change I had to make to build DEM-E ?
>>>>>>>> Do
>>>>>>>> you think it might be the case ?
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Victor
>>>>>>>> Le lundi 22 juillet 2024 à 20:59:41 UTC+9, Ruochun Zhang a écrit :
>>>>>>>>
>>>>>>>>> Hi Victor,
>>>>>>>>>
>>>>>>>>> It's not a permanent fix though, and I still wonder the reason.
>>>>>>>>> Please also make sure that the demos are runnable. I might later on
>>>>>>>>> add a
>>>>>>>>> fail-safe mechanism for the C++ standard detection function to patch
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Ruochun
>>>>>>>>>
>>>>>>>>> On Monday, July 22, 2024 at 7:42:00 PM UTC+8 Victor Michel wrote:
>>>>>>>>>
>>>>>>>>>> Hi Ruochun !
>>>>>>>>>>
>>>>>>>>>> Patching the cmake file worked just right ! I could build DEME
>>>>>>>>>> and run the demos without any issues !
>>>>>>>>>>
>>>>>>>>>> Thank you a lot for your help !
>>>>>>>>>> Victor
>>>>>>>>>>
>>>>>>>>>> Le samedi 20 juillet 2024 à 16:10:11 UTC+9, Ruochun Zhang a
>>>>>>>>>> écrit :
>>>>>>>>>>
>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>
>>>>>>>>>>> I guess there are two things that we can try.
>>>>>>>>>>>
>>>>>>>>>>> 1. You said you switched to gcc-11, but it looks like the CXX
>>>>>>>>>>> options are still pointing to gcc-12. Perhaps cmake is trying to
>>>>>>>>>>> look for
>>>>>>>>>>> non-matching or non-existent libraries. You might want to try to
>>>>>>>>>>> resolve
>>>>>>>>>>> that. That said, gcc-12 itself should not be the problem as I was
>>>>>>>>>>> able to
>>>>>>>>>>> successfully build the project with gcc-12.
>>>>>>>>>>>
>>>>>>>>>>> 2. If everything else fails, you might want to change the
>>>>>>>>>>> content of the *cxx_std_autodetect *cmake function to this
>>>>>>>>>>> one-liner:
>>>>>>>>>>> *set(CXXSTD_SUPPORTED 17 CACHE INTERNAL "")*
>>>>>>>>>>> as a temporary patch, to see if it can at least make DEME
>>>>>>>>>>> buildable.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Ruochun
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Friday, July 19, 2024 at 7:47:24 PM UTC+8 Victor Michel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Ruochun,
>>>>>>>>>>>>
>>>>>>>>>>>> Here are the screenshots of the advanced options.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you again,
>>>>>>>>>>>> Victor
>>>>>>>>>>>>
>>>>>>>>>>>> Le vendredi 19 juillet 2024 à 19:00:03 UTC+9, Ruochun Zhang a
>>>>>>>>>>>> écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's a bit weird to me that *CXXSTD_SUPPORTED *is not
>>>>>>>>>>>>> properly set after the autodetect call. It will probably be
>>>>>>>>>>>>> easier to debug
>>>>>>>>>>>>> in the CxxStdAutodetect.cmake file and *message *out the
>>>>>>>>>>>>> variables to see what is happening, provided that you are able to
>>>>>>>>>>>>> write a
>>>>>>>>>>>>> bit of cmake. But for the time being, can you also show the
>>>>>>>>>>>>> advanced
>>>>>>>>>>>>> options in the cmake configuration window (at least the first 20
>>>>>>>>>>>>> or so
>>>>>>>>>>>>> items). I'd like to see what's happening to the CXX compiler we
>>>>>>>>>>>>> are using.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Friday, July 19, 2024 at 9:44:55 AM UTC+8 Victor Michel
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Ruochun,
>>>>>>>>>>>>>> Here is the screenshot of the cmake configuration. I also
>>>>>>>>>>>>>> added environment variable screenshots in case it is relevant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you again for helping me !
>>>>>>>>>>>>>> Victor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le vendredi 19 juillet 2024 à 00:12:57 UTC+9, Ruochun Zhang a
>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then can you post a screenshot of the cmake configurations
>>>>>>>>>>>>>>> (from ccmake)? Maybe it can help.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thursday, July 18, 2024 at 9:42:51 AM UTC+8 Victor Michel
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Ruochun,
>>>>>>>>>>>>>>>> Thank you for taking time to help me.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I tried what you suggested (re-downloaded everything and
>>>>>>>>>>>>>>>> tried with cmake UI interface), however even when setting the
>>>>>>>>>>>>>>>> option
>>>>>>>>>>>>>>>> *TargetCXXStandard * to *STD_CXX17* (or to any other
>>>>>>>>>>>>>>>> pre-set STD_CXX) I still get the same errors of *Could not
>>>>>>>>>>>>>>>> determine a suitable C++ standard!* and *XXX called with
>>>>>>>>>>>>>>>> incorrect number of arguments*.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you know what might be causing this ?
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Victor.
>>>>>>>>>>>>>>>> Le mercredi 17 juillet 2024 à 18:42:51 UTC+9, Ruochun Zhang
>>>>>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's a bit difficult to reproduce this problem, but if it
>>>>>>>>>>>>>>>>> happens to you, can you try removing everything to start over
>>>>>>>>>>>>>>>>> again, then
>>>>>>>>>>>>>>>>> configuring with cmake/ccmake again, while manually setting
>>>>>>>>>>>>>>>>> the cmake
>>>>>>>>>>>>>>>>> option *TargetCXXStandard *(may be easier to do with
>>>>>>>>>>>>>>>>> ccmake UI) to *STD_CXX17*? Let us know if it does not
>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>> Ruochun
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tuesday, July 16, 2024 at 4:16:06 PM UTC+8 Victor
>>>>>>>>>>>>>>>>> Michel wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am facing a little issue while trying to configure
>>>>>>>>>>>>>>>>>> DEM-E build.
>>>>>>>>>>>>>>>>>> (I'm on Ubuntu 24.02, with CUDA 12.0, gcc-12 and g++-12
>>>>>>>>>>>>>>>>>> installed)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> While configuring with ccmake I get the following :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *[C++STD Autodetect] Detecting level of C++
>>>>>>>>>>>>>>>>>> support... CMake Error at cmake/CxxStdAutodetect.cmake:53
>>>>>>>>>>>>>>>>>> (message):
>>>>>>>>>>>>>>>>>> [C++STD Autodetect] Could not determine a suitable C++
>>>>>>>>>>>>>>>>>> standard! Call
>>>>>>>>>>>>>>>>>> Stack (most recent call first): CMakeLists.txt:103
>>>>>>>>>>>>>>>>>> (cxx_std_autodetect) ==== Configuring Core Components ====
>>>>>>>>>>>>>>>>>> [core]
>>>>>>>>>>>>>>>>>> Generating API version header... [core] Extracting NVIDIA
>>>>>>>>>>>>>>>>>> Jitify
>>>>>>>>>>>>>>>>>> header... CMake Error at src/core/CMakeLists.txt:77
>>>>>>>>>>>>>>>>>> (set_target_properties): set_target_properties called with
>>>>>>>>>>>>>>>>>> incorrect
>>>>>>>>>>>>>>>>>> number of arguments. [core] Generating Runtime Data helper
>>>>>>>>>>>>>>>>>> (build)... [core] Generating Runtime Data helper
>>>>>>>>>>>>>>>>>> (install)... CMake Error
>>>>>>>>>>>>>>>>>> at src/core/CMakeLists.txt:198 (set_target_properties):
>>>>>>>>>>>>>>>>>> set_target_properties called with incorrect number of
>>>>>>>>>>>>>>>>>> arguments. ====
>>>>>>>>>>>>>>>>>> Building DEM Components ==== CMake Error at
>>>>>>>>>>>>>>>>>> src/DEM/CMakeLists.txt:59
>>>>>>>>>>>>>>>>>> (set_target_properties): set_target_properties called with
>>>>>>>>>>>>>>>>>> incorrect
>>>>>>>>>>>>>>>>>> number of arguments. ==== Configuring GPU Algorithm
>>>>>>>>>>>>>>>>>> Components ==== CMake
>>>>>>>>>>>>>>>>>> Error at src/algorithms/CMakeLists.txt:60
>>>>>>>>>>>>>>>>>> (set_target_properties):
>>>>>>>>>>>>>>>>>> set_target_properties called with incorrect number of
>>>>>>>>>>>>>>>>>> arguments. Demo
>>>>>>>>>>>>>>>>>> programs for DEM solver... ...add DEMdemo_Repose CMake Error
>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>> src/demo/CMakeLists.txt:85 (set_target_properties):
>>>>>>>>>>>>>>>>>> set_target_properties
>>>>>>>>>>>>>>>>>> called with incorrect number of arguments. ...add
>>>>>>>>>>>>>>>>>> DEMdemo_Repose2D CMake
>>>>>>>>>>>>>>>>>> Error at src/demo/CMakeLists.txt:85 (set_target_properties):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> set_target_properties called with incorrect number of
>>>>>>>>>>>>>>>>>> arguments.*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And then about 15 more Error with the same model as the
>>>>>>>>>>>>>>>>>> last one :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * ...add DEMdemo_XXXXXXXXXXXXX CMake Error at
>>>>>>>>>>>>>>>>>> src/demo/CMakeLists.txt:85 (set_target_properties):
>>>>>>>>>>>>>>>>>> set_target_properties
>>>>>>>>>>>>>>>>>> called with incorrect number of arguments.*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think I understand that the issue is coming from my C++
>>>>>>>>>>>>>>>>>> compiler. After going through the CMakeCache file I tried
>>>>>>>>>>>>>>>>>> installing g++-11
>>>>>>>>>>>>>>>>>> (I was previously using g++-12) before running the
>>>>>>>>>>>>>>>>>> configuration again but
>>>>>>>>>>>>>>>>>> it didn't solve the issue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If someone has an idea as to how I could solve this issue
>>>>>>>>>>>>>>>>>> it would help me a lot!
>>>>>>>>>>>>>>>>>> Thank you in advance.
>>>>>>>>>>>>>>>>>> Victor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/projectchrono/4d83c5aa-5c2c-4d8d-9a20-e408abad90ffn%40googlegroups.com.
