Plumbing/variable properties

[ralberd]

Approach to passing element-constant fields to materials.

[ralberd]

@cmhamel @lkgallup can you go through this diff and highlight the core changes for @btalamini?

[cmhamel]

@cmhamel @lkgallup can you go through this diff and highlight the core changes for @btalamini?

@lkgallup Can you start by removing some of the exodus files and other misc files that aren't src code? It's fine to keep mesh files for running relevant examples, but let's try to get some of that cleaned up first.

[lkgallup]

@cmhamel @lkgallup can you go through this diff and highlight the core changes for @btalamini?

@lkgallup Can you start by removing some of the exodus files and other misc files that aren't src code? It's fine to keep mesh files for running relevant examples, but let's try to get some of that cleaned up first.

@cmhamel Sure, I'll get right on it.

[lkgallup]

@cmhamel @ralberd I removed all of the files that are not necessary right now, reducing the changes greatly. A lot of the examples that I've worked on are stuck in the frfMechanicsFix branch, so once that is merged with plumbing/variable_properties, then we'll have to do something similar then, but for now this should be good to go

[ralberd]

Thanks @lkgallup. As a next step can you merge in main and deal with the merge conflicts so the pipelines start running?

[ralberd]

@cmhamel Is there a way to provide default props so that it's backwards compatible with material models that aren't changed to take them in?

[cmhamel]

@cmhamel Is there a way to provide default props so that it's backwards compatible with material models that aren't changed to take them in?

We probably could come up with a way to do that. But then it would add confusion unless we carefully document it.

I count 5 material models and the changes would be minimal. We just need to change the method signatures of the following

• [ ] Change create_material_function methods to not take in properties, or maybe just a list of static properties we don't want to change over the block. Lucas is already doing something similar in his clone of the hypervisco model with the resin cure models.
• [ ] Change energy methods to also take in props
• [ ] Change state var update methods to also take in props

[ralberd]

@cmhamel Is there a way to provide default props so that it's backwards compatible with material models that aren't changed to take them in?

We probably could come up with a way to do that. But then it would add confusion unless we carefully document it.

I count 5 material models and the changes would be minimal. We just need to change the method signatures of the following

* [ ]  Change create_material_function methods to not take in properties, or maybe just a list of static properties we don't want to change over the block. Lucas is already doing something similar in his clone of the hypervisco model with the resin cure models.

* [ ]  Change energy methods to also take in props

* [ ]  Change state var update methods to also take in props

So would this require passing in a vector of material properties to any material functions? What if you have uniform properties throughout the block?

[cmhamel]

@cmhamel Is there a way to provide default props so that it's backwards compatible with material models that aren't changed to take them in?

We probably could come up with a way to do that. But then it would add confusion unless we carefully document it. I count 5 material models and the changes would be minimal. We just need to change the method signatures of the following

* [ ]  Change create_material_function methods to not take in properties, or maybe just a list of static properties we don't want to change over the block. Lucas is already doing something similar in his clone of the hypervisco model with the resin cure models.

* [ ]  Change energy methods to also take in props

* [ ]  Change state var update methods to also take in props

So would this require passing in a vector of material properties to any material functions? What if you have uniform properties throughout the block?

There's vmap logic to check if the properties are (NE, NP), where NE and NP are the number of elements and number of propreties, or (NP,). So if properties are homogeneous you just provide a (NP,) array of properties and if you want varying properties you provide a (NE,NP) array of properties.

[cmhamel]

@ralberd Finally got this one patched up across the whole codebase.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 46.75000% with 213 lines in your changes missing coverage. Please review.

Project coverage is 75.28%. Comparing base (4fdc0b6) to head (12f928d). Report is 68 commits behind head on main.

Files with missing lines	Patch %	Lines
...timism/material/HyperViscoelastic_VariableProps.py	0.00%	106 Missing :warning:
optimism/material/Neohookean_VariableProps.py	0.00%	75 Missing :warning:
optimism/Mechanics.py	80.64%	18 Missing :warning:
optimism/phasefield/PhaseField.py	76.92%	6 Missing :warning:
optimism/FunctionSpace.py	80.00%	4 Missing :warning:
optimism/Objective.py	75.00%	2 Missing :warning:
optimism/material/Gent.py	83.33%	1 Missing :warning:
optimism/phasefield/PhaseFieldThreshold.py	88.88%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #116      +/-   ##
==========================================
- Coverage   77.82%   75.28%   -2.54%     
==========================================
  Files          63       65       +2     
  Lines        5416     5661     +245     
==========================================
+ Hits         4215     4262      +47     
- Misses       1201     1399     +198     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

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

[cmhamel]

@ralberd once this pipeline passes you can go ahead and merge this. I'm going to tag the current main branch as v0.0.2 for easy rollbacks if necessary.