[IN REVIEW] Refactor EAS to handle NonLinearElastic

[tarun-mitruka]

This PR focuses on refactoring enhancedassumedstrains.hh such that it is compatible also with nonlinearelastic.hh.

See CHANGELOG.md for more details.

See also Issue #331.

DONE

• Include updateState(/*...*/) in mixin.hh
• Get rid of noAssembler() argument for nonlinop construcor
• Does updateStateImpl() need to be a template of scalartype?
• Incorporate the call of the updateState() function in nonlinear solvers. (see below the call by FEGenericObserver as an example)
• Check if AutoDiff tests could be refactored even further
• Can we make a default implementation for updateState() or does every element need to implement this - Every element has to implement as it can then also be used for instance to update history variables while working with plasticity.
• Add tests performing a nonlinear analysis along with the EAS method.
• Fix/Add Python bindings accordingly

// In newtonraphson.hh
this->notify(NonLinearSolverMessages::SOLUTION_UPDATED, correction_);

// In main.cpp
auto updateStateObserver = std::make_shared<Ikarus::FEGenericObserver<Ikarus::NonLinearSolverMessages>>(
    Ikarus::NonLinearSolverMessages::SOLUTION_UPDATED, [&](const Eigen::VectorXd& correction_) {
      for (auto& fe : fes) {
        req.insertGlobalSolution(Ikarus::FESolutions::displacement, D_Glob)
            .insertParameter(Ikarus::FEParameter::loadfactor, lambda);
        fe.updateState(req, correction_);
      }
});

nr->subscribeAll({updateStateObserver });

OTHER PR

• Check and implement stresses (NonlinearElastic + EAS) -> To be done along with Add Result tests for Nonlinear Elastic #285
• Rework EAS with possible enhancements on displacement gradient and deformation gradient -> To be done after Add Local FE functions for non-linear contiuum mechanics #85
• Functionality to switch/transform between total Lagrangian and two point formulations -> To be done along with Non-linear finite elements #86

[codecov]

Codecov Report

Attention: Patch coverage is 96.66667% with 6 lines in your changes missing coverage. Please review.

Project coverage is 80.72%. Comparing base (13b6e50) to head (acb6da3).

Files with missing lines	Patch %	Lines
...finiteelements/mechanics/enhancedassumedstrains.hh	93.33%	5 Missing ⚠️
...olver/newtonraphsonwithscalarsubsidiaryfunction.hh	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #325      +/-   ##
==========================================
+ Coverage   78.99%   80.72%   +1.72%     
==========================================
  Files          69       70       +1     
  Lines        2238     2309      +71     
==========================================
+ Hits         1768     1864      +96     
+ Misses        470      445      -25     

Flag	Coverage Δ
tests	80.72% <96.66%> (+1.72%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tarun-mitruka]

@rath3t The C++ side of this PR is ready for the first review, the Python bindings side will be updated after the C++ side is converged in either this PR or via a separate PR by @henrij22

[tarun-mitruka]

I am not sure if this minor difference is acceptable here as ANSYS APDL is used more like a black box, where the control routine and nonlinear solver algorithms are not fully clear. Since the easAutoDiffTest passes, I think the solution should be correct here.

[tarun-mitruka]

Shall I remove the APDL comment here or leave it?
@rath3t You didn't comment anything in the tests during your review process. Can it be assumed that no major changes are necessary there?

[rath3t]

IN my view the Nonlinear operator is by design only a collection of a function and its derivative.
There should be no template or object of an assembler. What should this be doing if all functions are just lambdas without any underlying assembler? But somehow I also dont see a nice solution to this we should chat about different posibilities of design choices. I think it can be already done with observers but this might be to indirect. E.g. all EAS element observe the non-linear solver and as soon as the solvers signals that the iteration or load step is finished the elements get notified and can update what they want. This seems nicer, since we dont have to refactor the design of nonlinearoperator.

Another thing would be a new class that contains a nonlinearoperator and the assembler.
Something similar I have done already in python branch for the solvers but Im not srue if we want that.

[rath3t]

We can also disable all the linear elastic functionality if eas is present and the eas method always deals with everything. Like calculateMatrix(...) requires not hasEAS which would disable the function alltogether and we would not have the runtime switch with usesEASSkill().

[rath3t]

I dont like that introduction of states inside the innocent Newton-Raphson function.
This entangels unrelated functionality and might drop on our feet later, sicne extensibility is compromised since a local change somewhere else might affect this here.

[rath3t]

same

[rath3t]

As i said before this is not so nice

[rath3t]

See comment. But we should discuss this in person.

[tarun-mitruka]

To- Dos (New)

• Remove/Modify Code related to displacement-based stuffs in EAS such that 'usesEASSkill' is not needed @tarun-mitruka
• Remove notion of assembler from nonlinear operator and the notion of update state from nonlinear solver. Add a factory for control routine which takes in the assembler and subscribes a message for the solver. The finite elements should then inherit from an observer itself. @henrij22
• It was recently discovered that somewhere in the code, either a copy of the assembler or the finite element container occurs and the current updateState function called by the nonlinear solvers updates the state variables of the "wrong" finite element container. This is apparently fixed by the broadcaster-listener design in [WIP] Observer Pattern for UpdateState #346. This also has to be merged first before this PR is merged.

[henrij22]

this is neccesary 1) gcc won't compile otherwise and 2) that the correct function is chosen (idk why but if that is not here, then the function in nonlinear "wins" and nans are returned)

[tarun-mitruka]

Is it due to the priority tags? For a similar reason, I added a default in feresulttypes.hh to get zeros instead of nans, which I think is removed now

[henrij22]

My comment was in constrast to just requires(supportsResultType<RT>())