Concept for extra outputs

[lijas]

A way for the user to request extra ouput variables from the material routine.

Instead of calling

s, ds, state = material_routine(mat, strain, dt)

they can call

s, ds, state, extras = material_routine(mat, starin, dt, :extras)

(Similar to how tensors export both gradient and residuals from by adding :all in the arguement list)

Should generate typestable code.
Does not affect the implementation of exciting or new materials (unless the material should output extra variables).

(Some code should be added for 2d-materials, but that could be done later)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.06%. Comparing base (2a4ef29) to head (3ca19bc).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
src/MaterialModels.jl	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #35      +/-   ##
==========================================
- Coverage   94.87%   94.06%   -0.81%     
==========================================
  Files          10       11       +1     
  Lines         351      354       +3     
==========================================
  Hits          333      333              
- Misses         18       21       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kimauth]

With this all routines would always return some (possibly empty) Extra, right? So calling

s, ds, state = material_routine(mat, strain, dt) 

on a material that has extras defined is not possible?

[lijas]

A material that has extras defined could also define the "normal" material_response routine (s, ds, state = material_routine(mat, strain, dt), so it would be possible to call it in the normal way.

[kimauth]

Ultimately we should just decide for a way to handle it now and try it out. If it breaks down for some use-case we worry about it with a concrete problem at hand. I think we should have a unit test for the fallback of material_response, but once that's there this is good to merge with me.