Skip to content

Conversation

@lijas
Copy link
Collaborator

@lijas lijas commented Aug 3, 2021

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
Copy link

Codecov Report

Merging #35 (3ca19bc) into main (2a4ef29) will decrease coverage by 0.80%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
src/MaterialModels.jl 0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a4ef29...3ca19bc. Read the comment docs.

@kimauth
Copy link
Owner

kimauth commented Aug 12, 2021

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
Copy link
Collaborator Author

lijas commented Aug 13, 2021

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
Copy link
Owner

kimauth commented Aug 13, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants