Run the repose demo

[Yves Eric Maxime Robert]

Hello everybody,

I am new to Chrono, but would want to run a simulation which should be very close to what the repose demo found in Chrono::GPU, to the exception that I need some recent additions to the code, so I have to use the feature/GPU branch. So everything that follows is with that branch.

I already compiled Chrono following the tutorial for Windows in the past and could run several demos. But having now access to a NVIDIA GPU, I installed CUDA and additional dependencies, and followed the instructions again. I saw that OpenGL was important to have to be able to run this repose demo, so I also compiled it. Here is how my CMake window looks:

It  got built well on VS2022, with all succeeded and 1 skipped.

With that, I can run all demos with their executables (IRR, Postprocess, ...), except for the GPU ones. The ball drop one shows a terminal with values and outputs files, and that's the only one. The rest just crashes with no output as soon as I click on the executable. 

My guess was that I do not have the granular module enabled, and from the documentation I need that. However, I cannot find it, and cannot find how to install it. 

Could you please help me figure that out? 

Thank you,

Yves

[Ruochun Zhang]

Hi Yves, 

You should enable Chrono::GPU module. It's the GPU-based physics module and right now it is Chrono's dedicated granular simulator, those demos need that.

Thank you,

Ruochun

[Yves Eric Maxime Robert]

Hello,

Sorry about that, I must have unchecked the box when taking the screenshot.

The compilation has been done with the GPU module, which is why I have access to the GPU demos.

Do you have an idea of why it does not work?

Thank you,

Yves

[Ruochun Zhang]

Hi Yves,

Most likely the environment is the problem and it can be the tricky one. You are running on Windows, not WSL, right? Also, maybe you should show your "Advanced" options so we have an idea about how your CUDA environment/paths are set.

Thank you,

Ruochun

[Yves Eric Maxime Robert]

Thank you for your answer.

I have been trying to use WSL for days, but it never worked. So I proceeded to a clean installation with Windows, following the instructions of the website, using the same software (SourceTree, CMake, VS2022). I installed CUDA as well.

Here is a zipped folder containing all the advanced CMake information.

Thank you for your help,

Yves

[Yves Eric Maxime Robert]

Sorry for the multiple messages, but I figured it might be good for you to have access to my build logs. Here is the one with Debug, knowing that I get the same results and output with the Release one.

Thanks,

Yves

[Ruochun Zhang]

Hi Yves,

If you just double-clicked the executable and found the prompt closed shortly after launching, then you should instead use a Windows-based command line terminal to run them (Powershell?). This will allow you to see the output/error message.

Remember you'll typically have to supply a JSON file as an input argument, something like ".\demo_GPU_repose.exe demo_GPU_repose.json". You should try that from a terminal. That's the only suggestion I can infer from your description.

Thank you,

Ruochun

[Yves Eric Maxime Robert]

Hello,

I indeed double-clicked. Now, with the Powershell, providing an input file as argument (exactly what you provided in your answer), it outputs some text, and creates a windows that freezes instantaneously, and nothing happens after that (Not responding).

The output I get is the following:

Reading parameters: ../data/gpu/demo_GPU_repose.json
--- Parsing JSON ---
params.sphere_radius 0.100000
params.sphere_density 2.800000
params.box_X 40.000000
params.box_Y 40.000000
params.box_Z 40.000000
params.time_end 10.000000
params.grav_X 0.000000
params.grav_Y 0.000000
params.grav_Z -980.000000
params.normalStiffS2S 100000000.000000
params.normalStiffS2W 100000000.000000
params.normalStiffS2M 100000000.000000
params.normalDampS2S 1000000.000000
params.normalDampS2W 1000000.000000
params.normalDampS2M 1000000.000000
params.tangentStiffS2S 100000000.000000
params.tangentStiffS2W 100000000.000000
params.tangentStiffS2M 100000000.000000
params.tangentDampS2S 1000000.000000
params.tangentDampS2W 1000000.000000
params.tangentDampS2M 1000000.000000
params.static_friction_coeffS2S 0.750000
params.static_friction_coeffS2W 0.750000
params.static_friction_coeffS2M 0.750000
params.rolling_friction_coeffS2S 0.000000
params.rolling_friction_coeffS2W 0.000000
params.rolling_friction_coeffS2M 0.000000
params.cohesion_ratio 0.000000
params.adhesion_ratio_s2w 0.000000
params.psi_T 32
params.psi_L 16
params.output_dir repose
params.write_mode csv
params.step_size 0.000002
--------------------
Added 60761 granular material points
Added 45030 fixed (ground) points
In total, added 105791
Version: 3.3.0
NVIDIA Corporation : NVIDIA GeForce GTX 1050/PCIe/SSE2 (3.3.0 NVIDIA 512.96)
 >> GLSL: 3.30 NVIDIA via Cg compiler
 # of shapes : 1
240 240 0 240
 # of shapes : 1
26 26 0 36
 # of shapes : 1
74 74 0 144
 # of shapes : 1
49 49 0 72
Initialize Viewer : GL_INVALID_ENUM
frame step is 0.0333333

This happens with both Release and Debug, with the exact same output.

I feel I am close to the solution. Is it anything you experienced in the past?

Best regards,

Yves

[Ruochun Zhang]

It's probably running, you can check if there is an output folder created and if there are output csv files inside it. I usually disable runtime visualization for GPU scripts, it tends to be too large to be done efficiently. For GTX1050 on Windows, I am not sure but maybe several hours' runtime can be expected, if you are to finish the entire demo.

Ruochun

[Yves Eric Maxime Robert]

It is actually running, just very slowly! 

However, I still have some questions. Since as you said my GPU is not the most efficient, I modified the JSON file and multiplied the radius of the particles by 10.

It should lower the number of particles by a lot and make the runtime visualization feasible. And it does, as the first screenshot shows (still not responding as soon as I click on it though...). 

However, the time for an iteration is the same as if I did not change the radius, meaning that it takes more or less 5 minutes per time step.

I do not really understand, as I would expect it to be very fast with several tens of particles. Do you see a reason for that?

Also, I have been using Paraview for visualization of the particles (is it what Chrono users usually use?) and got the result shown on my second screenshot.

What are these points at Z=-10?

Thank you for your support, I really appreciate it.

Yves

[Ruochun Zhang]

Hi Yves,

For the question regarding the performance, I am not completely surprised, because for smaller problems (less than something like 10k particles), various overheads dominate the runtime (such as the overhead for launching kernel functions), so the total runtime is probably not sensitive to the problem size. Only for larger problems it shows a linear scaling. However on the other hand I do expect *some* time savings if you shrink the problem size by a factor of 100~1000. If you meant the runtime did not change at all after you enlarge the particle size by 10 times, then probably you are somehow completely I/O bound, and it may be related to that you are using runtime visualization, since host--device communication is a big overhead. And by the way, 5 minutes for a frame may be possible, but 5 minutes for a *time step* is not normal, but I assume you meant frame.

Paraview is a common choice for visualization. If you apply Glyph(sphere) filter to the particles with correct radius, you will see the particles at around Z=-10 are hexagonal close-packed and fixed. We use them to represent a ground that has some geometrical roughness.

Thank you,

Ruochun

[Yves Eric Maxime Robert]

Hello,

I think now I understand, thank you for the thorough explanation.

I will run the code for few steps slowly increasing the number of particles and reporting the runtime per step to see when the scaling becomes linear. 

I guess I had not timed the code execution up to now, so removing the runtime visualization might have helped a bit.

I indeed was talking about a frame, that is a mistake I make a lot, my apologies for not being clear on this point.

Thank you once again for your helpful answers!

Yves

[Ruochun Zhang]

Hi Yves,

For sure you can have a couple of timing tests on your own, they should help you get familiar with using this package. If you just wish to have a general idea on the scaling though, we have a paper on this package for your reference https://www.mdpi.com/2227-9717/9/10/1813.

Thank you,

Ruochun

[Dan Negrut]

Also, Yves, make sure you run the timing analysis for C::Granular in Release mode.

Finally, if you do run this timing analysis for your problem, please post it here on the forum for all of us to learn from  it.

Good luck, and thanks.

Dan

 

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

Bernard A. and Frances M. Weideman Professor

NVIDIA CUDA Fellow

Director, Wisconsin Applied Computing Center

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/5f81a800-6920-493a-be06-6f6b1dfbe0bfn%40googlegroups.com.

[Yves Eric Maxime Robert]

Hello,

I ran this weekend some tests with the repose demo.

In these tests, I was just varying the number of particles by changing the size of the particles (from around 0 to around 1,000,000) and running for 10 steps.

Of course, it is specific to my computer (GTX1050 on Windows), but it shows the linear scaling that was already shown in the paper.

At first, the overhead of around 100s is largely dominating, but each particle adds ~8ms so each 1,000 particles adds 8% of this base time for me.

There are two files, the first one (times) has all the steps and numbers of particles, and the second one plots the average (with std) of the times spent as a function of the number of particles simulated.

Best regards,

Yves

[Dan Negrut]

Yves – thanks for following up on my kind request and sharing the results of your experiments. For all purposes, this is confirming that you see the same behavior that Ruochun mentioned in a previous email and has been reported in this paper (Fig. 15).

Thanks, Yves!

To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/77ca6365-18ff-4e02-b4f1-62718df6c6a5n%40googlegroups.com.