Compilation of DEM-Engine as a Chrono library

[Gianni Curti]

Hi,

I am trying to compile DEM-Engine as a Chrono library on my pc running a Linux system on Ubuntu 24.10. I have already compiled both Project Chrono (with CUDA toolkit 12.3) and DEM-Engine (with CUDA toolkit 12.6). I am following the instructions given on the website to complete this passage but I am stuck at the point where I have to set the field DEME-DIR. In fact, this field does not appear even though I have put "ENABLE_PROJECTS" to ON therefore I am unable to link DEM-Engine with Chrono.

Could you please give me some guidance about how to resolve the problem?

Plus, do I need CUDA 12.3 or 12.6 to complete this process?

Thank you in advance for your assistance and kindness.

Gianni

[Ruochun Zhang]

Hi Gianni,

Can you post a screenshot of the Cmake UI after you "ENABLE_PROJECTS" and re-generate? If DEME-DIR is not shown, I'd like to know what is shown. Besides, if there is any warning or error in the process, please show them too.

Ruochun

[Gianni Curti]

Hi Ruochun,

first of all thank you for your patience. I did more attempts and in the end, I saw that the problem was due to the fact that I cloned the main branch of chrono-projects. Instead, if I clone the feature/DEME branch the prompt "ENABLE_DEME_TESTS" appears and I can link DEME against Chrono. However, while building the following errors appear.

I left as active only the option to compile the scripts where DEME and Chrono are used together since in Chrono I have only Core, Vehicle and Multicore installed so I didn't want to trigger some kind of error related to other missing modules. To be clearer, these are the screenshots showing CMAKE settings and outputs during configuration.

Thank you again.

Gianni

[Ruochun Zhang]

Hi Gianni,

The error you saw is about an outdated API. UpdateStepSize now needs a number as an argument. I am surprised I didn't spot it when I tried it. It's certainly not a big problem though: I pushed a new version of chrono-project, could you please do a pull and rebuild the project? Thank you for the catch and for testing it!

Ruochun

[Gianni Curti]

Hi Ruochun,

thank you again now everything is working fine!

However, I have another question related to the nvidia driver. For now, I have the 560 version and I have noticed a power cap on my GPU of 35W against the 110W limit specified by the manufacturer. Looking in some forums I understood that the problem may be related to the driver itself, therefore I want to update it. Do you know if this will cause any problem to DEME?

Thank you again.

Gianni

[Ruochun Zhang]

Hi Gianni,

That's good to know. I'd like to note that depending on the model of your GPU and the problem you are running, it could be natural that the actual consumption is a bit far from the power limit. But as you said, it could also be related to the driver. DEME does not touch the driver so I would say if you don't update the driver out of the CUDA installation supported range, then it should be fine.

Thank you,

Ruochun

[Gianni Curti]

Hi Ruochun,

I found that the power cap problem for nvidia GPU has been widely discussed and reported. I found out that one possible solution could be downgrading the driver to 525 version, which is still compatible with both CUDA 12.3 and 12.6 and capable of allowing the user to set the power cap as desired.

Another question that came up to me while compiling a project with chrono and DEME is the following one. As you can see in the image, cmake detects the CUDA version 12.3 which satisfies Multicore. However, I know from the instructions that DEME does not work well with this version. Thus, which CUDA version do you advice to specify to cmake? I tried with CUDA 12.3 and everything seems to work at a first glance but I want to be sure of what I am doing.

Thank you again.

Gianni

[Ruochun Zhang]

Hi Gianni,

For building this Chrono-DEME co-simulation project, it probably doesn't matter. You could try if you can run the smallest demo in it which is the ball drop co-simulation version. If it runs, everything should be fine.

Thank you,

Ruochun

[Dario Mangoni]

Just a side note: I saw that you enabled Multicore and you are playing with CUDA; please mind that USE_MULTICORE_CUDA is currently bugged, at least on Win. 

I have the fix but not yet pushed so if you are trying things around do not get mad with that. 

[Gianni Curti]

Hi Ruochun and Dario,

thank you for your answers.

Now I have solved the problem with my driver and I have the version 550.142 correctly working. However, I am not able to run DEM-Engine scripts anymore since I always have the following problem:

I have also tried to compile again from source DEM-Engine but the problem persists. I attach also the cmakecache in case it helps. I am using GNU 11.5 and nvidia-smi and nvcc --version give the following correct outputs:

Thank you for your kindness.

Gianni

[Ruochun Zhang]

Hi Gianni,

From what I know, the CUDA version shown by nvidia-smi is the maximum CUDA version supported by the current driver. It looks like it does not support the CUDA installation you have (I get flashbacks from our previous posts...). About the error in DEME, it shows the program failed at the first GPU call, when it tried to detect the number of devices the system has. So indeed, there is a high chance that the driver does not work.

I know managing the environment can be frustrating, but if the code ran well before, and you got this after the driver update, then I'd definitely undo the driver update, and see if that can undo the damage and revert the code to a runnable state. After that, I'd start experimenting if I can update the driver to a more preferrable version that supports CUDA 12.6.

Thank you,

Ruochun

[Gianni Curti]

Hi Ruochun,

in the end, I solved the problem by installing again a new driver. This time I picked the version 560.35.03 and everything works again now. However, it is quite surprising for me since before I was working with the driver version specifically recommended by NVIDIA website.

Thank you again for your time.

Gianni

[Gianni Curti]

Hi Ruochun,

sorry again but I have a few more questions regarding DEM-Engine.

First, I am using as template the code "test_DEME_BallDrop_Cosim.cpp". I have created my assembly in project chrono with the motors I need, while for the DEM-Engine part I imported a mesh of a box so that I can apply to all the triangles composing the body some properties using the Wildcards. This would allow me to simulate electrostatic interaction between the body and the particles and other physical effects. This is the part of my code where I deal with it.

However, when I try to run the simulation it exits with the following error:

Have you got any idea about how to solve this problem?

Second, I wanted to ask you an explanation about the difference between the "move" and "InformCentroidPrincipal" functions. I read the online documentation but I am not sure to fully understand their difference. Do they allow to assign to the body's CoM a different position with respect to the geometrical center and to state how the principal inertia axis are oriented with respect to the global frame? If so, then I could specify the principal moment of inertia with "SetMoi" and my body would be fully defined. In case I am completely wrong, is there another way to do this?

Thank for your time.

Gianni

[Ruochun Zhang]

Hi Gianni,

All tracker-related methods can only be used after initialization, meaning you have to call SetGeometryWildcardValues after Initialize(). I know this is self-evident, but just remember the rule of thumb: trackers are used to modify the states (pos, vel...) of the simulation objects, and when you need to modify the states of objects, the simulation world has to be "initialized" first so these quantities exist; while simulation object definitions, such as InformCentroidPrincipal or material property assignments, are in general done before initialization.

As for InformCentroidPrincipal, I realized that the comments for the mesh version of the method have some copy-paste artifacts which I'll fix soon. But I think your understanding is basically correct (with a loose usage of "geometrical center"). I'll write down how I see these methods should be used, and I think your notes regarding the principal axes are equivalent:

These two methods are used w.r.t. the underlying frame you created the mesh with. If you want fewer brain teasers, it's preferable to choose to create the mesh with the CoM of the object that the mesh represents at (0, 0, 0) and its principal frame aligned with XYZ. If you do this, then you never need to call InformCentroidPrincipal or Move. However, if you did not do this during mesh creation, then InformCentroidPrincipal or Move can be used as remedial measures. You can use InformCentroidPrincipal to notify the solver where the CoM and principal frame are in the mesh's own underlying frame (then the mesh will be modified accordingly under the hood). I wouldn't suggest using Move as its name does suggest something ambiguous but it's intended for the same purpose: using it here means rotating and then translating the mesh in the hope that after this, its principal frame agrees with its underlying frame. Whether you call the methods or not, after the simulation starts, the meshed objects' simulation world pos/rot always means the pos/rot of its principal frame.

And it's correct that you can use SetMOI to fully define the object.

Thank you,

Ruochun

[Gianni Curti]

Hi Ruochun,

thank you for the clarification regarding Move() and InformCentroidPrincipal(). Now everything is clear.

Regarding the problem with SetGeometryWildcardValue, I tried to apply your suggestion and also to look at your example "test_DEME_BallDrop_Cosim.cpp", but the problem still persists. I initialized my DEMSolver with DEMSim.Initialize() and then I called the functions that need the tracker of my imported body but every time the variable "lander_tracker" in code the output is "Segmentation fault (core dumped)". Could there be other possible reasons for this behaviour?

Thank you again for your time and patience.

Gianni

[Ruochun Zhang]

Hi Gianni,

I do have a couple of ideas about how this could be, but I'll need a more complete version of the code you are running. Since this is already a different topic, for better documentation of this discussion, could you start a new thread with more complete information on the script you wrote? Also in that new post, please let us know the value of DEME_MAX_WILDCARD_NUM when you compiled DEME.

Thank you,
Ruochun

[Gianni Curti]

Hi Ruochun,

Finally I solved all the problems and the simulation is working.

The first one (which was responsible for segmentation fault each time I called the tracker) was related to the process I used to create the .obj file. Apparently, there was a slightly different procedure to follow in my software and now the object, despite having the exact same mesh as before, is correctly imported.

The second problem was related to the creation of the assembly in Project Chrono. In my original script from Multicore, I used to create it with a function and then fetch the bodies of interest for the main thanks to their ID. Apparently, this causes segmentation fault for some reason, therefore now I generate the bodies directly in the main.

There are another couple of questions I want to ask but I will open another thread as you suggested.

Thank you again.

Gianni