Kratos LSPG update.

[SADPR]

Pull Request Description

This pull request introduces significant updates to the LSPG builder and solver.

Main Changes:

Inheritance Update:

• Previously: lspg_rom_builder_and_solver.h inherited from elemental rom_builder_and_solver.h.
• Now: Inherits from global_rom_builder_and_solver.h which, in addition, inherits from residualbased_block_builder_and_solver.h.

Assembly Mechanism:

• Previously: Manual assembly for LHS with hardcoded application of Dirichlet boundary conditions.
• Now: Utilizes residual-based block builder and solver technology for Jacobian assembly, application of Dirichlet conditions, and reuses code for ROM basis creation.

Solving Technique:

• Introduced a new field in B&S settings: inner_rom_settings.
• Users can now choose between "qr_decomposition" or "normal_equations" for solving the rectangular system.

Training the Petrov-Galerkin Model:

• Inside the inner_rom_settings, users can decide whether to train the Petrov-Galerkin model or not.
• They can also choose the basis strategy: "residuals" or "jacobian".

Monotonicity Preserving Setting:

• Introduced for both global_rom_builder_and_solver and lspg_rom_builder_and_solver inside the inner_rom_settings.

ROM Manager Update:

• Necessary changes made to accommodate the new settings options.

Performance Enhancement:

• The new builder and solver exploit the Eigen library instead of UBLAS, which is expected to enhance computation speed.

Files to Review:

• applications/RomApplication/custom_python/add_custom_strategies_to_python.cpp: Exported functions to python.
• applications/RomApplication/custom_python/add_custom_utilities_to_python.cpp: Bug fixes and removal of unused functions.
• applications/RomApplication/custom_strategies/global_rom_builder_and_solver.h: Added inner_rom_settings, updated arguments, and changed variable access levels.
• applications/RomApplication/custom_strategies/lspg_rom_builder_and_solver.h: Major changes here, including a shift from UBLAS to Eigen.
• applications/RomApplication/custom_utilities/rom_residuals_utility.h: Removed unused functions.
• applications/RomApplication/python_scripts/calculate_rom_basis_output_process.py: Updated settings.
• applications/RomApplication/python_scripts/hrom_training_utility.py: Settings updates and validation.
• applications/RomApplication/python_scripts/petrov_galerkin_training_utility.py: Bug fixes, code refactoring, and settings updates.
• applications/RomApplication/python_scripts/rom_analysis.py: New settings assignment.
• applications/RomApplication/python_scripts/rom_manager.py: Adapted for new settings.
• applications/RomApplication/python_scripts/rom_solver.py: Assigned missing settings.

Note:

• KratosExamples Update:

Upon merging, the demo_rom_manager.py in KratosExamples will be immediately updated to reflect the new settings options.

• Test Adjustments:

Tests will undergo settings changes, but results are expected to remain consistent.

• Thermal Case Error:

An error was identified in the thermal case (LSPG) related to the convergence criterion. The configuration of the test was set to the 'residual criterion'. However, because the previous LSPG B&S only accounted for the 'solution criterion' and not the 'residual', this led to the problem artificially and wrongly "converging" in just one iteration instead of the expected three. With the updated LSPG B&S, both 'residual' and 'solution' criteria are considered, thanks to the inheritance from the residual-based builder and solver. This change ensures a more accurate convergence assessment. Consequently, two thermal expected output binaries were updated to account for this change. It's worth noting that before this update, the new B&S passed the tests using only one iteration.

Example of new settings for an lspg:
Before:

"monotonicity_preserving": true
"train_petrov_galerkin": {
        "train": false,
        "basis_strategy": "residuals",
        "include_phi": false,
        "svd_truncation_tolerance": 0.001
    },
    "rom_settings": {
        "nodal_unknowns": [
            "PRESSURE",
            "VELOCITY_X",
            "VELOCITY_Y"
        ],
        "number_of_rom_dofs": 28,
        "petrov_galerkin_number_of_rom_dofs": 0
    },

Now:

"rom_settings": {
        "inner_rom_settings": {
            "train_petrov_galerkin": true,
            "basis_strategy": "residuals",
            "include_phi": false,
            "svd_truncation_tolerance": 0.001,
            "solving_technique": "normal_equations",
            "monotonicity_preserving": false
        },
        "nodal_unknowns": [
            "PRESSURE",
            "VELOCITY_X",
            "VELOCITY_Y"
        ],
        "number_of_rom_dofs": 28,
        "petrov_galerkin_number_of_rom_dofs": 0
    },

[Rbravo555]

Everything looks good, but I would suggest to rename the inner_rom_settings to something more evocative like: specific_rom_b&s_settings (provided we can use ampersand).

[SADPR]

Everything looks good, but I would suggest to rename the inner_rom_settings to something more evocative like: specific_rom_b&s_settings (provided we can use ampersand).

In Kratos, the naming conventions for solver settings have been a guiding factor for me. For example, when using the monotonicity preserving solver, there's a primary setting named solver_settings, and nested within it, we have inner_solver_settings. Similarly, in the context of ROM, we use rom_settings. Given this structure, it felt natural to me to introduce inner_rom_settings as a nested setting within the primary ROM settings.

However, understanding the desire for more specificity, I'd suggest considering one of these three options:

1. inner_rom_builder_and_solver_settings
2. inner_rom_bns_settings
3. inner_rom_b&s_settings

I'd like to also note my reservations about using the "&" character in the setting name, as it might introduce potential issues.

[Rbravo555]

If they are specific to each b&s, let us reflect it on its name

[Rbravo555]

Everything looks good, but I would suggest to rename the inner_rom_settings to something more evocative like: specific_rom_b&s_settings (provided we can use ampersand).

In Kratos, the naming conventions for solver settings have been a guiding factor for me. For example, when using the monotonicity preserving solver, there's a primary setting named solver_settings, and nested within it, we have inner_solver_settings. Similarly, in the context of ROM, we use rom_settings. Given this structure, it felt natural to me to introduce inner_rom_settings as a nested setting within the primary ROM settings.

However, understanding the desire for more specificity, I'd suggest considering one of these three options:

1. inner_rom_builder_and_solver_settings
2. inner_rom_bns_settings
3. inner_rom_b&s_settings

I'd like to also note my reservations about using the "&" character in the setting name, as it might introduce potential issues.

I see your point now.

However, I'd insist in changing the name to for example rom_bns_settings --as these settings are always related to the specific RomB&S.

The proposals of keeping the inner bit plus an extra specification, are confusing and do not follow the exisiting pattern within the Kratos (although only found within the monotonicity_preserving stuff)

[SADPR]

@loumalouomega FYI, I changed some settings in the rom test that we had for the CoSimulation with ROM (NO CHANGES ON THE SOLUTION). Everything else is related to the ROM app.

[loumalouomega]

Okay from my side

[Rbravo555]

LGTM