DEMdemo_Wheel and DEMDemo_WheelDP_simplified

64 views
Skip to first unread message

sumaya

unread,
Oct 28, 2025, 4:48:40 PMOct 28
to ProjectChrono
Hi,

I wanted to understand the exact differences between the WheelDP executable and the WheelDP_simplified version.

From my experience:

WheelDP_simplified simulates a relatively small number of particles (for me, it generated around 26K particles).

WheelDP simulates a very large number of particles (for me, it generated around 4.68 million particles).

My understanding is that the WheelDP version uses GRC-1 simulant, while nothing specific is mentioned for the simplified version, except that the number of particles is based on the simulation box size and then scaled. Could you please clarify what other differences exist between these two executables?

For my research, I want to simulate 6 mm particles (around 300,000 particles in total) for a drawbar-pull test. The particles will be spherical clumps of 2(not three), and the simulant should preferably be lunar simulant (GRC-1). Which executable would you recommend for this scenario: WheelDP or WheelDP_simplified?

Additionally, I want to confirm that for the WheelDP test, it takes wheel rotational speed and horizontal velocity as inputs and provides drawbar-pull force as output. Could you please verify this?

If I choose to use the WheelDP executable, where should I modify the particle size, and do I also need to modify the particle numbers in the GRC-1 and GRC-2 files?

Thank you for your guidance.

Best regards,

Ruochun Zhang

unread,
Oct 29, 2025, 12:43:10 PMOct 29
to ProjectChrono
Hi Sumaya,

I think you’ve essentially already described the difference between DP and DPSimplified. Running the full DP demo is a major task. It requires a prerequisite run and is computationally expensive. I created DPSimplified to provide a more accessible drawbar-pull example. In this version, the particles are larger, resulting in fewer total particles and faster runs. This terrain representation still captures the overall terrain response characteristics similar to GRC-1.

Regarding your comments on the types of simulations you want and where to begin, I’d like to clarify that it’s not about creating two-sphere clumps and hoping that they somehow represent GRC-1 in the simulation. Rather, you need to construct a terrain representation that meets your specific needs and then verify that it does. With that said, you can start with WheelDP. It’s smaller, easier to modify, and overall simpler to work with. However, keep in mind that you cannot easily modify the checkpoint files if you use WheelDP. These files contain pre-settled particle beds, and naively changing particle sizes will lead to inconsistent scenes (e.g., large overlaps if particles are enlarged), which will cause divergence in subsequent simulations. If you wish to change particle shapes or sizes, you must modify the initial configuration, re-run the settling process to generate new checkpoint files, and then use those. Also note that you don’t change particle sizes within the checkpoint file; you do so in the clump template within your test scripts. Of course, you could write a custom script that reads particle sizes and shapes from an external file; that’s entirely up to you. DEM-Engine is a core solver, not a tightly constrained end-user application yet.

Lastly, for the DPs test, I wouldn’t call those parameters “inputs.” It’s simply a test designed to measure the drawbar-pull ratio of a wheel shape, given predefined wheel angular velocity and slip ratio (TR).

Thank you,

Ruochun

sumaya

unread,
Nov 11, 2025, 11:07:50 AMNov 11
to ProjectChrono

Hi Ruochun,

Thank you for the clarification. Currently, I am using WheelDPSimplified and have the following follow-up questions:

  1. Clump Input Data: The input file "clumps/triangular_flat.csv", does it specify the positions of the particles as x, y, z coordinates? I am interested in generating a two-sphere clump with a radius of 0.006 m, so I would have two lines in the CSV specifying the two spheres. Were the x, y, z positions in the existing file randomly assigned? Do you have any suggestions for generating two-sphere clumps? Also there has been some scaling in the script, is there any suggestions how to keep radius same with or without scaling.?

  2. Volume Calculation: In the script, the variable float volume1 = 4.2520508 is defined. I tried deriving the volume using the values provided but did not get the same result. Since the existing script has a three-sphere clump where the spheres are fused, there could be some volume loss. Was that accounted for in your calculation, and if yes, could you explain how you arrived at this volume?

  3. Wheel Geometry: I want to verify if the line float total_pressure = 200.0; corresponds to the load applied to the wheel in Newtons. Could you kindly confirm this?

  4. Soil Bed and HPC Sampler: My soil bed size is 0.90 × 0.204 × 0.31 m, and I want to simulate the entire region. My understanding is that the size is defined in this part of the code:

// `World': soil bed size float G_mag = 9.81; float step_size = 5e-6; double world_size_y = 1.; double world_size_x = 2.; double world_size_z = 2.;

However, I am not sure what the HPC sampler section does. Could you describe how you chose the following constant parameters?

float sample_halfheight = 0.25; float sample_halfwidth_x = (world_size_x * 0.95) / 2; float sample_halfwidth_y = (world_size_y * 0.95) / 2; float offset_z = bottom + sample_halfheight + 0.03;

Thank you very much for your help.

Best regards,

Sumaiya

Ruochun Zhang

unread,
Nov 12, 2025, 8:45:00 AMNov 12
to ProjectChrono
Hi Sumaiya,

1. Yes. And also their radii r. And the implicit origin of the xyz coordinates you give will be CoM (unless you later change that via InformCentroidPrincipal). They are not randomly assigned, but used to form a certain clump shape that I need. I don't have specific suggestions on how you do that, other than you should visualize it in the process of making it. I don't quite get the scaling part of the question. If you worry about the scaling in the script, set that to 1 or don't set it at all, then the clump template you load will be the same as what the file defines.

2. In short, the volume is the "true" volume, not the naively added sphere component volume. I created the particle in Rhino7, as a union of 3 sphere primitives. Then I used Rhino7 to calculate the volume of it. I mean, using a CAD tool like this is the easiest way if your clump is complex. But for a two-sphere clump, I don't see any difficulty calculating analytically the true volume, taking into account the overlap.

3. Yes. The implicit unit system is SI in all demos. In the case you mentioned it should've been better named as total_effective_weight, I admit.

4. The "world size" usually means the size of the simulation world. DEME cannot handle XYZ that is not bounded by that. So usually, it is safe to just make it "large enough." Here I made the sampling region (the space that the particle-creating sampler tries to fill) a bit smaller than the world size so everything is spawned within the world, hence the constants you saw. You could also make the world size much larger than your soil bin size, but in that case you'll have to manually add plane boundaries to contain your particles, unlike here, I just lazily used the boundary (added by InstructBoxDomainBoundingBC("top_open", mat_type_terrain)) that comes with the world's edge.

Thank you,
Ruochun

Reply all
Reply to author
Forward
0 new messages