Support for plastic deformation of FEA elements
Janik Helbig
I'm currently building a multi-body dynamics simulation of colliding/stacking FEA meshes and some rigidbodies.
I would like to give the meshes plastic deformation, so indentations and such are persistent and not fully elastic. From what I can gather from this forum and the source code, the current stable version (10.0) does not support this for most elements, except for some beams and the ChElementHexaANCF_3813_9 element.
Looking at the GitHub, I can see that there has been some work on the FEA module on the development branch recently. It appears there is now more general support for plastic deformation via the field, domain deformation and ChMaterial3DStress* classes?
I would appreciate some clarification on that and whether or not you would consider the new implementation to be at least experimentally usable?
Kind regards.
Dan Negrut
Janik,
Your reading of 10.0 is correct. In the current stable release, plasticity in the FEA module is
available in two places:
1. For volumetric meshes, `ChElementHexaANCF_3813_9` is the one solid element with built-in
plasticity. It supports J2 (von Mises), Drucker-Prager, and Drucker-Prager cap models. See
`demo_FEA_hexaANCF_3813_9.cpp` for usage (it exercises the DP cap model) and
`utest_FEA_ANCFhexa_3813_9.cpp` for the J2 and Drucker-Prager cases.
2. For beams, plasticity comes through the Cosserat section framework:
`ChBeamSectionCosserat::SetPlasticity()` takes a `ChPlasticityCosserat` object (for example
the lumped-plasticity variant), and is used by the IGA beam element.
So for "colliding/stacking meshes with persistent indentation" in 10.0 today, the practical path
is meshes built from `ChElementHexaANCF_3813_9` bricks with one of its plasticity models, plus a
`ChContactSurfaceMesh` for contact against your rigid bodies. Tetrahedra and shells do not have a
plasticity option in 10.0.
On the development branch: you read the code correctly, with one naming update. What you saw as
"domain deformation" classes was recently renamed, `ChDomain*` became `ChFEModel*` (e.g.
`ChFEModelDeformation`).
It is a new multiphysics FEA framework under `src/chrono/fea/multiphysics/`: fields and per-material-point
data, new field elements (tetrahedron-4, hexahedron-8), and a family of `ChMaterial3DStress*`
materials.
Two things to know about its current state:
1. The framework is designed for plasticity, but no plastic material ships yet. The architecture
carries per-material-point state and an end-of-timestep update hook written explicitly with
plastic flow in mind, and the comments sketch how a plasticity law would store its state.
The stress materials implemented so far are elastic and viscous: St. Venant-Kirchhoff,
Neo-Hookean, Ogden, linear viscoelastic and Newton-type viscous damping, and a composition
wrapper for combining models (e.g. Kelvin-Voigt-style behavior).
2. It is experimentally usable for what it implements, with caveats. There are working demos,
including one with contacts (`demo_FEA_multiphysics.cpp`, `demo_FEA_multiphysics_contacts.cpp`,
`demo_FEA_multiphysics_custom.cpp`, `demo_FEA_multiphysics_viscous.cpp`). But it is under
active development with API churn (the rename above happened only weeks ago), it is C++ only
for now (no Python wrapping yet), and anything you build on it should expect to track changes.
If you are comfortable living on the development branch, the `demo_FEA_multiphysics_custom.cpp`
demo shows how to implement your own field/material combination, so an experimental J2-type
plastic `ChMaterial3DStress` following that pattern is feasible; the state-storage plumbing you
would need is already in place. Otherwise, the 10.0 brick-element route above is the supported
way to get persistent indentation today.
One more option worth considering, depending on what your blocks are physically made of: skip
FEA for the deformable parts and model them with Chrono's CRM material (the SPH elastoplastic
continuum in Chrono::FSI that we run vehicles over as deformable terrain). Persistent
indentation is CRM's native behavior, not an add-on: it uses a pressure-dependent yield
(mu(I) rheology with cohesion, or a modified-Cam-Clay option), it is GPU-accelerated, shipped
in 10.0, couples to rigid bodies the same way vehicle wheels do, and unlike the development
FEA work it is usable from Python today (see `demo_VEH_CRMTerrain_WheeledVehicle.py`; the
material is configured via `ChFsiFluidSystemSPH::SetElasticSPH`, and the rheology is documented
in `fsi_mu_i_rheology.md`).
The fit is application-specific, so two honest caveats. First, CRM is a granular/soil
constitutive family: blocks made of it behave like stiff clay or compacted fill (they dent, but
they can also smear, and they carry essentially no tension), so if your parts are metal or
polymer solids that should dent elastoplastically while keeping full structural stiffness, stay
with the FEA routes.
Second, free-standing CRM shapes hold together through cohesion and can slowly creep under
self-weight in long simulations. If your blocks are soil-like and mostly interact with the
rigid bodies, this is probably the fastest path to what you described.
Dan
--
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
projectchron...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/projectchrono/fbbb5cc2-1033-464e-9b0a-d6065834f6c6n%40googlegroups.com.