-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object-oriented solid material models #178
Comments
I have started looking into this: I think the hierarchical structure implemented in
For example, suppose we want to model an arterial wall (domain 1) externally supported by a sheath (domain 2). Then we can define If we want to add growth to the arterial wall, then we would just combine it in the same variable: Of course not everything can be combined with everything else, but Abaqus already has documentation on what can be combined with what, under which conditions, which building blocks are incompatible etc. For growth and remodeling, we also need to think of an appropriate hierarchy based on the above template, and if/how it should be combined with other models. I am currently looking into and documenting what models are already implemented in svFSI+ and will follow-up on that. Let me know if you have any comments on the above in the meantime. |
@lpapamanolis The hierarchical structure you propose looks like a nice way to identify material model components that can be mapped to classes. An important implementation goal to keep in mind is enabling code reuse. This can be implemented using |
Thanks for discussion with @mrp089 and @MatteoSalvador yesterday. We observed that to implement Object-Oriented Solid Material Model and further to implement G&R Constraint Mixture Constituent Model, we may need material point to store the material information at every gauss point. The purpose is similar to what currently As a start, I will write a One concern about the above implementation I can imagine is the efficiency and MPI compatibility. Because the @ktbolt @lpapamanolis Any comments or thoughts are very welcomed! |
@yuecheng-yu A good start! Your material model work should probably be in a separate Issue. A few comments. Saying that
The Before you write a single line of code you should create a design document that defines what a You can then create an implementation design that sketches out how the You can then prototype your implementation in a branch that the team can use for code reviews. The |
Use Case
This affects all solid material models that are currently implemented and future ones.
Problem
We currently have a massive
switch/case
statement for our solid materials, inherited fromsvFSI
. Many of these material models overlap heavily. Furthermore, we cannot combine material models to form a new one, making it hard to implement new (more complex) material models (like G&R).Solution
Create a class structure for all existing material models.
Alternatives considered
FEBio
has a comprehensive collection of material models. This can help us figure out our material models and some of their inheritance structures.Abaqus
has interfaces for user material subroutines. There is one for general solid materials and an invariant-based one for hyperelastic materials.. This can help to define interfaces between abstract (e.g., hyperelastic) and derived classes (e.g., Neo-Hooke, Mooney-Rivlin).Additional context
This is a good opportunity to take "inventory" of what materials are currently implemented. We can use our (currently under-utilized)
Doxygen
documentation when implementing new classes to document the governing equations. This also helps visualize the inheritance structure (see here a 0D example).Code of Conduct
The text was updated successfully, but these errors were encountered: