(What has been done / What is important to be done) regarding the Constitutive Laws in StructuralMechApp

[AlejandroCornejo]

Dear Structural Mechanics Team (and colleagues) I think that it is important to recapitulate all the implemented CL and the current state of them. In this way I've created the following table in order to summarize the work done.

This issue has, in my opinion, two main objectives:

1. Summarize and decide the TODO tasks regarding the job done

2. Talk about the future implementations (new CL's, modifications of the current structure of the code...)

Thank you all,

[loumalouomega]

nice, I still have pending to apply the last corrections in the large deformations laws

[RiccardoRossi]

@AlejandroCornejo well done! my feeling is that it would be pretty important to have some implementation of the basic casis of plane stress/strain (once we agreed about #3935 )

also what kind of plastic potential etc ?

as a final comment we should document with some examples of use

[frastellini]

Thank you @AlejandroCornejo . It would be also good to have a table with implemented yield functions, plastic potentials and hardening laws available for plastic (and damage) models.

[AlejandroCornejo]

[philbucher]

Guys will you make a separate issue abt separating the CLaws into a different shared-library and replacing the template-mechanism by sth more suitable?

[loumalouomega]

I tried, but is a little bit more complex I expected, because recursive dependencies between laws and other things

[AlejandroCornejo]

Guys will you make a separate issue abt separating the CLaws into a different shared-library and replacing the template-mechanism by sth more suitable?

I think that we can talk about that here in fact :)

[philbucher]

I tried, but is a little bit more complex I expected, because recursive dependencies between laws and other things

Ok

Still I would say this should be made priority very soon after the release, the linking times have really increased and it affects out developments in StructuralMechanics

[philbucher]

ping, any news?

[philbucher]

Another question, what is the plan regarding the deprecation-warnings related to the ConstitutiveLaws?

[loumalouomega]

First we should update the message. Then check which laws use this methods, then remove from the elements. Then pray

[philbucher]

any news here?

[AlejandroCornejo]

Okkey! I sincerely forgot about this issue, sorry @philbucher . As far as I've understood, there are two main concerns:

1. Compilation time due to the highly templated CL
2. Set CL variables in a separated file

The point 1. is the tricky one since it means refactoring everything (quite a work) but it can be done if it's a major improvement The point 2. it's easy and relatively fast I think.

What are your opinions @loumalouomega @RiccardoRossi @philbucher

[philbucher]

about 1. yes ofc this is a large work but I think this will pay of about 2. as discussed above the idea would be do "decouple" the CLaws more from the elements, i.e. to reduce the dependencies. The intermediate solution would be to have them in a separate shared library and the final goal from how I understood the previous discussions would be to have a separate app for the advanced CLaws and the basic CLaws should be in the Core

@AlejandroCornejo I suggest that once your current PRs are merged we can start by putting the CLaws into a different lib, this wil already mitigate the problems with dependencies and compilation/linking times

[loumalouomega]

@philbucher I already tried to separate into a independent library the CL, and I remember the change was not trivial...