DEM_wheelDP_simplifed_low DP forces at 50%slip

94 views
Skip to first unread message

sumaya

unread,
Apr 6, 2026, 12:43:01 PMApr 6
to ProjectChrono

I am currently trying to prevent wheel sinkage by modifying the wheelDP script with a new set of parameters. I have attempted to set the wheel's Z-position to match the existing script; however, the wheel still sinks as soon as the load is applied.

For this simulation, I am using a 2-sphere clump to model the soil particles, and my reference max_z is slightly higher. Most importantly, I am observing low drawbar pull (DP) forces, including negative DP forces at 50% slip, which I believe is unexpected for a 50% controlled slip scenario. I have attahced some important plots to examine.

Given your expertise, I would greatly appreciate it if you could  provide some feedback or suggestions. I have attached the script for your reference.

Thank you for your time and assistance.

1. Chrono existing wheelDPSimplified plot (DP force vs simulation time of 6 sec at 50% slip)---->Attached image named Chrono

2. Modified wheelDPSimplified plot (DP force vs simulation time of around 6 sec at 50% slip)

3.Paraview version modified wheelDP version

4.Code: modified, wheel parameters, x,y world dimensions, scaled down the two clumps to get a specific radius, added two extra families(goal to settle the wheel gently). The z world size has stayed the same, modified the mesh file for the wheel.

Sincerely,

Sumaya

paraview.JPG
code.txt
small_gantry.JPG
chrono.JPG

sumaya

unread,
Apr 6, 2026, 5:23:59 PMApr 6
to ProjectChrono
Also can you please explicitly explain the max_z parameter used in the wheelDPSimplified script. Thanks.

Ruochun Zhang

unread,
Apr 7, 2026, 2:24:09 AMApr 7
to ProjectChrono
Hi Sumaya,

I don't think this is that unexpected based on your description. 

About wheel sinking: It seems that neither your script nor the demo DPSimplified enforces the z coordinate of the wheel, so sinking is expected. It seems that you thought that setting the coordinate using the tracker would fix the wheel's location forever, and that's definitely not the case. This set was done once to put it at the correct initial location, and then the wheel is still affected by the physics, and it should indeed sink when the load is applied.

About drawbar pull: I'd rather conclude from the chart that when the simulation stabilizes, the average DP force is low and close to zero. To me it's quite expected for a smooth cylindrical wheel. I usually imagine the physical scene represented by this simulation as a smooth, metal cylinder rolling on a pile of also smooth and spherical glass beads with high slip, and the propulsion you'd expect to get from them is low anyway. If not for the enforced slip I'd imagine the wheel should just spin in place. The demo, on the other hand, uses a wheel with grousers and that is very different and should give significant propulsion. In this type of simulations usually the geometric locking contributes to the force much more than other effects. That is not to say you should arbitrarily add some sources of geometric locking to "resolve the problem"; you should still reproduce the actual physics you are after.

The variable max_z simply records the max z coordinate of the granular material, so that when we set the wheel's initial location, we put the wheel just above the terrain and do not let the wheel have initial penetration with the terrain. After that, the wheel drops to the material and sinks, and max_z has nothing to do with all these.

Thank you,
Ruochun

sumaya

unread,
Apr 30, 2026, 4:37:31 PM (8 days ago) Apr 30
to ProjectChrono
Dear Ruochun,

Thank you for your detailed comments. I hope you are doing well.

I have some follow-up questions regarding my recent simulations as I work to match our physical lab setup using glass beads.

First, I am encountering issues when attempting to use the physical properties of our experimental materials. While our glass beads have a Young's modulus of 65 GPa, I am unable to exceed 35 GPa in the chrono_demo_wheelDP_simplified script without triggering a DEME error. I encountered the same error when increasing the friction coefficient (mu) from 0.5 to 0.6 while keeping the rest of the parameters as as below. The error message indicates that the system's maximum velocity exceeded the allowance, which suggests potential divergence. Since these values are derived directly from our experimental setup, is there a specific reason why adjusting these parameters consistently triggers this DEME error?
    auto mat_type_terrain = DEMSim.LoadMaterial({ {"E", 3.5e10}, {"nu", 0.245}, {"CoR", 0.296}, {"mu", 0.5}, {"Crr", 0.01} });//glassbeads (currently working in the script with this parameters)  

DEME Error message:0x0000024873c6c370 {pPagerToMain=0x00000248662228e0 {userCallDone=false mainCanProceed={...} cv_mainCanProceed=...} ...}
+ error_message 0x000000b0c08fe540 "System max velocity is 78.01013, exceeded max allowance (35).\nIf this velocity is not abnormal and you want to increase this allowance,
use SetErrorOutVelocity before initializing simulation.\nOtherwise, the simulation may have diverged and relaxing the physics may help, such as decreasing the step size and modifying material properties.\nIf this happens at the start of simulation, check if there are initial penetrations, a.k.a. elements initialized inside walls." char[1024]
+ out "System max velocity is 78.01013, exceeded max allowance (35).\nIf this velocity is not abnormal and you want to increase this allowance, use SetErrorOutVelocity before initializing simulation.\nOtherwis... std::string

I am interested in learning more about how the standard maximum system velocity value is determined. Specifically, what threshold is used to identify when a value indicates an error? Additionally, does this value change based on the wheel and granular particles involved, or is it an internal DEM physics concept?

Second, I have modified the wheel diameter and weight while keeping the wheel angular velocity at w_r = math_PI / 4. Given these structural changes to the wheel, do you believe this velocity setting may now be too high for the simulation to possibly contribute to low DP?

Finally, I have attached the plots for dynamic sinkage and DP at 50% slip for both mu=0.5 and mu=0.6 (where the simulation failed), alongside the original script results(dynamic sinkage). The sinkage in the improved script does not appear normal, and I have been unable to identify the underlying cause.

I would greatly appreciate any feedback or insights you have based on these plots. 



Best regards,

Sumaya

Dynamic_Sinkage_mu=0.5.JPG
DP_1_mu=0.5.JPG
Dynamic_Sinkgae_orignal.JPG
Dynamic_sinkagge_mu=0.6.JPG
DP_2_mu_0.6.JPG

Ruochun Zhang

unread,
May 1, 2026, 4:46:57 AM (7 days ago) May 1
to ProjectChrono
Hi Sumaya,

The questions you have here are all DEM simulation questions rather than DEME questions. DEM questions are research-dependent and you should know them better, and I only have general experience.

First is that the error-out velocity selection is purely a solver thing, not related to physics. It's there for you to set a velocity value that you think would be high enough to never be in the simulation, so the solver errors out when the physics diverges and (typically) leads to high bursts of velocity, lest you waste time waiting for a run that already went kaput. That's everything it does, no physics involved. 35 may be a bit on the lower end for your use case, but I see it mostly served its purpose in your tests.

Note that most DEM research uses reduced Young's modulus, rather than true material values. Whether that is valid depends on the use case, but for off-road mobility simulations, even vastly lower E wouldn't affect the physics of interest that much, usually. You have to test it but I guess you can even get away with something like 35MPa (1/1000 of yours), which enables you to have a much more stable simulation, or get away with a larger time step size. With your 35GPa stiffness, the time step size needed to keep the simulation stable may be much smaller, and I doubt if you are using such. In short, simulations are generally not set up exactly the same as the real world and figuring out a setup that sufficiently captures the physics you are after is the task, and for a research solver that gives you all the freedom, you find the balance yourself.

I can help quite little with your other questions. I can say both are a "maybe". But once you are able to reliably run simulations from start to end, it should be easier for you to figure out the cause. One thing I'd note is that two-sphere clumps being weak in supporting wheels may be expected, as geometrically it still have a tendency to roll sideways, whereas tri-sphere clumps don't. You could add rolling resistance, or otherwise modify the material or shape configurations, but what you actually do, again, depends on what this simulation aims to capture. (What ground? What physical test baseline?)

Thank you,
Ruochun

Reply all
Reply to author
Forward
0 new messages