Test `strufem_hex8_eas_cantilever.4C.yaml-p2` runs in timeouts

[maxfirmbach]

The test strufem_hex8_eas_cantilever.4C.yaml-p2 frequently runs into timeouts in several PRs, we should fix this asap.

[c-p-schmidt]

The input file has remained untouched for several months, meaning that, with #1715, the solid time integration was changed from the old to the new one.

[amgebauer]

If I run these tests locally, I get the following difference in the timings between the old and new solid time integration:

old:

Timer Name                                                 Global time (num calls)    
--------------------------------------------------------------------------------------
Adapter::StructureTimIntBaseAlgorithm::SetupStructure      1.1322e-02 (1)             
Core::FE::Discretization::Evaluate                         2.3499e+01 (1834)          
Core::FE::Discretization::set_state                        1.1827e-02 (4908)          
Core::LinAlg::Solver:  0)   translate_solver_parameters    9.1610e-06 (1)             
Core::LinAlg::Solver:  1)   Setup                          1.1976e-01 (1233)          
Core::LinAlg::Solver:  2)   Solve                          1.3897e+01 (1233)          
Core::LinAlg::SparseMatrix::Complete                       4.2656e-03 (1534)          
Core::LinAlg::SparseMatrix::Complete(domain,range)         1.2263e-03 (1531)          
Epetra_CrsMatrix::Multiply(TransA,X,Y)                     9.5886e-02 (1533)          
Rebalance::rebalance_graph                                 2.2753e-03 (1)             
--------------------------------------------------------------------------------------
Rebalance::rebalance_node_maps                             2.3289e-03 (1)             
Solid::TimInt::prepare_contact_meshtying                   1.1843e-05 (1)             
======================================================================================

Total wall time for CALCULATION:  4.043e+01 sec 

new:

Timer Name                                                 Global time (num calls)    
--------------------------------------------------------------------------------------
Adapter::StructureTimIntBaseAlgorithm::SetupStructure      1.2075e-02 (1)             
Core::FE::Discretization::Evaluate                         3.2357e+01 (4300)          
Core::FE::Discretization::set_state                        3.0659e-02 (1.387e+04)     
Core::LinAlg::Solver:  0)   translate_solver_parameters    7.0400e-06 (1)             
Core::LinAlg::Solver:  1)   Setup                          1.2969e-01 (1233)          
Core::LinAlg::Solver:  2)   Solve                          1.3791e+01 (1233)          
Core::LinAlg::SparseMatrix::Complete                       4.1643e-03 (1235)          
Core::LinAlg::SparseMatrix::Complete(domain,range)         1.1613e+00 (6162)          
Epetra_CrsMatrix::Multiply(TransA,X,Y)                     1.4982e-01 (2466)          
Rebalance::rebalance_graph                                 2.3541e-03 (1)             
--------------------------------------------------------------------------------------
Rebalance::rebalance_node_maps                             2.3956e-03 (1)             
======================================================================================

Total wall time for CALCULATION:  5.416e+01 sec

The difference in Core::FE::Discretization::Evaluate is remarkable. I don't know why we call the evaluate call so much more often. The convergence behavior did not change 🤔

[maxfirmbach]

@amgebauer @c-p-schmidt The pre, post etc etc calls often call itself and trigger evaluate several times, I observed that for beam-interaction too.

[amgebauer]

@c-p-schmidt and me observed that the difference is coming from how we evaluate the residuum and the linearization.

In the old framework, we always evaluate struct_calc_nlnstiff in every Newton iteration. In the new framework, we call struct_calc_internalforce, and if not converged struct_calc_nlnstiff. Our implementation is, however, not well prepared for this since we do a lot of computations twice (we just not assemble the linearization).

This is also the underlying issue in #121 observed by @dragos-ana

I think we need to discuss this behavior (in #121). Maybe there is some option in NOX that we can make use of for the cases where struct_calc_internalforce is not significantly cheaper than struct_calc_nlnstiff.