CxxStdAutodetect.cmake Error when configuring DEM-E build

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

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.

[Ruochun Zhang]

Hi Victor,

Then can you post a screenshot of the cmake configurations (from ccmake)? Maybe it can help.

Thank you,

Ruochun

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

Hi Ruochun, 

Here are the screenshots of the advanced options.

Thank you again, 
Victor

[Ruochun Zhang]

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

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

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

[Ruochun Zhang]

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

[Victor Michel]

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.

[Ruochun Zhang]

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

[Victor Michel]

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

[Victor Michel]

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

[Ruochun Zhang]

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

[Dan Negrut]

Following up on what Ruochun suggested, another thing that might come into play is how you define “r”, which shows up in the denominator.

The wheel might sink some, the wheel might have grousers, the grousers might not have identical shape, the wheel might deflect (if deformable), etc.

Dan

---------------------------------------------

Bernard A. and Frances M. Weideman Professor

NVIDIA CUDA Fellow

Department of Mechanical Engineering

Department of Computer Science

University of Wisconsin - Madison

4150ME, 1513 University Avenue

Madison, WI 53706-1572

608 772 0914

http://sbel.wisc.edu/

http://projectchrono.org/

---------------------------------------------

--
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 projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/4d83c5aa-5c2c-4d8d-9a20-e408abad90ffn%40googlegroups.com.