[CoSim] Adding a strong block solver and block MVQN acceleration

[azzeddinetiba]

📝 Description
If I understand correctly, doing a block QN acceleration for CoSim coupling (using the PYTHON interface) is not possible as things are at the moment, since the acceleration is only applied after a full F(S(f)) ( Or S(F(u)) ) computation with the current coupled_solvers.
This is a suggestion to do that, with a block MVQN for example.
The idea is that the ConvergenceAcceleratorWrapper handles two CouplingInterfaceData instead of just one.

I realised ( probably too late 😅 ) that you aim to unify the accelerator interface with the ones in the Core or the ones in FSI (#5187) .. ? In which case this PR wouldn't be of help (?)

🆕 Changelog

• Added block coupled solver
• Added MVQN convergence acceleration in CoSim

[azzeddinetiba]

An example would be to change the config file on fsi_mok to

...

    "solver_settings" :
    {
        "type" : "coupled_solvers.block_strong",
        "echo_level" : 1,
        "num_coupling_iterations" : 12,
        "convergence_accelerators" : [
            {
                "type"      : "block_mvqn",
                "solver_sequence" :
                [
                    {
                        "solver": "fluid",
                        "data_name"  : "disp",
                        "coupled_data_name" : "load"
                    },
                    {
                        "solver": "structure",
                        "data_name"  : "load",
                        "coupled_data_name" : "disp"
                    }
                ]
                // "type"      : "mvqn",
                // "solver"    : "fluid",
                // "data_name" : "disp"
            }
        ],
        "convergence_criteria" : [
            {
                "type"          : "relative_norm_previous_residual",
                "solver"        : "structure",
                "data_name"     : "load",
                "abs_tolerance" : 1e-6,
                "rel_tolerance" : 1e-6
            }
        ],

...

        "coupling_sequence":
        [
            {
                "name": "structure",
                "input_data_list": [],
                "output_data_list": [
                    {
                        "data"           : "disp",
                        "to_solver"      : "fluid",
                        "to_solver_data" : "disp",
                        "data_transfer_operator" : "mapper"
                    }
                ]
            },
            {
                "name": "fluid",
                "input_data_list"  : [],
                "output_data_list" : [
                    {
                        "data"           : "load",
                        "to_solver"      : "structure",
                        "to_solver_data" : "load",
                        "data_transfer_operator" : "mapper",
                        "data_transfer_operator_options" : ["swap_sign"]
                    }
                ]
            }
        ],

...

[philbucher]

overall I am fine with this addition, I dont think it would block the unification of the interfaces with the Core/FSIApp

But I have some conceptual questions

[philbucher]

Apologies for the delay. Here are some more comments, style as well as conceptual:

• Please use python-style for variable names whenever possible => snake_case
• Please separate the wrapper for the block-accelerators, the code becomes quite messy otherwise
• Generally I think this is a valuable addition, thanks!
• Can you please add some tests?
  • For the wrapper I recommend doing similar tests to what I did for the current wrapper
  • For the accelerators ideally you would add a test like this one in the FSI-App. This tests the accelerators independently. I know that I never got to add it for the other accelerators, so this is optional. Maybe @rubenzorrilla can comment/recommend sth.
  • What about adding the mok-fsi case also for both of the new accelerators? This si a pretty small test case that prevent regressions, it runs an entire strongly coupled FSI simulation super fast

[philbucher]

in terms of code it looks good now, thanks for the effort!

Will you add tests?

[azzeddinetiba]

in terms of code it looks good now, thanks for the effort!

Will you add tests?

I still didn't take a look at the convergence wrapper tests.
For the fsi_mok test I think I can add one in a few moments. I'm thinking smth similar to the aitken one is sufficient ? without the external solver part ?

[azzeddinetiba]

@philbucher is it possible to run a CoSim problem on MPI while the mapper is on serial compilation ?
Otherwise I can't test on my local machine, I can't compile Trilinos .. #11900

[philbucher]

@philbucher is it possible to run a CoSim problem on MPI while the mapper is on serial compilation ? Otherwise I can't test on my local machine, I can't compile Trilinos .. #11900

Unfortunately not. I tried to implement this at some point, but decided it was not worth the effort, esp since we have Kratos-native matrices which can be used to completely replace trilinos

[philbucher]

looks good to me, thanks for the good work (and the patience)

[azzeddinetiba]

Hi, can this be merged ?

[philbucher]

sure
I approved months ago :)