Conversation
Codecov Report
@@ Coverage Diff @@
## main #50 +/- ##
==========================================
+ Coverage 90.34% 91.43% +1.09%
==========================================
Files 12 10 -2
Lines 352 292 -60
==========================================
- Hits 318 267 -51
+ Misses 34 25 -9
Continue to review full report at Codecov.
|
|
Is there a reason the base package can't just be included here? (Sorry if we discussed this before, I don't remember.) |
The main idea is a lightweight package to depend on, which doesn't care how material models are implemented but rather focuses on what can be done with a material model. E.g. when writing an FE-program, constitutive driver, or doing material parameter identification. Hence leaving packages like this free to include additional dependencies, be less restrictive about exported names, and not include all features supported by the interface (e.g. differentiation wrt. parameters). From my side would be fine to include the additional features here, but I assumed that was out of scope for this package... |
|
I see your point of havning one package with the interface, and another package with the implementations of the material models. But I dont think the separation is really needed in this case, and think they can be in the same package.
Nice
This is something I wanted as well. I tried something similar in this PR, but instead returned the extra output as a 4th output instead (instead of having a mutated object). I dont know which option is best though. |
Since we are considering using a model from this package in existing code using the MaterialModelsBase.jl package, I looked into what changes would be necessary for this to work. In case you find this interesting...
Most of the interface is based on this repo, so changes are rather minimal.
The three main differences are
NoExtraOutput()type is used.Currently, the traits part from this package has not been included - but I think that could belong in the base package as it is indifferent to the internal material model implementation.
Let me know if this is interesting to adopt - would be great to have your input on the interface to make it more general/easier to adopt.
(Note, most of the commits are just to make CI work for an unregistered package:))