Conversation
src/fluid/fluid_pnpn_bc_fctry.f90
Outdated
| case ("moving_boundary") | ||
| if (.not. neko_registry%field_exists('wm_x')) then | ||
| call neko_error("'moving_boundary' found in the BC list& | ||
| &, but ALE is not active! Set 'ale_active = true' in & | ||
| &case file.") | ||
| end if |
There was a problem hiding this comment.
Just an initial comment. This moving_boundary is just a no-slip condition underneath, right? Your new bc just does a masked copy of the mesh velocity. What I don't fully understand is how the setup of the motion in the ALE is coupled to the selection of the boundary that moves. If it is the boundary that moves, is it not more logical to prescribe the motion in the JSON dictionary for the bc? What if you have more than one moving_boundary in the current setup, does it work?
There was a problem hiding this comment.
The "moving_boundary" is similar to a Dirichlet boundary condition, but it is also used to mark boundaries that are allowed to move.
In the current implementation, a single mesh-velocity field is defined over the entire domain, assigning a velocity to every grid point. THen, the filed is multiplied by a scalar field called phi. So, we need to identify the moving_boundary regions for constructing the correct phi field.
The field phi takes values between 0 and 1. It is equal to 1 on boundaries marked as moving_boundary and 0 on all other non-periodic boundaries. When the mesh-velocity field is multiplied by phi, only the boundaries marked as moving are assigned the prescribed velocity, while all other boundaries remain fixed. Also, this method presereve the mesh quality near the wall, so mesh deformation happes mostly away from the wall.
In ale_manager, the subroutine solve_base_displacement computes the phi field by solving a Laplace equation once during initialization (in practive, we can recompute it also every N iterations, if needed). This results in a smooth spatial transition of phi from the moving boundaries into the interior of the domain.
- We can have multiple moving boundaries at the same time. The Laplace solution provides a smooth blending of motion throughout the domain. However, in the current implementation, all moving objects share the same prescribed velocity. With some hack (like defining the base mesh velocity based on coordinates to allow different object mvoe with different velocities) we can overcome this, but ofc not the best solution.
I will think about better ways to do this also.
Also, tbh, for most practical cases I think one would have 1 moving object, but it's good to make it more flexible for several moving objects for sure.
There was a problem hiding this comment.
Also, at moving_boundary, we need to set the fluid velocity vector equal to mesh velcoity (to have no-slip BC). that's what masked_copy does here. It's like enforcing the kinematics boundary condition.
There was a problem hiding this comment.
Also one way (maybe naiive, should think more about it) for generalization into several moving objects is using super position, such that we find 1 phi field for each moving body, such that phi=1 only on that body and 0 on other moving bodies, then we sum them up. and then I can set seperate motion for any number of bodies in JSON.
There was a problem hiding this comment.
Thanks for the clarification, Arash, now I understand much better! I think it is totally fine to leave the mesh motion working as you say for this initial PR. For the boundary conditions, it feels like a better way would be not introducing a new condition, but rather having a moving : true / false keyword added to ordinary boundary conditions and letting them handle that situation. In the beginning we can just add this to the no_slip condition. But later on it is probably nice if other conditions can also handle a moving boudnary, and adding a movng_* for each sounds not very practical. I am not 100% sure, but it seems this can be done rather easily, or? The only thing you need is to fetch the grid velocity inside the bc. Think about it, and I will also take a bit of a look.
There was a problem hiding this comment.
I see the point. I think it's straight forward to do this. Will give it a shot today.
There was a problem hiding this comment.
What we do now for no-slip is
allocate(zero_dirichlet_t::object)
in the bc factory. I don't think we should add anything to zero_dirichlet_t. That type is anyway mostly meant as a utility for masks etc. I think what you can do is rename the new bc you added here to no_slip, and allocate that one instead of the zero_dirichlet. Then, you pretty much do exactly the same as what you already do in the moving_boundary currently, but just add treatment of the ordinary no-slip when there is no mesh movement.
…o enable saving the lag metrics from coef
…t for moving boundaries
…mals and also added more support for center of torque calculations
…ort for multibody ALE simulations and many more stuff
|
Great stuff, I think it would be good to try to get this merged as soon as possible before it starts to lag behind |
Added an option to print out the mesh every time. I am having problems on deciding how to do this. Generally I would like that one can control what is written when the write method is called, but that is not the way we do things in Neko, so for the moment it is just like this. I guess if one creates a file_t in the user file, it is possible to control if the mesh is written by directly modifying the attribute in the object, so at least that's something. This is based on what @arash-mp will also add in #2244. --------- Co-authored-by: Timofey Mukha <timofey.mukha@protonmail.com> Co-authored-by: Victor Baconnet <baconnet@kth.se>
|
@arash-mp, is this one ready for review? Also check the failing tests. |
…ature/ALE Merging with latest develop_2026_02_11
Added an option to print out the mesh every time. I am having problems on deciding how to do this. Generally I would like that one can control what is written when the write method is called, but that is not the way we do things in Neko, so for the moment it is just like this. I guess if one creates a file_t in the user file, it is possible to control if the mesh is written by directly modifying the attribute in the object, so at least that's something. This is based on what @arash-mp will also add in #2244. --------- Co-authored-by: Timofey Mukha <timofey.mukha@protonmail.com> Co-authored-by: Victor Baconnet <baconnet@kth.se>
4 participants
Summary
This PR implements the Arbitrary Lagrangian-Eulerian (ALE) formulation to support moving mesh simulations in Neko. It introduces a new "ale_manager" to handle grid velocities and mesh deformation, modifies "fluid_pnpn" to include grid velocity terms, and updates the IO and checkpoints to support ALE simulations.
Key Changes
Core & Solver
IO & Checkpointing
Examples
ToDo:
References:
Implementation is based on:
1- Fischer, P., Schmitt, M. and Tomboulides, A., 2017. Recent developments in spectral element simulations of moving-domain problems. Recent progress and modern challenges in applied mathematics, modeling and computational science, pp.213-244.
2- Ho, L.W., 1989. A Legendre spectral element method for simulation of incompressible unsteady viscous free-surface flows (Doctoral dissertation, Massachusetts Institute of Technology).