Material class

[JoranZwet]

I propose to use a material class to store material properties instead of independently defining each material property whenever it is necessary.

As a consequence get_D, assemblestiffness and assemblemass would have to be altered, where instead of defining material attributes (e_modulus, nu, rho), we would first define a material class which stores all those values.

Stijn made me do this

[aatmdelissen]

Some questions we need to think about before we can implement this:

• How does the user know which material properties are used by a module? We don't want the user to fill in 10 different properties when only E and nu are used.
• Would it be possible to also support multiple materials in different (predefined) regions? And how can we efficiently capture this information? Currently, multiple material properties can be implemented by multiplying the scaling vector (input of assembly) with another vector of E values for each element. Multiple different Poisson ratio are not supported however.

[artofscience]

small add; for multiple material with different Poisson ratio we can look at SIMPALL [Ferrer, 2020]; I have some good experience with this.

[JoranZwet]

I think each material property should just have a default value when the material class is initialized, then a user would only have to define specific material properties when they are relevant

[artofscience]

It is probably easiest to make a new branch where you introduce this feature; then we can check the use of such class as well as the implications on other modules. (aka geen woorden maar daden)

[aatmdelissen]

From #21:

Maybe we can have some way of overriding with a standard argument for the 'general' assemble operation. What I mean is something like

pym.AssembleGeneral(s_scale, EM=Stiffness(E=210e+9, nu=0.3))
pym.AssembleGeneral(s_Scale, EM=Poisson(2.5))

Where the operator passed to EM basically only is used to generate a single stiffness matrix

It might be a good idea to draft a generic interface for 1) mesh and 2) physics information, as these are tightly linked. Currently, all modules are focused on a voxel mesh and won't work, e.g., for an unstructured mesh.

Idea is that DomainDefinition can also generate physics data - domain.Stiffness(E=210, nu=0.3) would generate the required data to assemble the stiffness matrix. In general the data required for matrix assembly is:

• Dof-connectivity for each element matrix of size (#elements, #dofs_per_element)
• Element matrix corresponding to the dofs of size (#dofs_per_element, #dofs_per_element)

There are some variations to keep into account

• Unstructured mesh has a different element matrix for each element
• A compound mesh (with different element types) can have a different connectivity per element, which makes the dof-connectivity non uniform data.