Weird results with bending beam problem

Hello

I try to simulate the bending beam problem where the beam is fixed (x, y) on one end and the gravity load is applied. I selected the particle at the Gauss point and the particle volume as w*DetJ. The background mesh is structured with element size = 0.5. After running the simulation I observed that the results are not as expected and some particles are sticked to the grid (see attached figure). I attached here the input for my simulation. The json looks fine to me, but I wonder if I set something wrong in the analysis part.
BendingBeam.zip (3.3 KB)

Giang

Hi Giang,

I have checked your mesh file, and I think there is something wrong with the ordering of your connectivity. I run a similar case and it works okay for me (see screenshot below).


Here is my input file:
BendingBeam2D.zip (2.8 KB)

Kind regards,
Nanda

Hi Nanda

I checked my mesh and did not find any problem on the connectivity. Nevertheless, there is topological difference between your mesh and my mesh. In my mesh, the element connectivity has different configuration

(1)
3—2
| x |
0—1

or

(2)
2 --1
| x |
3 --0

^ Y
|
0—> X

or cyclic permutation of (1)

In your mesh, only the first configuration appears. In fact if I adapt my mesh to use the first configuration and it runs fine. In addition, it does not run with other configuration. May I know if that is the implicit constraint for the input mesh?

Hi @vryy

As the documentation mentions, the code is based on gmesh ordering. This is exactly like what you show in the congifuration 1 above.

In addition, it does not run with other configuration.

I would have guessed that using any single anti-clockwise permutation of

3 — 2
| x |
0 — 1

for all cells in your mesh would be fine. When you mention that the code does not run with other configurations, were you trying a single configuration for all cells or mutliple configures within your input file?

Hi @jgiven100. In my thinking, I assume gmsh ordering defines counter-clockwise but does not fix to the first configuration. In the test I tried only a single configuration for all cells and all is failed except the first configuration. I could upload the mesh to double check if necessary.

@vryy Thanks for checking all of the configurations. No need to upload - I trust these results!

While making my own meshes, I’ve always made sure to have the numbering increase CCW; I must’ve gotten lucky and coincidentally put the 0 node in the bottom left position :slight_smile:

@vryy Alternative solution is to set

"isoparametric": true

within the "mesh" section of the input JSON. I am able to get your original mesh file to produce good results. Additionally, any rotation of a single CCW configuration is working for me with the isoparametric setting enabled. See below:

One thing I didn’t catch before is that you will want to set

"velocity_update" : false,

Here is a discussion of that setting for a different benchmark test:

Thanks @jgiven100 for the solution. That’s exactly I’m looking for.

1 Like