Hi Juli! ## What the CRM mu(I) model does at/near the free surface
The behavior you're seeing (upper bed disturbed, lower bed uniform) is consistent with how cohesion interacts with the low-pressure region of the bed, which is exactly the near-surface zone. The relevant model mechanics from `doxygen/documentation/manuals/fsi/fsi_mu_i_rheology.md` are: - **Yield limit with cohesion:** `tau_max = mu * p_tr + c`. Cohesion `c` (your `cohesion_coeff`) "adds shear strength at low pressure." The near-surface material is precisely where pressure `p_tr` is lowest, so cohesion changes the constitutive response most strongly there. - **Cohesive tension cutoff:** "if `p_tr < -c/mu_s`, stress is zeroed." With `c = 0`, this cutoff is at `p_tr < 0`. With `c = 299` and `mu_s = 0.61`, it moves to `p_tr < -490 Pa`, i.e. the model now permits tensile stress states before zeroing. This is a fundamentally different near-surface behavior between your two cases. - **Free-surface treatment:** "if flagged (`nabla_r < free_surface_threshold`), stress and pressure are zeroed." So surface-flagged particles have their stress zeroed regardless of cohesion, while sub-surface particles now carry cohesive tensile strength. The transition between these two regimes sits right in your disturbed layer. - **No EOS in CRM:** "EOS is not used in CRM; pressure comes from stress trace." So in a loose bed there's very little confining pressure near the top, amplifying the sensitivity to the two mechanisms above. **So to your first two questions:** yes, a change in near-surface behavior when you introduce cohesion into a loose bed is an expected consequence of how cohesion couples with (a) the low-pressure free-surface region, (b) the tension cutoff `p_tr < -c/mu_s`, and (c) the stress/pressure zeroing at the flagged free surface. It does not by itself indicate that your material construct is wrong. It is genuinely an interaction between cohesion, loose packing (low pressure), and free-surface handling. ## Two things in your setup worth checking 1. **Young's modulus / step size.** Your `Young_modulus = 35.9e6` is ~36× the CRM baseline of `1e6`. The parameter guidance explicitly warns: "increase if response is too soft, but expect smaller stable step sizes when stiffness rises" (`fsi_mu_i_rheology.md`). A stiffness this high with an unchanged `step_size` can produce noisy/unstable behavior that would be most visible in the loosely-confined surface layer. I'd verify your step size is small enough for this stiffness before attributing all the disturbance to cohesion. 2. **How cohesion is applied.** The docs note cohesion can be set either through `mat_props.cohesion_coeff -> SetElasticSPH` *or* via `SetCohesionForce` (`fsi_mu_i_rheology.md`). Make sure you're only setting it one way and that `SetElasticSPH(mat_props)` is actually being called after you assign `cohesion_coeff`. ## Last thought: I encourage you to try the new MCC rheology in CRM, in Chrono 10.0. It works well for soils when there needs to be consolidation. The mu(I) rheology is not great at doing that. I hope this helps a bit. Dan ------------------------------------------------ Bernard A. and Frances M. Weideman Professor NVIDIA CUDA Fellow Department of Mechanical & Aerospace 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/ ------------------------------------------------ From: [email protected] <[email protected]> On Behalf Of JüliMari Sent: Friday, June 5, 2026 1:28 PM To: ProjectChrono <[email protected]> Subject: [chrono] CRM/SPH cone drop with LHS-1: unexpected behavior when adding a cohesion parameter Hello Chrono community, I am working with the CRM/SPH cone drop demo and adapting it for LHS-1 lunar regolith simulant. My research team would like to include cohesion in the LHS-1 material model, but I am seeing behavior that makes me unsure whether I am applying the cohesion coefficient correctly, or whether there is something in the cone drop setup that affects cohesive cases. I ran two loose LHS-1 cone drop cases with the same setup (other than render_fps, to capture as many snapshots as possible). The only change between cases was manually editing the LHS-1 material construct from cohesion_coeff = 0 Pa to cohesion_coeff = 299 Pa. With 0 Pa, the loose LHS-1 bed behaves smoothly during the cone drop and as expected following other CRM research papers. With 299 Pa, the upper region of the bed becomes highly disturbed, while the lower material remains comparatively uniform. I attached snapshots showing the difference between the two cases. The LHS-1 material construct I implemented: struct lhs1_material { double density_max = 1740; // kg/m^3, dense LHS-1 double density_min = 1340; // kg/m^3, loose LHS-1 double Young_modulus = 35.9e6; // Pa double Poisson_ratio = 0.3; double mu_I0 = 0.08; double mu_fric_s = 0.61; double mu_fric_2 = 0.61; double average_diam = 51e-6; // m double cohesion_coeff = 0; // changed manually to 299 for cohesive case }; And for MU_OF_I rheology, mat_props.rheology_model = RheologyCRM::MU_OF_I; mat_props.mu_I0 = mu_i0; mat_props.mu_fric_s = mu_s; mat_props.mu_fric_2 = mu_2; mat_props.average_diam = lhs1_mat.average_diam; mat_props.cohesion_coeff = lhs1_mat.cohesion_coeff; My questions are: is this disturbed free-surface behavior expected when adding cohesion to a loose granular bed, or does it suggest that my setup is inconsistent? Could this be caused by the interaction between cohesion, loose packing density, free-surface handling, and the initial pressure/preconsolidation setup? And is there any hard-coded assumption or scaling in the cone drop (or cone penetration) examples that could make cohesion behave unexpectedly in this case? I can provide the full code file if you need to see it, though I wanted to check first whether this behavior is expected for CRM/SPH cohesion implementation. Undergraduate Student Aerospace Engineering 1 Aerospace Boulevard Daytona Beach, FL 32114 Embry-Riddle Aeronautical University Florida | Arizona | Worldwide -- 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 [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/d/msgid/projectchrono/fd428527-985e-4b60-a7db-0088bf43d482n%40googlegroups.com<https://urldefense.com/v3/__https:/groups.google.com/d/msgid/projectchrono/fd428527-985e-4b60-a7db-0088bf43d482n*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!Mak6IKo!KUCQyXEPDPbuUTMfjCsxxqdA2wyolDpLbA_gOkMouaSBQpaR1-eWpKmpFG1tXRMvcTkB1UuVt7It2XU$>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/projectchrono/DM8PR06MB770318D34AB21657A11B3EA9B1F62%40DM8PR06MB7703.namprd06.prod.outlook.com.
