```{tags} category:cookbook feature:2d feature:cartesian ``` (sec:cookbooks:platelike-boundary)= # Convection in a box with prescribed, variable velocity boundary conditions A similarly simple setup to the ones considered in the previous subsections is to equip the model we had with a different set of boundary conditions. There, we used slip boundary conditions, i.e., the fluid can flow tangentially along the four sides of our box but this tangential velocity is unspecified. On the other hand, in many situations, one would like to actually prescribe the tangential flow velocity as well. A typical application would be to use boundary conditions at the top that describe experimentally determined velocities of plates. This cookbook shows a simple version of something like this. To make it slightly more interesting, we choose a $2\times 1$ domain in 2d. Like for many other things, has a set of plugins for prescribed velocity boundary values (see Sections {ref}`parameters:Boundary_20velocity_20model` and {ref}`sec:extending:plugin-types:velocity-bc`). These plugins allow one to write sophisticated models for the boundary velocity on parts or all of the boundary, but there is also one simple implementation that just takes a formula for the components of the velocity. To illustrate this, let us consider the [cookbooks/platelike-boundary.prm](https://github.com/geodynamics/aspect/blob/main/cookbooks/platelike-boundary/platelike-boundary.prm) input file. It essentially extends the input file considered in the previous example. The part of this file that we are particularly interested in in the current context is the selection of the kind of velocity boundary conditions on the four sides of the box geometry, which we do using a section like this: ``` {literalinclude} boundary.part.prm ``` We use tangential flow at boundaries named left, right and bottom. Additionally, we specify a comma separated list (here with only a single element) of pairs consisting of the name of a boundary and the name of a prescribed velocity boundary model. Here, we use the `function` model on the `top` boundary, which allows us to provide a function-like notation for the components of the velocity vector at the boundary. The second part we need is that we actually describe the function that sets the velocity. We do this in the subsection `Function`. The first of these parameters gives names to the components of the position vector (here, we are in 2d and we use $x$ and $z$ as spatial variable names) and the time. We could have left this entry at its default, `x,y,t`, but since we often think in terms of “depth” as the vertical direction, let us use `z` for the second coordinate. In the second parameter we define symbolic constants that can be used in the formula for the velocity that is specified in the last parameter. This formula needs to have as many components as there are space dimensions, separated by semicolons. As stated, this means that we prescribe the (horizontal) $x$-velocity and set the vertical velocity to zero. The horizontal component is here either $1$ or $-1$, depending on whether we are to the right or the left of the point $1+\sin(\pi t/2)$ that is moving back and forth with time once every four time units. The `if` statement understood by the parser we use for these formulas has the syntax `if(condition, value-if-true, value-if-false)`. The remainder of the setup is described in the following, complete input file: ``` {literalinclude} platelike.prm ``` This model description yields a setup with a Rayleigh number of 200 (taking into account that the domain has size 2). It would, thus, be dominated by heat conduction rather than convection if the prescribed velocity boundary conditions did not provide a stirring action. Visualizing the results of this simulation[^footnote1] yields images like the ones shown in {numref}`fig:platelike`. ```{figure-md} fig:platelike Variable velocity boundary conditions: Temperature and velocity fields at the initial time (top left) and at various other points in time during the simulation. ``` [^footnote1]: In fact, the pictures are generated using a twice more refined mesh to provide adequate resolution. We keep the default setting of five global refinements in the parameter file as documented above to keep compute time reasonable when using the default settings.