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.03k stars 245 forks source link

[ALEMeshMoving] Naming + meaning of settings #9162

Open mpentek opened 3 years ago

mpentek commented 3 years ago

The naming and/or meaning of ale_boundary_parts is not clear.

https://github.com/KratosMultiphysics/Kratos/blob/dfecc86d40657c11d5eb6682a05874522f779f23/applications/MeshMovingApplication/python_scripts/ale_fluid_solver.py#L213

As far as the functionality goes, it seems it is only adequate in case for the fluid solver the respective (sub)model parts have a NoSlip condition. This implies, that the relative velocity on the boundary and in the immediate vicinity in the fluid domain is the same, the relative velocity being zero. This does not hold in case of Slip or any kind of Wall function.

Did this occur perhaps historically, as all of the known FSI cases we have use NoSlip on the target boundary? Perhaps there is some other reason or misunderstanding? @rubenzorrilla @adityaghantasala

Note, that for RANS/URANS this might not apply. It anyway seems that converging FSI on the boundary with other boundary conditions than NoSlip is challenging. @sunethwarna

Proposal: in case the above assumptions are correct, there might be 2 ways to go:

  1. rename ale_boundary_parts to noslip_ale_boundary_parts (or something similar -> what happens to boundary parts with fixed nonzero velocity values in the fluid domain?)
  2. use some automated check
mpentek commented 3 years ago

tagging @mtnzguillermo @RiedlAndreas @philbucher as it might be relevant for coupling

rubenzorrilla commented 3 years ago

About the naming, I agree that as it is right now it can be easily misunderstood so I'm positive about your proposal (here I note that if we consider it necessary we can easily make this backwards compatible).

Regarding the "sliding" FSI interface, this is a bit more tricky. In order to do this you'd need to apply a slip-type BC in the fluid boundary (either in an MFC fashion as we normally do or using a wall-law) as well as to set the mesh velocity to be equal to the normal projection of the structure velocity. In order to have a Lagrangian interface in the normal component, the fluid slip like BC should take into account not only the tangential but the normal velocity as well. In case we're solving a two way coupling, the interface variable to be minimized should be the normal velocity projection (scalar), as you allow the fluid and structure interfaces to slide. I think that, provided that there is no mass flow through the interfaces the problem is well defined.

Having said this, I'd make clear what we're doing right now by updating the interfaces list name as @mpentek suggests.

adityaghantasala commented 3 years ago

To start with, I agree that the name " ale_boundary_parts" is confusing. For me, "interface_boundary_parts" is a generic name. And the distinguishing of the type should happen somehow implicitly inside the ale_fluid_solver. This is the best possible case. In case we want to have another additional setting like "noslip_ale_boundary_parts" and "slip_ale_boundary_parts" , the operation of ensuring that the velocity assigned to the "slip" nodes is free of tangential components (as @rubenzorrilla says) should be done in the ale_fluid_solver or in case of co-sim app , it can also be done in a coupling operation.