while there might be the chance that we need this, we better focus on
today's capabilities and don't make the material.yaml syntax more
complicated in anticipation of potential changes
Strict typing for YAML
New access pattern requires to specify the expected type, i.e. 'scalar', 'list', or 'dict'. This ensures that the node offers the expected functionality instead of polluting 'tNode' with dummy functions which throw error messages if not overwritten.
The restructuring of the code allows to hierarchically construct methods without much code duplication.
Some aspects of the error messaging system have been improved.
material.yaml specification is designed to allow more than one, but that
requires to have two phase fields etc.
For the moment, keep it as simple as possible.
choice of damage model triggers eigendeformation, no repeated variables
This implementation is the most ugly hack I could imagine. I just serves
the purpose of having a stable material.yaml
Martin Diehl