I’ve been looking through the Mesh Deformation code and documentation, looking for something I can use/adapt for a problem I’m working on.
My goal is to move a free-slip mesh boundary without advecting material with the boundary’s normal motion. Essentially, the free-slip condition is defined with respect to ASPECT’s fixed reference frame, not the moving mesh manifold. Any new material entering the domain inherits its composition, stress state, and temperature from the current boundary conditions. Any material leaving the domain is discarded, along with its history.
Based on my understanding of the current codebase:
Boundary function: Deforms the mesh and the material together; boundary motion is prescribed externally (“hand of God”).
(hillslope) Diffusion: Produces the desired decoupling between mesh and material deformation, but only for a very specific mesh deformation function.
Free surface: Deforms the mesh and material together, with boundary motion determined by the solution of the flow field.
If my understanding is correct, what I am looking for seems to be a combination of the Boundary function and (hillslope) Diffusion approaches.
Is there a way to achieve this behavior using the existing codebase? If not, would it be more appropriate to extend Boundary function, or to implement a new plugin altogether (Decoupled boundary function?)?
A follow up. Having tried out `tests/gmg_mesh_deform_topo.prm` with a later end time (0.24), I am confused. In this prm, the LHS of the top boundary oscillates like part of a sine wave. At t=0.2, the velocity field and streamlines look like this:
The yellow streamlines are cut off by the edges of the domain, the blue ones represent closed streamlines. The presence of the yellow streamlines makes sense either if the mesh deformation function deforms the material (as I originally thought) or if the boundary is open, but I do not understand the actual velocities - for example, nowhere in the cycle of mesh deformation do the velocities reverse direction. Here are some of the properties from the input file:
subsection Boundary velocity model set Tangential velocity boundary indicators = bottom, top set Zero velocity boundary indicators = left, right end
subsection Mesh deformation set Mesh deformation boundary indicators = top: boundary function set Additional tangential mesh velocity boundary indicators = left,right subsection Boundary function set Variable names = x,y,t set Function expression = 0; if (x<0.5, 1e+2\*sin(x\*2\*3.14159)\*cos(t/0.001), 0) end end
Can anyone help me make sense of this?
P.S. the simulation took about a minute to run with the changed end time, so hopefully these results are easy to reproduce.
I also ran at a global refinement level of 6, which also has streamlines truncated by the model boundary. Here are the streamlines in the top left part of that model at t = 0.08:
Please note that this also means prescribed velocity boundary conditions are defined in a stationary coordinate system, not a coordinate system that moves with the mesh.
However, this still leaves me confused by the docstring in tests/gmg_mesh_deform_topo.prm, e.g.:
The oscillating sin wavee [sp.] on the surface pushes the rising plume up and down.
More confusingly, the behaviour of the simulation arising from that prm doesn’t seem (to me) to be consistent with either description (see my previous message).
Hey @tjhei! Thanks for the link to the video; it’s great to visually check that the solution looks the same as it used to. The description certainly matches the video but I’m still not sure that the solution is correct.
I had a (maybe) epiphany this morning. At all stages of the simulation, the flow field at the boundary looks perfectly horizontal, even when the boundary is not. So perhaps during mesh deformation the position of the boundary is updated, but the normal direction is not?
All mesh deformation plugins behave the same way. It is not useful to think free surface does this and that other plugin does that, they all act the same.
All mesh deformation plugins deform the mesh geometry. The variable for the mesh system is displacement, not velocity; sometimes velocity is used to compute displacement, but the plugins themselves work with displacements.
Deforming the mesh also deforms the solution stored on that geometry. But deforming the mesh happens as the first thing in a timestep, and directly afterwards this deformation of the solution is compensated in the advection equations so that no material moves because of the mesh deformation (in an absolute reference frame). In other words: If no material moves in a model without mesh deformation, and you add arbitrary mesh deformation, the material is still not moving in absolute coordinates - from the outside the mesh is now moving relative to the (stationary) material.
Everything that happens at the boundary (no matter which mesh deformation) depends on the difference between Stokes velocity and mesh velocity (which is computed from mesh displacement and time step).
A consequence is that deforming the mesh does not “push material around” contrary to what the test that you ran suggests. Material will be added/removed in the advection equations if the boundary moves outward/inward. The reason it looks weird in the test is likely that:
The test shows temperatures, and there is a fixed temperature boundary condition at the top boundary (so it looks like cold material is pushed downward, while in reality cold material is lost and hot material is cooled down rapidly by the boundary condition).
The test uses free-slip at the top, and since the boundary is deforming of course material has to “flow around” that bump of the top boundary. I cant exactly tell you why Paraview streamlines flow through the boundary, but there are multiple possible problems in this model at that boundary, one of which you already mentioned (since the mesh deformed after we computed boundary constraints it is possible that we are using the wrong boundary normal in such a case).
All other solution properties dont know about the mesh deformation. They react to their boundary conditions though, so when material moves into the model (or the mesh boundary moves outward, causing a “compensating” influx) this new material will have T/C values according to the boundary condition.
Coming back to your original question:
My goal is to move a free-slip mesh boundary without advecting material with the boundary’s normal motion.
Just use the boundary function plugin. That should do exactly what you want. If not, let me know.
Amazing, thank you for all of the time and thought you put into that response!
I agree with your thoughts about tests/gmg_mesh_deform_topo.prm - from the temperature field alone I couldn’t tell exactly what was going on, which is why I visualised the velocity as well. Given that that test uses the boundary function plugin, is there somewhere I should look for a boundary normal bug, or maybe I can add a new test or two? It would be nice to (a) be helpful and (b) give me some confidence that I understand what is going on!
