Separate mechanics, fracture, and thermal models

[streeve]

Separate mechanics, fracture, and thermal models

ForceModel uses combinations of MechanicsModel and FractureModel to run dynamics. ThermalForceModel uses combinations of MechanicsModel, FractureModel, and ThermalModel. It is likely not obvious why only certain options are available

• Retain the original models as wrappers around these better separated components
• Renames generic reuse of the Fracture tag with CriticalStretch since that's actually how we model bond failure

TODO: agree on naming. In particular, I'm not sure I want Experimental namespace, but it was a quick easy choice. May be time for a discussion on deprecation timelines of the old models as well

[JBludau]

I am in favor of this ... Maybe we should think about some changes we want to do until 1.0 and when we want that to be.
I would say it is fair game to change the interface in a major version and with our limited user base it might be ok to not yet have a deprecation cycle. We could add one for >1.0

[streeve]

I am in favor of this ... Maybe we should think about some changes we want to do until 1.0 and when we want that to be. I would say it is fair game to change the interface in a major version and with our limited user base it might be ok to not yet have a deprecation cycle. We could add one for >1.0

To be honest we've changed interfaces a number of times in this version, but I'm trying to reduce that as we grow. You're right about the deprecation cycle - let's wait on that.

I still haven't come up with a good naming for OldForceModel and NewForceModel though

[streeve]

@JBludau I can split out some of the simpler changes (tag renaming) if you want, but can you review? This is kind of blocking the custom properties. Presuming we keep the older heavily inherited models, the plan would be to only support constant material properties in those

[JBludau]

I think this is going into the right direction. Not sure though if Experimental is the right call here, given that we already plan on using it in the internals

[JBludau]

hmm ... with this the new model is no longer in experimental, right? If we implement our backward compatibility with it is per definition the new way of doing things.
Also, we would be recommending to use a method in Experimental in our examples. Maybe we should just leap and promote it to the main namespace in one go?
Or, if we want to slowly get used to it: put it in Impl and allow us developers to just use it for testing until we are sure it is ready.

But I don't know the best way forward

[JBludau]

Ok, so we don't take it by reference here ... so that should be fine with our device capture

[JBludau]

@JBludau I can split out some of the simpler changes (tag renaming) if you want, but can you review? This is kind of blocking the custom properties. Presuming we keep the older heavily inherited models, the plan would be to only support constant material properties in those

The tag rename is pretty straightforward so I think it is fine doing it in one go here

[JBludau]

I like the direction

[streeve]

@JBludau this sat a long time in attempting not to break everything at the end of the quarter. Found one more thing in discussion with Pablo - LPS still isn't ready for thermomechanics. I'll merge soon unless there's a new reason to hold