Three-Field-Variation for Nearly Incompressible Hyperelasticity

Hi,

I wrote an example for the so-called “Hu-Washizu” three-field-variation (u,p,J) for nearly-incompressible hyperelasticity. As an example linear hexahedron elements are used for the displacement field u along with constant p and J fields. They can easily be changed to quadratic tetrahedral elements with linear pressure and volume ratio interpolations if that’s preferred.

I’m actually surprised how easy the implementation of this mixed formulation was. I do not have any prior experience with Fenics and I’m more familiar with the “engineering approach of finite elements”. Anyway, I really like how scikit-fem works!

I’ll append the whole lengthy script as an additional answer. I used my own helpers just to learn how it works. Should I change it to make use of skfem.helpers? Could you have a look at the code if I’m using scikit-fem the way it should be? Is it worth to make an “official” example out of that? Or could it make sense to take some parts of the code for more shorter examples?

A thing which could be of interest: I used (an easy to calculate) relative “nodal force residuals” - norm divided by the norm of reaction forces on the boundaries. Although not complicated I think this is not covered in the examples yet. If I remember correctly the checks in the examples are only performed on the incremental values of the unknowns u and no check of the resulting equilibrium norm(f) is done (in example 36).

# get active displacement dofs
dof1  = basis["u"].complement_dofs(dofs)

# reference force as norm of nodals reaction forces at prescribed dofs
f1_ref  = np.linalg.norm(np.delete(f1,dof1))

# check nodal equilibrium for nodal force residuals at active dofs
norm_f1 = np.linalg.norm(f1[dof1]) / f1_ref

The most difficult parts for me were

a) The definition of the degrees of freedom to keep for the additional fields (personally I also did not really understand why this is called I - of course I read the docs section about the I and D keywords):

# obtain degrees of freedom to keep
I = np.hstack((
    basis["u"].complement_dofs(dofs),
    basis["u"].N + np.arange(basis["p"].N),
    basis["u"].N + basis["p"].N + np.arange(basis["J"].N)
))

b) Use the x keyword in the condense function for the boundary condition. Without x (if example 36 was extended to several increments) you have to use really - and I mean really - small increments on ramping up external displacements.

To sum up, I have some questions:

1. Is it possible to export several timesteps into a single XDMF file or do I have to use the native meshio interface for that?
2. How can I export elemental values like the Deformation Gradient or a stress tensor inside mesh.save() in order to visualize it (in ParaView)?
3. Are there any easy speed-ups of the K11 assembly process for hyperelastic material formulations?

More a ParaView specific question, but maybe you know an answer: 4) Is it possible to visualize quadratic elements with curved edges from a scikit-fem exported “XDMF” file in ParaView?

[kinnala]

There are many questions but I’ll start answering one by one.

I have another question: How often is A11(w) actually called in the assembly process of the stiffness matrix for a mesh consisting of linear hexahedrons? Is there any chance of speeding this process up?

As many times as there are entries in the local stiffness matrix. I think (tri)linear hexahedron has 8 basis functions, and now we have vectorial 3D problem, so it should be 24 x 24 = 576 times in total.

We have thought many times about doing the form evaluations in parallel, but unfortunately a suitably general approach has not presented itself yet. Usually in complex forms significant savings can be also obtained by making the form evaluation faster which can be done in different ways. In theory you could also write the form function in some low-level language such as C or Fortran and decorate that. Some POCs did use numba to make the evaluation faster.

Edit: Let me add that the arguments to the form are largish numpy arrays which attempts to reduce the amount of times form gets called.

Edit 2: I calculated wrong; added the correct total number.

[gdmcbain]

In the end it would be great if contique and something like scikit-fem could be coupled. Unfortunately contique is not as flexible as pacopy and it was designed for relatively small problems.

I did take a stab at writing a small natural parameter function for scikit-fem as part of #119: skfem.algorithms.continuation.natural_jfnk. It’s on the shelf for now though, more for difficulties with JFNK in #119 than any shortcomings with it. One feature that I did like in it and would recommend is generating the successive solutions rather than building a list and returning it; this means that they can be postprocessed on the fly and means that the continuation function doesn’t have to worry so much about termination criteria. A generator is also used for an initial value problem #531 in

https://github.com/kinnala/scikit-fem/blob/8f0f0be7290142ac6dafd8a19a909152f17f52ec/docs/examples/ex19.py#L88-L93

which works well with matplotlib.animation.FuncAnimation: the solution is displayed as it evolves rather than at the end.