Interface definiton of `Problem`

[TTitscher]

We currently have only one LinearElasticity problem. With future implementations in mind, it is helpful to clearly define the methods and attributes for other code to rely on. This could mean

• a displacement field is always called problem.u
  • and (as a proposal) its function space is problem.u.function_space() and not explicitly stored
• strain and stress forms are accessible via problem.eps and problem.sigma (and not problem.strain, problem.stress)
• there is a problem.setup that creates functions and forms. When and how (automatically/manually?) is that called?
• inherit from dolfin.NonlinearProblem or not?
• ...

[eriktamsen]

I agree, we would need a problem definition. My answer to this has some overlap with #20, as I need to control two (or more) separate fields. I will try to answer some of Thomas questions:

• I like the current implementation of the setup, generating first an experiment, then initializing the problem, which calls the setup.
• I would not inherit the NonlinearProblem for our problem, but rather be "one level above" and have the possibility to setup the solving procedure.

I have a question regarding eg. problem.sigma. In my specialized but for me highly relevant example sigma is not a normal function but includes a quadrature point field. Can we handle this in a consistent way?

[joergfunger]

Isn't sigma (even in the standard case ) defined on the quadrature level?

[eriktamsen]

I thought there was a difference between a pure ufl description and one which includes these quadrature spaces. If this is not the case, then this is great and makes this easier =)

[TTitscher]

Jörg may mean that we also implemented Hookes law "manually" (without UFL) on the quadrature spaces. If possible, I prefer to also allow problem definition with UFL constitutive laws. That would give a much smoother "Getting starting" section in the future tutorial :)

Specifically for the stresses, I'd argue that those are either a UFL form or quadrature space values. Both can and must be projected into suitable visualization spaces. Devil in the detail: In 3D, the UFL form returns a 3x3 tensor, our Voigt-based quadrature implementation a 6x vector... We could define a stress_visu_space to always be a dolfin.TensorFunctionSpace and transform the Voigt values accordingly. Pro: Consistent to UFL, looks better in paraview (individual components are marked xx, xy, xz and so on). Contra: Sigma symmetric and off-diagonals would be stored twice.

No deal breaker, just a matter of definition.

[eriktamsen]

I agree that the possibility of UFL models should be included, as this is one of the strength of Fenics, even though only for "simple" problems.

I could live with "wasting" some memory space, when in turn we can have a more intuitive tensor handling. I have cursed the Voigt notation too many times. It really starts being fun when you go into nonsymetric stress measures, eg. P (first Piola-Kirchhoff stress tensor), for large strains. This would only affect the storing and visualization of the stress, right? As when I remember correctly, Voigt also has performance advantages as this can reduce unneccary computations, due to symmetry.

[joergfunger]

For me, implementing both interfaces is also fine (UFL and quadrature).

[pdiercks]

We could define a stress_visu_space to always be a dolfin.TensorFunctionSpace and transform the Voigt values accordingly. Pro: Consistent to UFL, looks better in paraview (individual components are marked xx, xy, xz and so on). Contra: Sigma symmetric and off-diagonals would be stored twice.

The stress_visu_space could be a dolfin.VectorFunctionSpace each for the diagonal and the off-diagonal entries. In the paraview you would then have mappings according to your Voigt notation used (x --> xx, y --> yy, z --> zz for diagonal and x --> xy, y --> xz, z --> yz for example)

strain and stress forms are accessible via problem.eps and problem.sigma (and not problem.strain, problem.stress)

Just a comment to take into account for the naming: maybe problem.stress is better than sigma. sigma refers to the stress in the current placement and therefore stress would be more general and depending on the problem this could as well be the 1st Piola Kirchhoff stress tensor. the same applies for the strain measures.

[ajafarihub]

Considering discussions in #20 and also what I commented here, I would be more fan of developing individual classes for certain problems (or groups of problems) that look too different; e.g. Elastic, ThermoElastic, MixedProblems, etc. Of course, in this procedure we can still try to define attributes and methods that could possibly be most common among others. So far, Plasticity and Elasticity have been merged, i.e. both are modelled via MechanicsProblem . However, such an adequate level of similarities might not easily exist among other problems.