search

KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
1.05k stars 246 forks source link

[GeoMechanicsApplication] Experiment with linear constraints to account for sheet pile walls not being present yet #12632

Closed WPK4FEM closed 1 month ago

WPK4FEM commented 3 months ago

There is a requirement to have nodal connectivities \ constraints when the interface \ sheetpile is not in place.

Refinement 13/08/2024

This will be an investigation to first understand how the existing mechanism works, second if it works with multi stage and boundary conditions and third how do we want to implement it.

The existing mechanism that we may want to use here is called multi-point constraint (MPC) and it has been documented here.

Likely candidates to provide the desired functionality: AssignMasterSlaveConstraintsToNeighboursProcess AssignMasterSlaveConstraintsToNeighboursUtility

WPK4FEM commented 3 months ago

Tried with the structural mechanics application and seemingly the master slave constraint works there.

linear_constraint.zip

WPK4FEM commented 3 months ago

When converted to GeoMechanicsApplication the process AssignMasterSlaveConstraintsToNeighboursUtility seems to run correctly, but the linear equation solver does not find MasterSlaveConstraints on the model part that is given to the linear equation solver.

The computing_model_part_name is defined in geomechanics_solver.py with the contents "porous_computational_model_part". When using this name in the process definition for the Master Slave constraints, the mechanism can be used within GeoMechanicsApplication. ,{ "python_module" : "assign_master_slave_constraints_to_neighbours_process", "kratos_module" : "KratosMultiphysics", "process_name" : "AssignMasterSlaveConstraintsToNeighboursUtility", "Parameters" : { "model_part_name" : "PorousDomain.porous_computational_model_part", "slave_model_part_name" : "PorousDomain.SlaveTrial", "master_model_part_name" : "PorousDomain.MasterTrial", "variable_names" : ["DISPLACEMENT","WATER_PRESSURE"], "search_radius" : 0.25, "minimum_number_of_neighbouring_nodes": 2, "reform_constraints_at_each_step" : false } }

In this respect GeoMechanicsApplication differs from StructuralMechanicsApplication. In StructuralMechanicsApplication the model part defined with "model_part_name": "Structure", on the ProjectParameters.json file is sent to the linear equation solver. In GeoMechanicsApplication the definition is usually: "model_part_name": "PorousDomain", but the linear equation solver receives PorousDomain.porous_computational_model_part. A further difference is that GeoMechanicsApplication uses lists of submodelparts which are processed in ExecuteCheckAndPrepare. An equivalent for that we have no found in StructuralMechanicsApplication, but there all model parts used in processes seem to automagically be taken into account.

The attached zip archive contains a working ( on 20-08-2024 ) test example for GeoMechanicsApplication.

MasterSlaveGeo.zip

avdg81 commented 1 month ago

The master-slave constraints have been added to the quay wall model by Wijtze Pieter. This issue can now be closed.