GEOS-DEV / GEOS

GEOS Simulation Framework
GNU Lesser General Public License v2.1
222 stars 89 forks source link

Multi-elements mesh simulation does not converge using Solidmechanics solver #1824

Closed alexandrebtessael closed 1 year ago

alexandrebtessael commented 2 years ago

Hello. I tried to use imported meshes in GEOSX to perform geomechanic simulations based on the Solid mechanics solver "SolidMechanicsLagrangianSSLE". I'm using the Beam Bending approach following the example provided here : https://geosx-geosx.readthedocs-hosted.com/en/latest/docs/sphinx/tutorials/step04/Tutorial.html These meshes are composed of 3 types of volume elements (4 nodes tetrahedra, 5 nodes pyramids, 8 nodes hexahedra) and the dimensions of the meshes are between (0, 0, -1) and (1, 1, 0). In the middle of the meshes, a fault is introduced.

My first test was on a 1_layer.msh and I managed to obtain the similar behaviour as presented in your example. But I tried this test again with a cube_5x5x5.msh and here, I faced a convergence issue (see screenshot below). All the parameters in both these tests are the same except for the mesh imported. I defined regions where to apply the boundary conditions in both meshes using the "PhysicalNames" in the msh files. I already used this kind of multi-elements meshes in flow simulations and I had no problem so I believe the mesh is not the issue here.

image

Could you please have a look at this issue (the link of the files is provided below with both meshes and xml files) because I can't find a solution using the documentation nor the issue tracker. Thank you and have great day.

The link to the files is : https://filesender.renater.fr/?s=download&token=68f928fc-eb1a-461e-a228-be5fde71a457

jhuang2601 commented 2 years ago

@alexandrebtessael This is related to the mesh quality. By checking the mesh with cube_5x5x5.msh, it shows that the outer boundaries are not flat surfaces anymore and aspect ratio of some elements are pretty bad. image

Although the case with 1_layer.msh can be running, unexpected displacement and stress can be observed after initialization (at t=0), which should be avoided: image image

I would suggest to refine and improve your mesh.

alexandrebtessael commented 2 years ago

Hello. I have followed your advice and I improved the mesh quality. I flattened all of the boundaries of the 1_layer.msh (now 1_layer_v2.msh) but I still have the same issues has you mentionned above. Concerning the aspect ratio, there was no modification. I double-checked the regions where I applied my boundary conditions but evrything is fine so I still don't understand why the gradient of total displacement is non linear along the X-axis (or close to). Could you please help me on this issue.

The new files can be download here : https://filesender.renater.fr/?s=download&token=c6091704-3dd3-48e5-a2ea-b71f6661afef

jhuang2601 commented 2 years ago

@alexandrebtessael Hello, by checking your xml files and simulation results, the observed issue is related to the event loop, where there is some ambiguity in terms of the current time. It is better to move the outputs event to the beginning of the loop. This way, the first time step in the vtk files corresponds to t=0, as expected.


 <Events
    maxTime="10.0">

    <PeriodicEvent
      name="outputs"
      timeFrequency="1.0"
      target="/Outputs/geomeca_1_layer"/>

    <PeriodicEvent
      name="solverApplications"
      forceDt="1.0"
      target="/Solvers/lagsolve"/>

    <PeriodicEvent
      name="restarts"
      timeFrequency="1e99"
      targetExactTimestep="0"
      target="/Outputs/restartOutput"/>

  </Events>

By doing so, the total displacement fields (stresses as well) are zero after initialization (at t=0, see below): image