An ejector is a simple mechanical component with no moving parts that uses momentum and energy transfer from a high-velocity primary jet to induce a secondary flow. During this process, a high-energy fluid (the primary flow) moves through a convergent–divergent nozzle, eventually achieving supersonic conditions.

When the primary fluid leaves the nozzle, it mixes with a secondary flow in an area called a mixing chamber, which is a constant-area duct. This mixing results in a set of complex interactions between the mixing layer and shocks. The fluid expands and decelerates in the mixing chamber and diffuser, a device often placed before the outlet to help recover pressure and return the flow to stagnation. As a result, the fluid speed is reduced to subsonic conditions before it is released into the atmosphere.

*Simple schematic of an ejector.*

Ejectors are used for various applications, such as:

- Space debris removal
- Industrial refrigeration (e.g., in supermarkets)
- Gas recirculation
- Thrust augmentation in aircraft propulsion systems
- Vacuum generation

*Ejectors can be used to launch nets and capture space debris (like dead satellites) that orbit around Earth and pose a danger to astronauts and space-faring vehicles.*

To further advance ejector designs, it’s possible to use simulation to study the compressible turbulent flow within these devices.

This benchmark model of a supersonic ejector analyzes air in the primary and secondary streams. For verification purposes, the model definition with geometry, fluid properties, domain settings, and boundary conditions are all taken from scientific literature. Just like in the literature, this example is defined in a 2D axisymmetric coordinate system, since the problem is rotationally symmetric.

For details about the dimensions of this example, check out the model documentation for the supersonic ejector.

*Model geometry of the supersonic air-to-air ejector.*

In this example, the pressure of the secondary flow is smaller than the outlet pressure. The secondary flow is induced by the supersonic primary flow exiting the primary nozzle, which can induce a flow with an adverse pressure gradient. This flow is used in vacuum generation, where very low pressures can be achieved in the secondary inlet, and gas recirculation in, for example, fuel cell systems. In the case of recirculation, the COMSOL Multiphysics® software can be used to compute the recirculation mass flows, as seen in the model documentation.

The ejector problem discussed here can be solved using the *High Mach Number Flow* interface in the CFD Module, which is useful for accurately describing supersonic flows in gases.

The first result, below, shows that the flow velocity in this example is large enough to cause significant density and temperature variations in the fluid. Further, the flow exceeds a Mach number of 1 in the divergent section of the primary nozzle and in the mixing chamber. The deceleration of the fluid (from supersonic to subsonic flow) occurs through a complex succession of shocks, called a shock train or pseudoshock wave, caused by the boundary layers interacting with the mixing layers. These shocks are clearly seen as shock diamonds in the simulation results.

*Results showing a typical pattern with shock diamonds in the velocity field. These shock diamonds can also be observed experimentally in the case of reacting flow; for example, when combustion takes place in the flow.*

As expected, the primary flow accelerates within the nozzle’s convergent section, achieves sonic conditions in the throat, and expands in the divergent section.

*Mach number distribution in the ejector (left) and velocity distribution in the nozzle and mixing chamber (right). Both plots depict shock diamonds.*

Meanwhile, the secondary flow behaves like an artificial wall for the primary flow at the outlet of the primary nozzle. This results in virtual nozzle throats and a succession of expansion and compression waves past the mixing zone. Eventually, the flow decelerates within the constant-area duct and returns to stagnation at the diffuser.

*Turbulent kinetic energy distribution in the ejector, showing the two flows combining in the mixing chamber.*

Moving on, the plot below analyzes the pressure at the mixing chamber centerline and walls. While it’s true that the multiple shocks cause the flow to switch from supersonic to subsonic at the centerline of the duct, these shocks cannot be detected via wall pressure measurements. The reason the shocks can’t be detected is that the dissipation in the boundary layer can smear out the surface pressures.

*Pressure distribution along the mixing chamber centerline (blue) and walls (green).*

Next is the temperature of the ejector. The results here indicate that there are very low temperatures within the ejector. The outlet even has a lower temperature than both of the inlets. This is an important observation for those designing ejectors, especially when they are working with two-phase flows.

*Temperature distribution in the ejector.*

The results of the ejector benchmark model correlate well with results found in existing literature, showcasing the ability of the CFD Module to accurately analyze ejectors.

Want to try modeling a supersonic ejector? Get started by clicking the button below. This button takes you to the Application Gallery, where you can use your COMSOL Access account to download the MPH files (with a valid software license) for the example discussed here.

To learn more about supersonic flows, check out this blog post: How to Model Supersonic Flows in COMSOL Multiphysics®

]]>

Fluid flow can be accurately described by the laws for conservation of momentum, mass, and energy. The most accurate way to describe these laws is by partial differential equations (PDEs). The system of PDEs that describes these laws is nonlinear. In most practical cases, these equations cannot be solved analytically. Instead, we can discretize in space and time in order to get an approximation of the PDEs in the form of algebraic equations that we can solve. We can say that we approximate our mathematical model with a numerical model.

*The “real” description of the geometry, to the left, is approximated with a discretized description where momentum balances and mass balances in each element are carried out.*

For problems in space and time, COMSOL Multiphysics uses the method of lines, where the discretization in space is done using the finite element method and time discretization is done using some standard method for ordinary differential equations, such as backwards differentiation formula (BDF) or Generalized-α.

The fluid flow equations are nonlinear, which means that the discretized numerical model equations are also nonlinear. For transient problems, a system of nonlinear equations has to be solved at every time step. For steady flows, the numerical model equations form a system of nonlinear equations that has to be solved once.

The method for solving the systems of nonlinear equations, both for the time-dependent and stationary problems, is a damped Newton method, when the system is solved fully coupled. This method is based on linearization of the nonlinear equations and solving the linear equations in a sequence of iterations, often referred to as Newton iterations, until we obtain the desired accuracy.

In our case, we have hundreds of thousands or millions of equations and unknowns, proportional to the number of nodes in the finite element mesh that we used to generate the numerical equations. The linear equation system that has to be solved in each Newton iteration is too expensive to solve with a direct solver. However, we can solve the linear equations with an iterative solver using much less memory.

*Even this relatively simple model of the flow in a centrifugal pump requires 350,000 equations and unknowns. Thanks to the AMG solver, the equations can be solved on a desktop computer.*

For fluid flow problems, COMSOL Multiphysics uses the generalized minimal residual (GMRES) method, which is an iterative method for solving very large systems of linear equations. We can modify the linear equation system so that the GMRES method performs much better.

Multigrid methods provide an optimal technology for modifying, or preconditioning, the equation system for iterative techniques like the GMRES method.

The GMG method acts on the linear equation system for different mesh levels, from fine to coarse meshes. It transfers solution candidates, the iterates, between different linear systems corresponding to coarser and finer meshes. The idea is that a direct method is solved only for the coarsest mesh and this information is used to find a solution for the finer mesh levels more quickly. The coarse problem needs to be so small that it does not affect the performance of the method.

In each GMRES iteration, the GMG method may go from a finer mesh, where the right-hand side of the system is obtained, mapping the approximate solutions at the finer levels to the coarser mesh in a process called *presmoothing*. The solution of the equations is corrected at the coarsest level using a direct solver. This solution is then mapped to the fine levels again, in a process called *postsmoothing*.

The process of going down and up the mesh levels (V-cycle) can be repeated for each GMRES iteration. When the tolerance in the GMRES iterations is reached, we have a good-enough solution to the linear system.

The GMG method is extremely efficient for fluid flow problems. However, it has a very serious limitation. For complex geometries, it may be difficult or almost impossible to generate a coarse mesh that gives a system of equations that is small enough to be solved at the coarsest level.

*The thin blades of the centrifugal pump result in very small elements in the fluid around the blades. This also implies that even the coarsest mesh level generates too many elements and consequently too many equations to be solved with a direct solver using GMG.*

The AMG method does not require different mesh levels. The coarsening process in the AMG method is based only on the structure of the linear system of equations, or, more precisely, on the matrix that represents the left-hand side of the equation system. The method agglomerates entries in the matrix that are connected into fewer entries into a new matrix with smaller size. The process of agglomerating entries can be repeated and even smaller matrices can be constructed. These are then assigned different levels according to how many aggregations have been performed. The principle of the multigrid cycle with presmoothing, postsmoothing, and coarsest level solve is then the same as for the GMG method for the constructed matrices at the different levels.

*The settings for the iterative solver (GMRES) used in combination with the AMG method to solve the model equations for the Ahmed body shown below. Note that the method is used to solve for the momentum and continuity equations (u, v, w, p) and for the turbulence model variables (k, ε) in two separate steps in the segregated solver.*

In order to monitor the performance of the different solver settings in COMSOL Multiphysics, a couple thousand tests are run every day. One of the test cases for iterative solvers and fluid flow is the so-called Ahmed body model. Another test is the so-called laminar static mixer test. The results of the measurements show that for 6.3 million degrees of freedom, the AMG method beats the GMG method with about a 13% shorter solution time on a single-core computer.

*The Ahmed body is a benchmark model for turbulent flow and a verification model for turbulence models in general.*

Note that these results reflect the COMSOL Multiphysics implementation of these methods, not a general property of the methods. On a computer with four cores, this difference drops to around 6%. For 32 cores, the two methods are equal. The reason for this behavior is that the GMG solver is parallelized to a higher degree than the AMG solver. The new AMG method has already in its first year shown superior robustness and excellent performance, on par with the best-case scenario for the GMG method.

Learn more about the key features of COMSOL Multiphysics for your numerical modeling needs via the button below.

Read more about using multigrid methods on the COMSOL Blog:

]]>

The important boundary condition that we will discuss here is called the *Inflow* boundary condition. It is available at boundaries that are exterior to a fluid domain and is equivalent to having a virtual channel “upstream”. The *Inflow* boundary condition is used to define a heat flux at the inlet boundary that brings the same energy to the fluid domain as if you had modeled the virtual channel as a real CFD domain. The virtual channel can be seen as a long insulated channel with given thermal properties at the inlet, and with the same velocity profile as defined in the settings for the *Inflow* boundary condition.

*Representation of the virtual domain corresponding to an* Inflow *boundary condition.*

From a mathematical point of view, the boundary condition is formulated as a flux condition:

(1)

-\mathbf{n} \cdot \mathbf{q} = \rho \Delta H \bf{u}\cdot \mathbf{n}

where the enthalpy variation is defined as:

(2)

\Delta H = \int_{T_{\mathrm{upstream}}}^{T}{C_p \mathrm{d}T}+\int_{p_{\mathrm{upstream}}}^{p}{\frac{1-\alpha_p T}{\rho}\mathrm{d}p}

where we can designate the two terms:

{\Delta H}_T = \int_{T_{\mathrm{upstream}}}^{T}{C_p \mathrm{d}T}

and

{\Delta H}_p = \int_{p_{\mathrm{upstream}}}^{p}{\frac{1-\alpha_p T}{\rho}\mathrm{d}p}

so that we can write:

\Delta H ={\Delta H}_T + {\Delta H}_p

This expression contains two terms. The first, , depends on the temperature difference while the second, , depends on the pressure difference.

Eq. (1) expresses the fact that the normal conductive heat flux () at the inflow boundary is proportional to the flow rate and enthalpy variation between the upstream conditions and inlet conditions.

As shown in Eq. (2), the enthalpy variation depends in general both on the difference in temperature and in pressure. However, the pressure contribution to the enthalpy, , is neglected when the work due to pressure changes is not included in the energy equation.

In the COMSOL Multiphysics® software, this is controlled in the *Nonisothermal Flow* multiphysics feature using the corresponding check box:

There is another classical case where this term cancels out: when the fluid is modeled as an ideal gas. Indeed, in this case, .

First, let’s assume that the pressure contribution to the enthalpy is null. (We have seen above that this is actually quite often the case.) Then, the boundary condition reads:

(3)

k\nabla T \cdot \mathbf{n} = \int_{T_{\mathrm{upstream}}}^{T}{C_p \mathrm{d} T} \: \rho\mathbf{u} \cdot \mathbf{n}

When advective heat transfer dominates at the inlet (large flow rates), the temperature gradient, and hence the heat transfer by conduction, in the normal direction to the inlet boundary is very small. So in this case, Eq. (3) imposes that the enthalpy variation is close to zero. As is positive, the *Inflow* boundary condition requires to be fulfilled. So, when advective heat transfer dominates at the inlet, the *Inflow* boundary condition is almost equivalent to a *Dirichlet* boundary condition that prescribes the upstream temperature at the inlet.

Conversely, when the flow rate is low or in the presence of large heat sources or sinks next to the inlet, the conductive heat flux cannot be neglected. In addition, the inlet temperature has to be adjusted to balance the energy brought by the flow at the inlet and the energy transferred by conduction from the interior, as described by Eq. (3).

This makes it possible to observe a realistic upstream feedback due to thermal conduction from the inlet surroundings.

Keeping the assumption that the enthalpy only depends on the temperature and that, in addition, the heat capacity is constant, Eq. (1) reads:

(4)

k \nabla T \cdot \mathbf{n} = (T-T_\mathrm{upstream})C_p \rho\mathbf{u} \cdot \mathbf{n}

which corresponds to a *Danckwerts* boundary condition that is used in, for example, the *Transport of Diluted Species* interface.

In practice, there are many models where the heat capacity is nearly constant, so the *Inflow* boundary condition behaves like a *Danckwerts* boundary condition with an averaged heat capacity. Interestingly, if this is not the case, the *Inflow* boundary condition automatically accounts for an incoming flux that corresponds to the enthalpy and cannot be expressed by simply using a *Danckwerts* boundary condition.

Let’s discuss a general case. In Eq. (2), the enthalpy variation depends both on the difference in temperature and in pressure.

Considering that the *Inflow* boundary condition models a virtual channel feeding the inlet, we expect pressure losses between the virtual channel inlet and the boundary where the condition is defined. This explains why the upstream pressure is different from the inlet pressure. While the fluid flows through the channel, it is subject to pressure work that results in a temperature change between the virtual channel inlet and the boundary where the *Inflow* boundary condition is defined. This is what is described by the pressure-dependent term in Eq. (2). Note that the viscous dissipation in the virtual channel is not accounted for.

In practical situations, the pressure contribution, , is often zero (for ideal gases or when work done by pressure changes are neglected) or small in the sense that a very small difference between the upstream temperature and the inflow temperature is enough to balance it. To illustrate this, consider two common fluids:

- Air: Its density is defined from the ideal gas law in the Material Library, hence the pressure contribution to the enthalpy, , is zero.
- Water: The order of magnitude of is 1000 J/K/kg while the order of magnitude of is 0.001 m
^{3}/kg. A pressure difference of 1 bar (= 10^{5}Pa) and a temperature difference of 0.1 K induce and , respectively; two contributions with the same order of magnitude in .

To illustrate how the *Inflow* boundary condition behaves compared to a *Temperature* boundary condition, we can study the stationary temperature profile in a long channel in 2D, which actually represents a flow between two plates. Beyond a certain point, the channel is cooled by a convective heat flux on both sides. The channel height is 1 cm and the part exposed to the convective heat flux is 10 cm long. The channel is filled with air (the density follows the ideal gas law).

At the inlet located at some distance from the cooling area, the average velocity is U_{in} and the temperature is T_{hot} = 30°C. The convective heat flux is defined as h(T_{cold}-T), with h = 100 W/m^{2}/K and T_{cold} = 10°C.

Most of the temperature variations occur beyond the point where the heat flux is applied, so we can choose to reduce the computational domain by modeling only a fraction of the channel before the cooling area. The image below contains two sketches. The one at the bottom has a section of length *L*_{inlet} = 2 cm before the cooling area, while on the one on top, the inlet coincides with the beginning of the cooling area (*L*_{input} = 0).

*Representation of the geometry with a section before the area exposed to the heat flux (top) and with the inlet at the beginning of the area exposed to the heat flux (bottom).*

Now we solve the model using either a *Temperature* or *Inflow* boundary condition at the inlet. We vary two parameters in the model:

- Inlet velocity, U
_{in}: 1 cm/s and 10 cm/s - Length of the channel before the area exposed to the heat flux,
*L*_{inlet}: 0, 0.2, 1, and 2 cm

The goal of these simulations is to determine the values of *L*_{inlet}for which we are able to set accurate thermal boundary conditions using *Temperature* and *Inflow* boundary conditions, respectively.

Let’s comment on the results for U_{in} = 10 cm/s. In the left part of the figure below, we see the temperature profile using the *Temperature* boundary condition (top) and the *Inflow* boundary condition (bottom). The two graphs look very similar and it is difficult to draw any conclusion from them, but the graph on the right gives more details.

The graph to the right shows the temperature profile along the vertical line located at the beginning of the cooling zone. (It coincides with the inlet boundary, when *L*_{inlet} = 0. Let’s call it “reference line” in the rest of this blog post.) The solid lines represent the results obtained using an *Inflow* boundary condition and the dotted lines correspond to the *Temperature* boundary condition. The different colors correspond to different values of *L*_{inlet}.

Let’s first check the results obtained using the *Temperature* boundary condition (dotted line). We see that as *L*_{inlet} increases, the temperature profile along the reference line converges to a given profile. The results for *L*_{inlet} = 2 cm show no improvement; they coincide with the results obtained for *L*_{inlet} = 1 cm, so we can consider that there is no need to further extend the channel.

For *L*_{inlet} = 0, the temperature profile is quite different from the converged profile. This illustrates a classical issue using a *Temperature* boundary condition: As the temperature profile is not known in advance along the reference line, the best option is to prescribe a reasonable temperature; here, the upstream temperature.

When an *Inflow* boundary condition is used, if the value of *L*_{inlet} is increased, the temperature profile along the reference line convergences to the same profile as when a *Temperature* boundary condition is used.

We notice that especially with *L*_{inlet} = 0, the solution is much closer to the converged profile than when using the *Temperature* boundary condition.

*Left: Temperature field in the channel using the* Temperature *boundary condition (top) and* Inflow *boundary condition (bottom) for* L* _{inlet} = 0 and U_{in} = 10 cm/s. Right: A comparison of the temperature along the reference line with the* Inflow

It is important to keep in mind that in many projects, the geometry contains inlets that are fed by channels that are not represented in the geometry. While for simple geometries — like here — it is easy to modify it to include a part of the channel before the inlet, it can be challenging for advanced geometries. Even with *L*_{inlet} = 0, the *Inflow* boundary condition gives a decent prediction of the temperature profile at the inlet.

When the channel before the inlet can be extended a sufficient distance, the temperature profile on the inlet boundary obtained using *Inflow* and *Temperature* boundary conditions coincide. This is in agreement with the analysis made before stating that when the advective heat transfer dominates and an ideal gas model is used, the *Inflow* boundary condition is similar to a *Temperature* boundary condition. It is interesting to mention here that from a numerical point of view, the two conditions behave similarly in this case. (For example, the number of iterations taken by the nonlinear solver is identical for both conditions.)

Apart from the temperature profile, another quantity that should be monitored is the heat rate induced by the heat flux. The table below contains this heat rate for the different values of *L*_{inlet}. One column contains the value for the *Inflow* boundary condition and the other for the *Temperature* boundary condition.

*The heat rate tabulated for the case with highest inlet velocity.*

When the *Inflow* boundary condition is used, the heat rate is almost constant. When using a *Temperature* boundary condition, the heat rate is affected by the value of *L*_{inlet}.

Because the velocity is lower in this case, the advective effects no longer dominate. The image below to the left shows the temperature field obtained using the *Temperature* boundary condition (top) and *Inflow* boundary condition (bottom). Although the two plots look similar, a closer look at them reveals that at the end of the inlet boundary, there is a difference between the two temperature profiles.

The graph to the right shows the temperature profile along the reference line. As before, the solid lines represent the results obtained using an *Inflow* boundary condition, the dotted lines correspond to the *Temperature* boundary condition, and the different colors correspond to different values of *L*_{inlet}.

Again, for *L*_{inlet} = 0, the *Temperature* boundary condition prescribes a constant temperature along the reference line. This temperature profile is far from the solution obtained with the largest values of *L*_{inlet}. As before, we see that as *L*_{inlet} increases, the temperature converges to a given profile. However, here, the convergence is slower, compared to the case with *U*_{in} = 10 cm/s. Comparing the solution obtained using the *Inflow* boundary condition and the *Temperature* boundary condition, we notice that for any value of *L*_{inlet}, the solution obtained using the *Inflow* boundary condition is always closer to the converged profile.

*Left: Temperature field in the channel using the* Temperature *boundary condition (top) and* Inflow *boundary condition (bottom) for* L* _{inlet} = 0 and* U

The table below again shows the heat rate for the two boundary conditions.

*The heat rate tabulated for the case with the lowest inlet velocity.*

The trend is similar to the first case, but when a *Temperature* boundary condition is used, the influence of *L*_{inlet} on the heat rate is much larger. Using a *Temperature* boundary condition with *L*_{inlet} = 0, the value of the heat rate is overestimated by a factor of almost 2 compared to the solution obtained with a long inlet. Using an *Inflow* boundary condition, the heat rate is correctly predicted for any value of *L*_{inlet}.

These results show that when *L*_{inlet} is small (especially when *L*_{inlet} = 0), the temperature profile and the heat flux are more realistic using an *Inflow* boundary condition rather than a uniform *Temperature* boundary condition. This can be explained by the fact that at the inlet, a uniform temperature profile is not realistic. In practical situations, the temperature is not controlled exactly at the inlet but, for example, in a tank located at some distance.

While in many configurations, the *Temperature* and *Inflow* features describe similar conditions and lead to similar simulation results, there are a number of configurations (especially for slow flow and small dimensions) where the conductive effects are not dominated by the advective effects and where the *Inflow* boundary condition usually leads to a temperature profile that is closer to the reality than a *Temperature* boundary condition. In addition, a *Temperature* boundary condition could enforce an erroneous temperature value that induces large heat fluxes that are not realistic.

As the *Inflow* boundary condition is simple to use and usually does not induce an additional numerical cost to be solved, it ought to be the first choice to define a heat transfer condition at the flow inlet. The vast majority of model examples in the Application Libraries use it.

Learn more about all of the functionality available for heat transfer modeling in COMSOL Multiphysics by clicking the button below.

: Heat capacity (SI unit: J/K/kg)

: Heat transfer coefficient (SI unit: W/m^{2}/K)

: Boundary normal vector (SI unit: K)

: Thermal conductivity (W/K/m)

: Pressure (SI unit: Pa)

: Heat flux (SI unit: W/m^{2})

: Pressure of the upstream (SI unit: Pa)

: Temperature (SI unit: K)

, : Cold and hot temperatures (SI unit: K)

: Temperature of the upstream (SI unit: K)

: Inlet temperature (SI unit: m/s)

: Coefficient of thermal expansion (SI unit: 1/K)

: Density (SI unit: kg)

: Velocity (SI unit: m/s)

: Enthalpy change vs. reference enthalpy (SI unit: K)

]]>

Compared to other heat exchangers, compact heat exchangers have a much larger heat transfer area per volume, usually thanks to dense arrays of plates or tubes. This attribute makes these heat exchangers lighter and more compact than classical heat exchangers. One disadvantage of the smaller heat exchangers is that they have higher pressure drops, which limits the flow rate and thus the amount of heat they can transfer.

*An illustration of a plate-and-frame heat exchanger, a common type of compact heat exchanger.*

In Reference 1, researchers explored whether they could improve the performance of compact heat exchangers by adding a dynamic wall. When the wall deforms, it generates oscillations that help mix the fluid and lessen the thermal boundary layers. As a result, the heat exchanger is able to transfer more heat. In addition, the oscillations generate a pumping effect similar to that of a peristaltic pump. This makes up for pressure losses, increasing the efficiency of the heat exchanger.

Oscillation might be a useful way to enhance the performance of compact heat exchangers. Using COMSOL Multiphysics, we can test this idea by easily creating and examining a model of the dynamic wall heat exchanger…

We start by modeling a static heat exchanger without a dynamic wall. This way, we can compare the results of both heat exchanger designs.

The static heat exchanger geometry consists of an upper wall, bottom wall, and channel. Fluid (water in this case) moves through the channel, steadily increasing in temperature due to a heat flux applied to the bottom wall. At this wall, we set the delivered heat rate to 125 W. Probes at the outlet determine the temperature and mass flow rate of the water when it exits the exchanger.

*The geometry of a static heat exchanger.*

Next, we prescribe a deformation on the upper wall based on the following parameters:

- Time
- Channel height
- Channel length
- Oscillation frequency
- Oscillation amplitude
- Number of waves in the channel length direction

*Animation showing the deformation of the dynamic wall.*

For the full details of how to model the dynamic wall heat exchanger, go to the Application Gallery, where you can download the model documentation and MPH-file.

To simulate the heat transfer and oscillation, we couple two built-in features. The first is the *Conjugate Heat Transfer* multiphysics coupling, which enables us to account for the heat transport between the exchanger and the water. We combine that coupling with the *Moving Mesh* feature, which simulates the deformation of the wall and channel.

Let’s look at the results for the static analysis of the heat exchanger. When the upper wall remains flat, we get a mass flow rate of 5.5 g/s and a heat transfer coefficient of 2900 W/m^{2}.

*The temperature profile in the channel for the static heat exchanger.*

Next, let’s look at the time-dependent analysis for the dynamic wall heat exchanger. The oscillation reaches a pseudoperiodic state after around 0.6 seconds. After it enters this regime, the average mass flow rate is 10.5 g/s, nearly double the rate at static conditions. As expected, the heat transfer coefficient is also higher: about 19,000 W/m^{2} for an oscillation amplitude of 90%.

*Left: The variations in temperature and flow rate. Right: The temperature profile in the channel of the dynamic wall heat exchanger.*

With simulation, it’s possible to analyze and optimize heat exchanger designs for maximum performance and efficiency.

- Check out these related blog posts:

- P. Kumar, K. Schmidmayer, F. Topin, and M. Miscevic, “Heat transfer enhancement by dynamic corrugated heat exchanger wall: Numerical study,”
*Journal of Physics: Conference Series*, vol. 745, 2016.

In 1773, André Bordier, a Swiss naturalist, used the term “fluid” to describe the movement of mountain glaciers for the first time. However, it took more than a century for scientists to agree on a unified description for the dynamics of glaciers.

One of the most confusing aspects of glaciers is the observation that ice exhibits both viscous and plastic behavior, depending on the glacier. British physicist John Glen observed and described this intermediate behavior using a nonlinear relationship between stress and strain. Known as *shear thinning*, this classical behavior applies to many different fluids (e.g., ketchup and blood).

The life of any mountain glacier can be schematically described as follows:

- Snow piles up at a high altitude, where the temperature is low, and compresses into ice
- The ice starts deforming and flowing down the slope under its own weight
- The ice melts away at a lower altitude, where the temperature is higher

*Sketch of a typical mountain glacier.*

Thus, we have a dynamical process for the ice, even at steady state (when the snow fall exactly compensates for the melting): *creep*. This fluid model is a standard Navier-Stokes equation with one simplification: the *Stokes (low-Reynolds) approximation*, which neglects the advection term. A typical value for the Reynolds number is *Re* = 10^{-15}, so the assumption undoubtedly holds.

The simulation of viscous flow generally assumes a linear relationship between stress and strain. This assumption describes a *Newtonian fluid*. Many fluids are, indeed, Newtonian in their standard condition (e.g., water and air). However, many fluids exhibit a variation of their viscosity when submitted to shearing. A slightly more general approach is to use a constitutive law to describe the viscosity as a function of a certain power of the shear rate. Mathematically speaking, it is written , where is the shear rate and is classically defined as the norm of the strain rate tensor .

Get more details in these blog posts about non-Newtonian fluids and the non-Newtonian behavior of ketchup.

To completely define the flow law, two parameters need to be evaluated:

- Consistency,
- Stress exponent,
*n*

In the case of ice, it is common to take . However, the viscosity of the ice depends not only on the shear rate but also the temperature and pressure. The consistency is then defined in order to represent these dependencies. A classical way to define the consistency in ice modeling is to use an Arrhenius law (Ref. 1): , where *R* is the perfect gas constant and *T’* is the temperature relative to the pressure melting point.

Indeed, the pressure dependency is reflected through the shift of the ice’s melting point with pressure (which is lowered with increasing pressure). Using the Clausius-Clapeyron relation, we obtain , where is the Clapeyron constant. The values for *A*_{0} and *Q* are a matter of debate. (Ref. 2)

This elegant flow law, established empirically over the years through rigorous lab work, has failed to predict the high velocities observed on real-life glaciers. It took many years to understand what was missing. Consensus was brought about by J. Weertman in the late 1950s with the notion of *basal sliding*.

At an equation level, the basal sliding law of glaciers is not different from the *viscous slip* concept introduced by H. Navier a century earlier, based on molecular interaction considerations. However, the physical process behind this law, in the case of ice flow, is still a matter of debate and is not the subject of this post. Let’s just recall that it is written as , where *u _{t}* is the velocity of the base; is the viscosity (nonlinear here); is the

The *Mer de Glace*, which translates to “Sea of Ice”, is a mountain glacier located in the Mont Blanc massif in the French Alps above the Chamonix Valley. Considered the largest glacier in France, it has been widely observed and monitored because of its considerable moving speed for a valley glacier (around 100 meters per year) and its significant retreat and decrease in size in the past 80 years. Studies show an average loss of 5 meters per year in thickness and 30 meters per year in length.

Below (right) is a sketch of a geometry for a valley glacier, set up using COMSOL Multiphysics and the CAD geometric kernel (available with the CAD Import Module). The geometry approximately mimics the measurements and visuals of the Mer de Glace (left).

*Left: Aerial photo of the Mer de Glace in 1909. Image in the public domain, via Wikimedia Commons. (Annotations added by the author.) Right: Model geometry, colored by thickness.*

Let’s simulate the nonisothermal flow of the ice mass downslope, under its own weight and subject to basal sliding.

In terms of fluid, the inflow and outflow boundary conditions are the normal constraints, corresponding to the applied pressure of the ice, which is not included in the domain. It simply corresponds to an assigned hydrostatic (or cryostatic) pressure. The upstream boundary weighs on the domain, thus contributing to a streamwise velocity, while the downstream boundary resists to the flow. The surface of the glacier is a free surface.

In terms of heat transfer, the surface is considered to be at an ambient temperature. The boundary in contact with the bedrock is normally subject to a geothermal heat flux, which could be modeled as a boundary condition. However, since such a value is spatially varying and generally unknown, a temperature is imposed in the present case. This way, we ensure that the ice remains at a temperature below 0°C, thus avoiding the phase change and latent heat flux contribution. It is worth noting that this aspect could be taken into account using a *Material with Phase Change* interface. Heat is allowed to enter and leave the domain at the inflow and outflow boundaries.

An extruded mesh is used that is consistent with the aspect ratio of the geometry.

The external weather conditions are an important input data for geophysical simulations. Accessing the ASHRAE 2017 database directly through the *Heat Transfer* interface, we can import the average external temperature and wind velocities at a given time of the year for more than 6000 weather stations all over the world. Here, we use the data from the *Grand Saint Bernard* station in the Swiss Alps, located at 16 km of the Mer de Glace, around at the same altitude on the first of February at noon. The ambient temperature is imposed at the glacier surface and the wind velocities are used to simulate a convective heat flux at the surface.

First, we run the simulation without basal sliding to see how much the viscous flow contributes to the observed velocities of the glacier. The results are expected to be around 120 meters per year at the top of the glacier and 90 meters per year at the end of the glacier.

As we can see on the left-hand side of the plot, solely based on the viscous law described here, we get only 50% of the expected velocity.

We can introduce a viscous slip with a slip length *L _{s}* = 250 m and run the simulation again. Below, we plot the velocity at the surface along the central flowline of the glacier for both cases.

Now the velocity is globally much higher and better matches the expected magnitude. It is interesting to note that the viscous sliding does not only introduce a pure shift of the velocities. Indeed, as a function of the nonlinear viscosity, it adds a nonlinear contribution, thus it is not purely rigid. With this value for the slip length, the sliding contributes to around 60% of the velocity at the surface.

Next, let’s move on to the results about the effect of temperature on the ice flow, which is an important coupling in the context of recent climate change studies. To quantify the effect of global warming on the glacier, let’s consider the following experiment. According to data, the temperature has been globally stable between 1940 and 1970, so we can assume that the glacier reached a steady state during this period. Measurements show that the global average temperature has increased by around 1 degree over 50 years. We can thereby simulate the transient flow of ice over these 50 years with the average temperature steadily increasing for a total of 1 degree.

To see the effect of this change in temperature, we can plot the evolution of the mass outflux, in cubic meters per year, at the downstream boundary.

It’s interesting to observe the delay between the beginning of the temperature increase and the beginning of the glacier’s response. The linear temperature increase starts in 1970 and the first significant effects are observed around 8 years later. This delay is mainly due to the time for a temperature change at the surface to propagate through the whole glacier (and thus increase the average temperature in the whole bulk). As a result, the output mass flux increases by around 12% during this period, leading to a net extra ice loss of 10 meters over the period, a 6% increase (compared to the case where temperature would have remained steady).

Let’s compare our results with the data about the Mer de Glace discussed earlier. If the glacier decreases in thickness by 5 meters per year for our domain (5500 meters long and 600 meters wide in average), we get 15 Mt/yr of ice loss per year. Even assuming that all of this ice flux will melt at a lower altitude (which is not the case), the 3 Mt/yr per year computed for 2017 is much smaller than the real mass loss that the Mer de Glace has undergone in past decades. This is because the simulation does not take into account the negative *surface mass balance* (the accumulation of snow minus the melting of ice at the surface).

Surface mass balance, in terms of modeling, is a data input and itself the product of complicated physics. As an example, hotter summers have a very strong effect on glaciers, because the small amount of snow that normally falls in the summer acts as a shield against solar radiation, thereby protecting the glacier from a large part of summer melting. If the summer snowfall does not occur, the melting is then much greater. This extra melting results in large infiltrations of liquid water through crevasses, which eventually form a subglacial hydrological network that plays a significant role in the basal slipperiness, mostly via the lubrication of the ice-bedrock interface and the water pressure “lifting” the glacier.

The fact that the simulation is performed for a given geometry of the glacier, neglecting the evolution of the geometry through the surface mass balance and dynamics, is also important, since the geometry affects the dynamics.

This blog post has presented the setup and solution of a simple glacier flow model with COMSOL Multiphysics. The COMSOL® software offers specialized functionality for most problems involved in such modeling scenarios. The main limitation here, and in glaciology in general, is the data; typically, the topographical data, basal slip length, surface mass balance, accumulation, and melting.

In an upcoming blog post, we will demonstrate how to get the most out of glacier simulations using sensitivity analysis and data assimilation through the Optimization Module. Stay tuned!

*Climate Change 2013: The Physical Science Basis*.*Contribution of Working Group I to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change*, T.F. Stocker et al. (eds.), Cambridge University Press, 2013.- R. Greve and H. Blatter, “Dynamics of Ice Sheets and Glaciers,”
*Springer*, 2009.

The process of natural convection, also called buoyancy flow or free convection, involves temperature and density gradients that cause a fluid (like air) to move, leading to the transport of heat. Unlike forced convection, no fans or external sources are needed to generate fluid flow — just differences in temperature and density.

Natural convection in air has a wide range of applications in various industries. In the electronics field, this phenomenon dissipates heat in devices, which helps prevent them from overheating. Additionally, structures like solar chimneys and Trombe walls take advantage of this heat transport method to heat and cool buildings. The agricultural industry also depends on natural convection, which helps in the drying and storage of various products.

*Natural convection of air through vertical circuit boards.*

With the COMSOL Multiphysics® software, it is possible to study natural convection in air for both 2D and 3D models. Let’s take a look at one example…

The Buoyancy Flow in Air tutorial shows how to model natural convection in air for two geometries:

- 2D square
- 3D cube

In both cases, all of the edges are insulated except for the left and right sides, which are set to a low and high temperature, respectively. The temperature difference (around 10 K) leads to density gradients in the air, generating buoyancy flow. Note that the cube has more sides than the square, which influences how the air flows.

To simplify the model setup, there are a couple of built-in features in COMSOL Multiphysics that we can use. First up is the predefined *Nonisothermal Flow* interface, which couples fluid dynamics and heat transfer in the model. We can also use the Material Library to easily determine the thermophysical properties of air.

Next, we can estimate the flow regime by computing the Grashof, Rayleigh, and Prandtl numbers. The Grashof and Rayleigh numbers suggest that the flow is laminar, with a velocity of around 0.2 m/s. As for the Prandtl number, it indicates that viscosity doesn’t influence the buoyancy of the air and that the shear layer thickness is about 3 mm.

For more details on estimating the flow regime, download the model documentation from the Application Gallery.

*Note: The Buoyancy Flow in Water tutorial model demonstrates a similar model setup with water instead of air.*

Let’s take a look at the results, starting with the velocity magnitude of air in the 2D square. In the left image below, we see that the velocity increases as the air nears the left and right edges, with a maximum velocity of 0.05 m/s. While this is a bit lower than the estimated velocity calculated using the Grashof and Rayleigh numbers, it is still in the same order of magnitude. Further, the shear layer thickness (3 mm) corresponds with the estimate from the Prandtl number.

*The velocity magnitude (left) and velocity profile (right) of air in the 2D square.*

As shown below, the results for the velocity magnitude in the 3D cube are similar to those for the 2D square.

*Velocity magnitude in the cube.*

Next up, let’s look at the temperature results for the 2D geometry. A single convective cell fills the square, with the air flowing around the edges. We see that the flow of air is faster at the left and right sides, where the temperature differences are the greatest.

*The temperature field in the square.*

The 3D results show a slightly different scenario. There are small convective cells in the cube at the corners of a vertical plane perpendicular to the heated sides. As mentioned, this difference is likely due to how the front and back sides in the cube affect the airflow.

*The temperature and velocity fields in the 3D cube.*

The model geometries in the Buoyancy Flow in Air tutorial are rather simple, but the example provides you with a solid foundation for modeling natural convection in more detailed models that represent real-world applications.

For more details about this example, go to the Application Gallery via the button above. From there, you can download the MPH-file and step-by-step instructions on how to build the model.

]]>

Let’s consider a buoyant sphere that is dropped into a water-filled beaker. The sphere, with a radius of 0.15 cm and density of 800 kg/m^{3}, is initially suspended in air. The cylindrical beaker has a radius of 0.65 cm, a height of 1.7 cm, and is partially filled with water. The size of the system is small enough to assume laminar flow and also allows for a faster solution process on a regular PC. A larger system can be modeled in exactly the same way, but would require more computational resources.

To model the motion of the sphere through the water surface, we need to model the fluid flow in both the air and water phases. If we consider the sphere to be rigid, we can compute the motion of it by solving the ordinary differential equations (ODEs) of motion that account for the force experienced by the sphere falling through the air, hitting the water surface, and finally interacting with both air and water. The total fluid stress exerted by the fluids on solid boundaries is given by

(1)

\mathbf{f} = \mathbf{n} \cdot \left\{ -p\mathbf{I}+\left(\mu\left(\mathbf{\nabla} \mathbf{u}_{\text{fluid}}+\left(\mathbf{\nabla} \mathbf{u}_\text{fluid}\right)^{T}\right)-\frac{2}{3}\mu\left(\mathbf{\nabla}\cdot\mathbf{u}_{\text{fluid}}\right)\mathbf{I}\right)\right\}

where u_{fluid} denotes the fluid velocity field, *p* the fluid pressure, μ the dynamic viscosity of the fluid, **n** the outward normal to the boundary, and **I** the identity matrix.

*Buoyant sphere suspended in air above the water surface in a water-filled beaker. Part of the beaker wall has been hidden to show the sphere.*

Assuming that the solid only moves in the vertical direction (z), we can write

(2)

\begin{align}

F_z &= m g + m\frac{d v_{s}}{d t}\\

v_s &= \frac{d u_s}{d t}

\end{align}

F_z &= m g + m\frac{d v_{s}}{d t}\\

v_s &= \frac{d u_s}{d t}

\end{align}

where *m* denotes the mass, *v _{s}* the velocity in the

The force *F _{z}* can be calculated by integrating the

Since the sphere moves through both air and water, a two-phase flow model is formulated on a *spatial frame* with time-dependent spatial coordinates to model both fluids. The spatial frame is the usual fixed global Euclidean system with spatial coordinates (*x*, *y*). These spatial coordinates, corresponding to the mesh nodes of the fluid domains, are functions of time and represent the current location of a point in space. This is achieved by solving the fluid flow problem on a *Moving Mesh* interface.

The mesh, on which the fluid flow problem is solved, deforms with a mesh deformation that is equal to the displacement of the sphere at the interfacing boundaries between the sphere and the fluid domains. Inside the fluid domains, the mesh deformation is computed using an appropriate smoothing method that is available in the *Moving Mesh* interface.

(3)

\left.\mathbf{u_{\text{mesh}}}\right|_{\text{Interfacing boundaries}} = \left(0,u_{\text{s}}\right)

On the fluid boundaries interfacing the sphere, the fluid velocity is given by

(4)

\left.{\mathbf{u}_{\text{fluid}}}\right|_{\text{Interfacing boundaries}} = \left(0,v_s\right)

We can set up the above problem as a 2D axisymmetric analysis. To model this problem, we couple a *Two-Phase Flow* interface with a *Moving Mesh* interface and *Global Equations* by defining the coupling expressions illustrated in Eqs. 1–4.

*Geometry of the 2D axisymmetric model showing the initial position of the water surface represented by the horizontal line. The sphere is represented as a boundary in the model domain because we are modeling it as a rigid object using ODEs.*

The fluid flow in this case is laminar, in both the air and water phases, so we can use the *Laminar Two-Phase Flow, Phase Field* interface. (Read this blog post on how to choose a multiphase flow interface for more information.) This multiphysics interface automatically defines a coupling between the laminar flow and phase field method, which is used to track the detailed shape of the water surface.

The *Laminar Two-Phase Flow, Phase Field* interface enables us to model the boundaries of the sphere as moving wetted walls. The *Wetted Wall* boundary condition of the *Phase Field* interface lets us specify the contact angle between the water surface and the solid walls, while the *Wall Movement* setting in the *Wall* boundary condition of the *Laminar Flow* interface lets us specify the velocity of the moving solid walls. An *Outlet* boundary condition is used for the boundary corresponding to the top of the beaker.

The structure of the model setup and the various interfaces — namely *Laminar Flow*, *Phase Field*, and *Moving Mesh* — is shown in the screenshot below:

In the *Phase Field* interface, we specify the value of the phase field variable as Φ = 1 (air for Fluid 1) and Φ = -1 (water for Fluid 2) for the initial configuration, along with the boundary representing the initial position of the water surface with the air above and the water below the horizontal line. The initial configuration is shown in the figure above.

We use a *Wetted Wall* boundary condition to specify the contact angle between the air-water interface, solid walls of the beaker, and sphere. For simplicity, we assume the same contact angle for both the sphere and walls of the beaker.

The velocity field in the fluids is automatically coupled to the phase field method to account for advection. The properties of the fluids and surface tension coefficient are specified in the multiphysics coupling between the *Laminar Flow* and *Phase Field* interfaces.

The *Moving Mesh* interface solves for the mesh deformation within the fluid domains due to movement of the sphere. We also use boundary conditions to describe how the mesh at the fluid boundaries should deform. The important boundary condition here is *Mesh Displacement*, which is equal to the sphere’s displacement on the spherical boundaries (Eq. 3).

The movement of the sphere is purely due to the gravitational load. However, the fluid exerts a drag force as defined by Eq. 1. The *z*-component of this force can be computed by integrating the built-in variable for total fluid stress in the *z* direction over the sphere boundaries. The built-in variable `spf.T_stressz`

computes the total stress in the *z* direction that is exerted on the sphere boundary by the surrounding fluid.

Learn more in this blog post on how to compute lift and drag.

The ODEs (Eq. 2) are solved using the *Global Equations* interface. The screenshot below shows one of the equations implemented in the *Global Equations* interface, where *vs* is the velocity of the sphere as noted in Eq. 2, *vst* is the time derivative of velocity (or the acceleration), and intop1 is an integration operator defined over the solid boundaries.

*Settings of the* Global Equations *interface used to solve for the velocity of the sphere.*

Since there is a large movement of the sphere, the mesh deformation will be large. To help keep the element quality high and avoid inverted elements, we can use the *Automatic Remeshing* feature, which stops a transient simulation based on a mesh quality metric and remeshes the current deformed shape before it continues.

The plot below shows the sphere falling on the water surface, the water-air interface (Φ = 0.5), and a cross-sectional plot of the fluid velocity magnitude.

*Animation of the movement of the buoyant sphere in the water-filled beaker, the water surface, and the fluid velocity magnitude plotted on a cross-sectional slice. To see the variation in velocity magnitude at later stages of the simulation, the maximum value of the color scale is capped at 0.1[m/s].*

The figure below shows the plot of the displacement of the sphere versus time. As expected, its motion is damped by the fluid surrounding it and the displacement amplitude decreases exponentially with time.

In this blog post, we have demonstrated how to model the oscillating motion of a buoyant sphere. Here, the sphere and its motion are considered axisymmetric with no rotational motion. In general, should the situation require, the same strategy discussed here can be applied to model both rotation and translation. Modeling such a case would require solving for additional rotational motion of the rigid object using ODEs. It would be much easier to instead use the built-in functionality of the *Solid Mechanics* interface to automatically solve for the rigid body motions. This would also allow for modeling a larger system where the flow becomes turbulent and the motion can take place in all directions.

Access the file for the model featured in this blog post by clicking the button below:

]]>

To keep the model simple and take advantage of the symmetry of a balloon, we can build a 2D axisymmetric geometry that consists of only a rectangle and an ellipse, together with slightly larger double versions to account for the rubber balloon. Our goal is to see what happens if we let the same amount of water into different-sized balloons. To do so, we can parameterize the geometry and use a scaling factor to change the initial size of the balloon, while the material thickness and the neck radius remain constant.

*Geometry of two deflated water balloons of different sizes. The size is controlled by the stretching factor* fact: fact = *1 (left) and* fact = *2 (right).*

The water balloon model makes use of new features in version 5.3a of COMSOL Multiphysics, including improved fluid-structure interaction (FSI) functionality and a realigned moving mesh.

As of COMSOL Multiphysics version 5.3a, FSI is modeled via a *Multiphysics* node. The node connects the physics from *Fluid Mechanics* and *Structural Mechanics* interfaces. In contrast to earlier versions of the software, where there was a separate *Fluid-Structure Interaction* interface, we can now use all of the available features from the two-way coupled physics.

*The interfaces and the moving mesh after adding the FSI physics.*

In this example, it is easy to take gravity into account. All we need to do is place a checkmark in the *Laminar Flow* interface settings. This activates the gravity of the earth, which in turn has an effect on the mechanical behavior due to the hydrostatic pressure in the water. We can expect that there will be a noticeable effect of gravity on the results, and this effect will be more significant in the larger water balloon, because there is more mass in the beginning.

On the mechanical side, the physics settings can likewise be set up quickly. We only have to define a suitable material model that describes the hyperelastic properties of the material of the balloon correctly. In the Application Library, the Inflation of a Spherical Rubber Balloon model contains a variety of hyperelastic materials. We can use the Ogden model here, because it reproduces the analytical solution most accurately.

Interested in details about fitting measured data to different hyperelastic material models? Check out this previous blog post.

By the way, copying model interfaces between different models is now very simple. Since version 5.3a of the COMSOL® software, interfaces and components can be exchanged via the copy-paste functionality — even between two running COMSOL Multiphysics® simulations! This means that we can efficiently insert material settings from another model into the water balloon model.

*Parameters of the hyperelastic Ogden material model used for the balloon.*

Another improvement in COMSOL Multiphysics version 5.3a is the new positioning of the *Moving Mesh* interface. It is now found at a more prominent position under *Definitions*. One advantage of the new structure is that it helps avoid accidental overlaps between deforming and nondeforming areas. For the water balloon model, this improvement means that we have only two tasks for the mesh: selecting the balloon’s interior water as a *Deforming Domain* and adding a *Prescribed Normal Mesh Displacement* on the symmetry axis (to avoid unwanted movement away from this axis due to numerical inaccuracies).

The final step before solving the water balloon model is to set the water flow timing. Turning the tap on and off quickly with a defined amount of time in between can be expressed by a rectangle function. This function is multiplied to the inlet velocity of 15 cm/s, creating a flow of about 1.4 l/min.

*The water inlet velocity is controlled via a rectangle function.*

We can carry out a parametric sweep study to compare the simulation results for three different initial balloon sizes. All three balloons are filled with the same amount of water because the inlet velocity and the filling time period are the same. By far, the largest stress occurs in the smallest balloon. This is as expected, because the small balloon has the smallest surface and the largest relative volume increase.

*Von Mises stress distribution in the balloon material after inflation for three different initial sizes. (Note: These plots were created with the Cividis color table, a color table that is optimized for people with color vision deficiency, new as of COMSOL Multiphysics version 5.3a.)*

These results call for some animations! If we take a look at the transitional behavior of the inflation, we clearly see the influence of gravity on the largest balloon, because it oscillates before the water injection even starts. There is no prestress in the balloon, so it starts falling down a bit until the counterforce from the material is large enough to compensate for the gravity.

*Animation of the von Mises stress in the smallest water balloon during inflation.*

*Animation of the von Mises stress in the medium-sized water balloon during inflation.*

*Animation of the von Mises stress in the largest water balloon during inflation.*

The FSI functionality in COMSOL Multiphysics version 5.3a includes useful enhancements and is more user friendly than in previous software versions. With surprisingly little effort, it’s possible to set up a complex FSI model and solve it in a short time.

I am very curious to see how you use these new features to master your modeling challenges!

]]>

Optogenetics is a neurological procedure in which light stimulates genetically modified photosensitive neurons to transmit electrical nerve impulses. Unlike with electrical probes, optical probes can target neurons precisely without damaging the surrounding brain tissue.

*A close-up view of optogenetics. Image by S. Berry and taken from his COMSOL Conference 2017 Boston presentation.*

How does optogenetics work? Neurons are genetically modified to release light-sensitive membrane proteins, making the brain susceptible to selective photoexcitation. When stimulated by light, these proteins transport ions into (or out of) the targeted neurons, which excites electrical responses that trigger nerve impulses in the brain.

As the functions of the brain are vast, so are the behaviors and treatments that optogenetics can facilitate. For instance, optogenetics can be used to treat neurological and psychiatric disorders like depression and schizophrenia — a significant improvement over controversial early treatments like lobotomies and electroconvulsive therapy (ECT).

Optogenetics can potentially be used to treat Parkinson’s disease, a degenerative brain condition that affects the central nervous system and causes tremors and shakes. Also, when testing the effect of optogenetics on laboratory mice, researchers found that it can treat heart arrhythmia and hearing loss.

*Optogenetics could help treat this mouse’s heart arrhythmia.*

In a more experimental application, researchers are looking into how optogenetics can help us understand the formation and consolidation of memories. Optogenetics could change the way we perceive and catalog past experiences. Think of the 2004 science fiction film *Eternal Sunshine of the Spotless Mind*: A couple experiences a tumultuous breakup and undergoes a procedure that erases all memories of their relationship, only to meet and start dating again as “strangers”.

A research team from MIT aimed to optimize the design of an optical probe using simulation. Their probe design includes a microlens with a liquid-liquid interface of oil and water. The lens must be able to provide both active focusing and beam steering in a single optical element in order to deliver light from the probe to the neurons. The researchers used the COMSOL Multiphysics® software to analyze the size of the liquid microlens as well as the angle and depth of its taper. They presented their findings at the COMSOL Conference 2017 Boston, where they won a Best Paper award.

*A schematic of the microlens design. Image by S. Berry and taken from his COMSOL Conference 2017 Boston presentation.*

The optical probe’s microlens can achieve both focusing and steering through the *electrowetting effect* in which electrodes are used to focus the lens and direct the light to the targeted cell.

The researchers modeled two-phase flow in the microlens using the level set method in COMSOL Multiphysics. This method helped them determine the location of the fluid interface and define the fluid domain. These initial results were used to simulate the fluid motion in the lens over time.

For the first time-dependent simulation, the same voltage was applied to the left and right taper walls (V_{L} and V_{R}) to find the resulting contact angles. When comparing the contact angle to the applied voltage, the researchers were able to see which taper angles (α) and voltages (V) cause concave and convex liquid-liquid interface profiles. Concave profiles result in a negative optical power for the probe, while convex profiles lead to a positive optical power.

*Equal voltage is applied to the left and right walls of the taper. Different voltages for a taper angle of 45° cause convex, concave, and flat liquid-liquid interface profiles. Image by S. Berry, S. Redmond, P. Robinson, T. Thorsen, M. Rothschild, and E.S. Boyden and taken from their COMSOL Conference 2017 Boston paper.*

Next, the research team turned their attention to the focusing of the probe. They used simulation to analyze the lens size, liquids that make up the lens interface, and voltage through electrowetting. The results show that a steeper taper angle causes a smaller dynamic range for the operating voltage. For instance, for a 75° taper angle, the microlens only has a positive optical power between 34 and 40 V.

*With a taper angle of 75° (red line), the microlens must operate between a range of 34 and 40 V to have a positive optical power. Image by S. Berry et al. and taken from their COMSOL Conference 2017 Boston paper. The data points are calculated from the simulations while the curves are interpolated to the simulation results.*

The third simulation dealt with focusing and steering combined. To happen simultaneously, these effects require the liquid microlens to be curved. With a curved shape, the lens can maintain a spherical profile while being shifted. To study the profile, a fixed voltage was applied to V_{L} and a voltage sweep was applied to V_{R}. The results highlight the importance of the taper cavity’s geometry as well as the ability to apply different voltages to the taper’s different walls.

*Liquid-liquid interface profiles for microlenses with different taper angles and different voltages applied to each side of the taper. Image by S. Berry et al. and taken from their COMSOL Conference 2017 Boston paper.*

As the taper angle neared 90°, the researchers observed that the liquid-liquid interface became flat and acted like a prism. If the sole goal was beam steering, this would be an ideal behavior — but optogenetics requires both beam steering and focusing.

To determine the operational space of the liquid microlens, the researchers compared the steering angle and focal length of the lens. Both of these values were calculated with the radius of curvature from the liquid-liquid interface profile found via the simulation, combined with the ray transfer matrix method.

*Operational space for the optical probe with a 15° (left) and 45° (right) taper angle. Image by S. Berry et al. and taken from their COMSOL Conference 2017 Boston paper. The optical probe with a 15° taper angle gives a larger steering angle and a lower minimum focal length than the one with a 45° taper angle, which suggests that the probe with a 15° taper angle is the superior design. Unfortunately, the better design is also difficult to manufacture.*

With these simulations, the research group learned about the behavior of the microlens when the geometry and operating conditions change. Using models and simulations, the team arrived at a decent design that was relatively easy to manufacture. They plan to use these analyses as a starting point for more complex research into optical probe microlenses, including performing 3D simulations of their optical probe designs beyond 2D models. With an optimized probe for optogenetics, we could see advanced brain research and treatment in the near future.

Get more details in the full paper from the COMSOL Conference 2017 Boston: “Liquid Microlenses with Adjustable Focusing and Beam Steering For Single Cell Optogenetics“

]]>

Drilled shafts are deep foundation elements that are both cost effective and high performing. They can be used in a variety of soil strata with minimal noise and vibration issues. Due to these benefits, drilled shafts are used to support heavy structures around the world.

*Schematic of a drilled shaft in use. Image by J. Asirvatham, A. E. Tejada-Martinez, and G. Mullins and taken from their COMSOL Conference 2017 Boston presentation.*

Drilled shafts are simple structures, consisting of deep cylindrical holes drilled into soil or rock. Often, construction workers use a drilling fluid or slurry to maintain the hole’s stability during the excavation process. They do so by pumping an amount of slurry that is equal to the removed soil into the excavated hole.

When the hole reaches a required depth, a reinforced steel (rebar) cage is added. The excavation hole is then filled with concrete via a long pump truck hose or tremie. This device pumps the concrete into the bottom of the hole, preventing it from mixing with the slurry.

*The main stages of the drilled shaft creation process: Drilling the excavation hole (left), inserting the rebar cage (middle), and filling the hole with concrete (right). Images by J. Asirvatham, A. E. Tejada-Martinez, and G. Mullins and taken from their COMSOL Conference 2017 Boston presentation.*

In an ideal situation, concrete effortlessly displaces the lighter slurry as it fills the excavation hole. However, this is not always the case in reality. Different rebar cage shapes and placements change how concrete rises as well as generate head differentials between the concrete inside and outside the cage. The kinematics of the concrete flowing into the excavation hole can also cause anomalies. For instance, a poor flow of concrete from the tremie can produce a drilled shaft that is lower quality across the entire cross section and depth.

*Left: Comparison of an idealized concrete flow to an actual concrete flow in situations involving a drilling fluid or slurry. Right: An anomaly caused by poor concrete flow performance. Images by J. Asirvatham, A. E. Tejada-Martinez, and G. Mullins and taken from their COMSOL Conference 2017 Boston paper and presentation, respectively.*

When performing experimental tests to investigate these issues, a research team from the Department of Civil and Environmental Engineering at the University of South Florida noted that the flow pattern of concrete into drilled shaft excavation holes has a large influence on the properties of the hardened cast of the drilled shaft. In addition, they saw that the placement of the reinforced steel cage could cause anomalies in the form of creases.

To achieve a concrete flow that properly fills a drilled shaft hole, the research team decided to simulate the drilled shaft concreting process. We take a look at this work below.

For their study, the team created a preliminary 2D axisymmetric drilled shaft model consisting of a rectangular element that is 7 feet deep with a 4-foot diameter. At the center of the model is a tremie pipe with a 10-inch diameter. Surrounding this pipe are rebars, which take the shape of vertical elements with gaps. The model can account for the rheological properties of the concrete, the potential structural blockages, and the two-phase flow of:

- Concrete flowing from the tremie pipe
- Slurry being displaced by the concrete and flowing out of the excavation hole

The researchers used a level set method, included in a two-phase flow interface in COMSOL Multiphysics, to compute the motion of the interface between the concrete and slurry.

*Drilled shaft model geometry. Image by J. Asirvatham, A. E. Tejada-Martinez, and G. Mullins and taken from their COMSOL Conference 2017 Boston paper.*

With this model, the team simulated the flow patterns and volume fraction of concrete and slurry over a 4-minute time period. They also calculated the head differential between the inside and outside of the rebar cage.

At the beginning of the time period, the concrete (depicted as red in the plots below) remains within the tremie, while the slurry (depicted as blue) fills the rest of the excavation hole. As time progresses, concrete begins to flow out of the tremie and move vertically up within the rebar cage. After developing the required head, the concrete starts to flow radially out of the rebar cage and spreads into the annular space. This continues as concrete fills more and more of the excavation hole, displacing the slurry. However, the concrete does not fill the space evenly, resulting in a head differential between the inside and outside of the rebar cage.

*Non-Newtonian simulation results, showing the volume fraction of the concrete (red) and slurry (blue) at different times. Images by J. Asirvatham, A. E. Tejada-Martinez, and G. Mullins and taken from their COMSOL Conference 2017 Boston paper.*

The non-Newtonian simulations calculate a head differential of 0.35 meters (14 inches), which is within the observed experimental range of 0.20 to 0.40 meters (8 to 16 inches). On the other hand, the Newtonian simulations show a difference of 0.90 meters (36 inches), which is higher than the observed range. Thus, the non-Newtonian flow model is more appropriate for this concrete flow simulation and demonstrates that simulation can successfully calculate the concrete head differential in a drilled shaft.

The researchers used their preliminary simulation results to predict how the concrete flow velocity and rebar spacing affect the concrete head differential between the inside and outside of the rebar cage. Here, the researchers found that the differential increases as the concrete velocity rises and when the clear spacing of the rebar is reduced.

The initial 2D axisymmetric model results are promising because the calculated flow patterns are consistent with the observations from the project site. In the future, the researchers want to examine how this process is influenced by the size of the drilled shaft and the design of the rebars. They plan on expanding their model to 3D to further study the concreting process.

These models can help to determine the ideal rheological properties and optimized workability of fresh concrete so that it can better fill a drilled shaft with a given size and rebar arrangement.

- Check out the full paper: Numerical Modeling of Concrete Flow in Drilled Shaft Construction
- Read these related blog posts:

Before we do anything else, let’s pour some 90°C coffee into a vacuum flask and consider the material properties of the model.

Materials involved:

- The coffee is represented using material properties of water
- The screw topper and insulation ring are both made of nylon
- The flask is made up of two stainless steel walls with a plastic foam filler in between (the inner gap in vacuum flasks is usually filled with evacuated air, but it may also contain foam)

All material properties except for the foam filler can be pulled directly from the Material Library in the COMSOL Multiphysics® software. As always, when using COMSOL Multiphysics, you can add special material properties manually into the software. In the case of the foam in this example, you would enter the following values:

- Conductivity: 0.03 W/(m·K)
- Density: 60 kg/m
^{3} - Heat capacity: 200 J/(kg·K)

Tip: The modeling approaches mentioned here are both covered in the Natural Convection Cooling of a Vacuum Flask tutorial model. Please refer to the tutorial MPH-file and accompanying documentation to see exactly how to set up and solve this model, because we won’t go into detail in this blog post.

For a quick and simple model, you can describe the thermal dissipation using predefined heat transfer coefficients. This method should help us determine how the coffee cools over time inside the vacuum flask. It’s simple because it *won’t* tell us anything about the flow behavior of the air around the flask, and it’s useful because it *will* show us the cooling power over time.

Instead of computing heat transfer and flow velocity in the fluid domain, you would simply model the heat flux on the external boundary of the vacuum flask, defined from the heat transfer coefficient, the surface temperature, and the ambient temperature (25°C; a little warmer than standard room temperature):

*q* = *h*(T_{∞}-T)

There are many predefined cases where *h* is known with high accuracy. The Heat Transfer Module (an add-on to COMSOL Multiphysics) includes a library of heat transfer coefficients for easy access.

Another time-saver with this method is the fact that you can avoid predicting whether the flow is turbulent or laminar, because many correlations are valid for a wide range of flow regimes. As long as you use the appropriate *h* correlations, you can typically arrive at accurate results at a very low computational cost with this method.

What about the second approach? It’s worth considering how the cooling power is distributed on the flask surface as the coffee cools down. To do so, you need to include surrounding fluid flow in the model.

To get a more complete picture of what’s going on with our precious java (seriously, when can I drink it?), we could create a more detailed model of the convective airflow outside the vacuum flask.

Taking the second approach calls for using the *Gravity* feature available in the *Single-Phase Flow* interface with the Heat Transfer Module or the CFD Module, which allows you to include buoyancy forces in the model. Typically, you would first need to figure out whether the flow is laminar or turbulent before following this modeling approach. For the sake of brevity here, let’s skip ahead: we know from the tutorial model documentation that the flow is laminar in this case.

The detailed model shows that the warm flask drives vertical air currents along its walls. The currents eventually combine in a thermal plume above the flask and air in the surrounding area is pulled toward the flask, feeding into the vertical flow. (This flow is weak enough that there are no significant changes in dynamic pressure.)

The vortex that forms above the flask’s lid reduces the cooling in that region — something you can’t tell from the first method. In essence, the fluid flow model is better at describing local cooling power than the simple method with the approximated heat transfer coefficient.

So how long will the coffee stay warm in the vacuum flask? Many coffee drinkers like to stay within the range of 50–60°C (roughly 120–140°F), because it’s supposedly when the “coffee notes shine.” Both methods suggest that after 10 hours inside the flask, the coffee will be about 54°C, which is still within the enjoyable range. Of course, if we were to bring the flask outside in cooler temperatures than the assumed 25°C, the coffee would cool down quicker.

*A plot of the coffee temperature over time for the two modeling approaches. The blue line denotes the first approach and the green line denotes the second approach.*

Though both modeling approaches give very similar results in terms of the coffee temperature over time, it’s a different story when looking at the flask surface’s cooling power:

*A plot of the heat transfer coefficient for the two modeling approaches. The blue line denotes the first approach and the green line denotes the second approach.*

For fast *and* accurate results in the long run, you can combine the two approaches. After setting up the more detailed model, you can create and calibrate functions for heat transfer coefficients to use later, via the simpler approach for solving large-scale and time-dependent models.

We saw that there are two different ways to model the convective cooling of coffee inside a vacuum flask over time. The detailed approach is more computationally demanding, as it combines heat transfer and fluid flow, but it’s also more accurate in the sense that it accounts for local effects. By combining both methods, you can save time in the future.

Try it yourself by downloading the tutorial model from the online Application Gallery or within the Application Library inside the COMSOL Multiphysics software. If you have any questions about this model or the COMSOL Multiphysics software, please contact us.

]]>