Particle outside mesh domain when changing material model

Hi folks,

I’m getting some strange behavior when changing the inputs for the sliding block example in mpm-benchmarks/2d/sliding_block_inclined_boundary. I’m just changing the boundary conditions and material properties in mpm.json, but leaving everything else the same. When doing that, I get MPM main: Particle outside the mesh domain before a single step is run which seems like it would be related to the domain initialization

The material is changed from LinearElastic2D to MohrCoulomb2D and the boundary conditions are specified as 0 velocity in the x and y along the sliding plane. There is also a friction boundary along the sliding plane.

I’ve attached the associated input files. Other than mpm.json, they are identical to the sliding block example.

Am I messing up the inputs or is this perhaps something else?

inputFiles.tar (30 KB)

Hi @shellshocked2003 - thanks for bringing this up. I’m able to reproduce the same error when updating LinearElastic2D to MohrCoulomb2D.

Starting with the input files you attached, if I update cohesion to something small like

  "materials": [
      "cohesion": 0.1,

I can get the model to run and see the block sliding. My guess is that some particles are shooting out of the mesh domain without a bit of tensile strength in the constitutive model (?).

@thiagordonho and @kks32 have been working on updating the code’s contact algorithm in general, but the feature hasn’t been merged into develop yet. This feature branch might give better results than the develop branch at the moment - Thiago and Krishna will know for sure.

Also, I noticed the MC parameters include "porosity": 0.3. This shouldn’t affect the output at all, but the MohrCoulomb2D won’t use this value.

Thanks for the quick response @jgiven100! I’ll mess around with the parameters a bit and try out the feature branch too.

One thing I notice though is that it still behaves like a sliding block even when the friction angle is very small–see the attached mpm.json. With a friction angle this small, I’d expect the block no longer to stick together but to fall apart. I could be missing something here in how I’m inputting parameters–I’m just starting to play around with the software–but I’d expect the block to just collapse and the particles to slide downslope in this case.

inputFiles.tar (30 KB)

Using both "friction": 40 and "friction": 2, I looked at an even simplier column collapse problem keeping the analysis inputs the same as the block problem. Below is the output after 100,000 steps (L-> phi=40, R-> phi=2).

Considering the big shift in friction, the difference is pretty subtle, so it seems like we need >>100000 steps to see the block fall apart.

Perhaps the combination of dt, nsteps, length of slope, angle of slope,… isn’t quite right to capture the block falling apart. I’ll think about this more.

Cool, thanks @jgiven100. I see what you’re saying, though what is keeping the material together then? If the friction is near zero and there’s negligible cohesion, why doesn’t the column collapse? If you think about a column of sand like you have in your example, it would collapse into a cone with slopes at approximately the friction angle. Seems like there is some cohesive/tensile resistance coming from something else.

See what I mean?


I just had a look at these input files and noticed you’ve set line 23 as:

“friction”: 1.0"

This corresponds to a very high friction coefficient between the points and the boundary which could be preventing the material from spreading outwards and collapsing.

Can you try setting this to a lower value, say 0.1?

I just looked at the code, and I think there is a bit of mismatching of using the naming "friction" in the .json file.

The "friction" below denotes the coefficient of friction at the boundary \mu as in image

"friction_constraints": [
            "friction": 0.5

The second "friction" written in the Mohr-Coulomb material parameter refers to the typical angle of internal friction \phi expressed in degree. The reasonable value for sand will be around 30.

"materials": [
  "id": 0,
  "type": "MohrCoulomb2D",
  "friction": 34,
  "residual_friction": 30,


In fact, the two frictions are related by \mu=\tan(\phi) as we all know. I am not sure that this solve your problem Mike @shellshocked2003.

If you think about a column of sand like you have in your example, it would collapse into a cone with slopes at approximately the friction angle.

Completely agree. From playing around a bit more with the sand columns, it seems to take clock time >>10 seconds to reach an equilibirum state. I imagine real sand wouldn’t need this much time. I’m not quite sure why the MohrCoulomb2D deformation under self-weight occurs “slow”, but in terms of the sliding block, the material reaches the end of the ramp much faster than collapse occurs.

@jgiven100 @shellshocked2003 I think the dissipative behavior is caused by the flag "velocity_update": true. Could you please change that to "velocity_update": false?

1 Like

I think the dissipative behavior is caused by the flag "velocity_update": true . Could you please change that to "velocity_update": false

Great catch! Thanks @bodhinandach

Ah, thanks Nanda @bodhinandach! Appreciate you looking into that. Also, thanks @jgiven100 for your help with this.

@cw646, the high value for mu was to see if having more friction along the base could help slow the block down as it slid so there was more time for it to fall apart.

Thanks again!