Maintaining the Continuity of the Fields and Balancing the Fluxes Between Aligned Elements

The basic theory behind the finite element method (FEM) has been covered several times (such as in this blog post on the weak form), so we won’t go over it all here. Instead, we will review one key point: What happens at the interface between different finite elements? In short: When the standard FEM is used, adjacent aligned elements share the same node points (the node points are the points at which the solution to the problem is computed). Since these elements share nodes, the fields being solved for (such as temperature, solid displacement, fluid velocity, etc.) are automatically continuous.

Fluxes are automatically balanced between elements of different domains and these elements share the same nodes, so the fields are continuous.

Furthermore, the fluxes are naturally enforced to be equal (although this requires a bit more thorough understanding of the derivation of the FEM). Now, the term flux can refer to different quantities, depending upon the physics we are working with. For brevity, we will just consider heat transfer, where we naturally speak of the heat flux, which is the thermal conductivity times the negative of the gradient of the temperature field, or . At boundaries between elements, the FEM automatically (that is, without needing any user input or additional internal equations) enforces the condition that , where is the normal vector to the boundary between elements. That is, the standard FEM naturally enforces the continuity of the fields and balances fluxes. Do keep in mind that, regardless of this, you will always need to do a mesh refinement study to gain confidence in the overall accuracy of your model.

Schematic of a submodel of a cross-flow heat exchanger.

Let’s now take a look at a sample model from the Application Gallery, the Cross-Flow Heat Exchanger, which is schematically pictured above. This is a submodel of a larger heat exchanger consisting of straight rectangular channels. The fluid flow through the channels is modeled, as is the temperature field in the fluid and the surrounding solid. The temperature field is plotted below. The temperature is also plotted along a representative line along the length of the flow channel. Observe from these plots that the temperature variation along the flow channel is varying quite slowly along the length, quickly over the cross section of the flow channel, and in a quite complicated way through the metal part.

Temperature field at the walls and isosurfaces of temperature in the solid (top) and the plots of temperature along the flow channel directions (bottom).

The mesh is plotted below, and we can see that it is continuous between the fluid domain and the solid domain. The mesh is composed primarily of tetrahedral elements, with a boundary layer mesh applied on the fluid side of the channel walls to resolve the high velocity and thermal gradients near the wall.

Default mesh of the cross-flow heat exchanger that is continuous between the fluid and solid.

Now, this default mesh is generated with no user interaction at all. But what if we wanted to manually build the mesh, and what if we allowed the mesh to be discontinuous — what could we do then? Before we get to how to implement that, let’s take a look at what the software will need to do.

Maintaining the Continuity of the Fields and Balancing the Fluxes Between Nonaligned Elements

Suppose we have a set of elements on two adjacent domains, as shown in the image below. The elements have adjacent boundaries, but the nodes are nonaligned. This kind of mesh is automatically generated when the Form Assembly geometry finalization step is used. The meshes of separate objects will not be connected, so as a consequence, the fields across this boundary will be as discontinuous, with no flux between the domains.

For nonaligned meshes, additional equations must be introduced to approximately balance fluxes and fields.

However, the Form Assembly operation can also automatically create so-called Identity pairs at the adjacent boundaries between objects. Within each physics, you can then apply boundary conditions to these pair boundaries. Depending upon the physics interface, different boundary conditions will be available, but in all cases, the Pair Continuity condition will be available. This condition enforces the continuity of the fields, and the fluxes, across the boundary in an element-averaged sense. It does so by adding an additional set of equations behind the scenes, which we won’t go into here. Since the elements are not exactly aligned, the fields and fluxes cannot be pointwise continuous, which is a drawback; however, we can now have different meshes in adjacent domains, which has advantages. Let’s look at how this benefits us in the case of this cross-flow heat exchanger.

As we saw earlier, the temperature variation along the flow channel is quite gradual. Since the flow is laminar and the channels are uniform in cross section, we also know that the flow field is nearly invariant along the flow directions. Therefore, we can apply a swept mesh in the channels along the direction of the flow, as shown in the image below. Observe that far fewer elements are used in the flow direction, thereby reducing the problem size with only a small loss in accuracy as compared to the previous mesh.

With assembly meshing, a swept mesh in the fluid channels allows for an elongated mesh with fewer elements.

Now, there are a few additional manual steps that we have to take to set up this mesh. First, within the Geometry sequence, we have to define two different objects. The first object is the metal part, the solid through which the fluid flows. The second object is the combination of all of the fluid flow domains; that is, a single object that is composed of several different domains, which are created via Boolean Union operations in the geometry sequence. We do need to ensure that these domains are nonoverlapping for the Form Assembly finalization operation to be valid, and then the software will automatically recognize all mating faces between these objects as identity pairs.

The Form Assembly geometry finalization that automatically creates Identity pairs.

Next, within the Heat Transfer in Solids and Fluids interface, we need to add a Pair Continuity boundary condition. Since we only have two adjacent objects (the solid and all of the fluid domains), this condition needs to be applied just to a single Identity Boundary Pair. No other changes to the physics are necessary.

The Pair Continuity boundary condition that enforces continuity of fields and balances fluxes.

Finally, the Mesh sequence has to be manually modified. The default meshing sequence will copy the elements on the mating faces of the pair boundary, but we will want to disable this and apply a swept mesh that is elongated along the length of the flow channels. Since we know the solution varies quite gradually in this direction, the modification is justified. No other significant changes are made to the mesh, as compared to the automatically generated mesh shown earlier.

The meshing sequence used to control the number of elements along the flow directions in the channels.

The temperature field and the difference in the temperature field are plotted below. The model using the swept mesh is, of course, going to be different. In this case, the temperature field differs by about 2°C in some regions compared to the previous case. This difference is primarily due to the difference in the mesh across the interface. It is not due to the additional pair continuity equations. In the limit of mesh refinement, both approaches will converge to the same solution. The primary advantage of using assembly meshing is that you can begin with a relatively coarser mesh that will still give reasonable results, thereby saving time and computational resources in your initial model development.

Temperature field (top) using assembly meshing and the difference in this temperature field (bottom) as compared to the default mesh.

In the case of this geometry, we could also divide our geometry in a different way. We could split our model up into two objects along the plane between the flow channels, as shown in the image below. Now, we can lower the element count even more. Although not all geometries lend themselves to this subdivision, this approach can even further reduce the element count.

An alternative meshing strategy would introduce the identity pair within the solid rather than at the fluid-solid boundary.

Closing Remarks

We have shown here that assembly meshing is a useful technique for reducing the number of mesh elements. This is particularly applicable for conjugate heat transfer problems, since these often contain relatively uniform flow channels that lend themselves to swept meshing. Although here we have considered a model involving laminar flow, this approach will also work for turbulent flow problems. Keep in mind, though, that this technique has its place in preliminary model development: You’ll usually want to verify these models against a model with a congruent mesh and, of course, always do a mesh refinement study. The key advantage is that you can more quickly do preliminary analyses.

The model using the assembly meshing capability is available for download here:

• Using Assembly Meshing for Conjugate Heat Transfer Modeling

The Example: Laser Heating of a Flat Plate

Let’s consider the case of a flat plate of material that is being heated by a laser heat source. The plate is centered at the origin, as shown in the figure below, and we want to heat its surface at varying locations over time. Suppose that the laser (or the workpiece) is mounted on a stage that provides positional control of the focus point. Let’s also assume that there are some optics that shape the beam profile of the laser, so the heat source is spread over a small area around the focus.

Schematic of a laser heat source traversing over a workpiece.

Now, let’s look at several different ways in which we can define the moving focus point to follow a known tool path.

Method 1: Using Variables

The simplest approach is to use a set of variables to define the position of the focus and distribution of the heat load over time. Let’s say that we want to have a 1-kW total heat load moving in a 40-cm radius circular path every 10 s. Furthermore, the heat load has a Gaussian intensity distribution with a 5-cm waist radius. We can define this information using variables, as shown in the screenshot below.

The first four definitions, Rb, P0, Rp, and T0, are actually just constants. If we would like to alter any of these definitions via a parametric sweep later on, we could also define them as Global Parameters. For now, it is simplest to just show them all in one place.

The next two variables, x_focus and y_focus, are not constant: They vary as a function of time, the built-in variable t. We can see that these variables describe a point moving on a circular path about the origin as:

Rp*cos(2*pi*t/T0)

Rp*sin(2*pi*t/T0)

The next variable, R, is a function of time and space. It makes use of the coordinate variables x and y, as well as x_focus and y_focus, which we just saw are functions of time. So at each instant in time and at every point in space, this variable tells us the distance (in the xy-plane) from the laser focal point.

The last variable, HeatFlux, is a function of R and the constants. It defines a Gaussian intensity profile about the focal point such that the total heat flux equals the defined power. It is this variable, HeatFlux, that we enter as a boundary condition, as shown in the screenshot below.

This prescribed heat flux expression then gives the heating profile path visualized below.

A circular heating profile set up via the Variables node.

Method 2: Using Interpolation Functions

So far, this isn’t very complicated; just a few expressions. But we can replace the simple expressions for x_focus and y_focus with something more general. COMSOL Multiphysics provides a variety of built-in functions in the software. For our discussion here, the most useful is the Interpolation function, which lets us read in data from a text file. Let’s suppose we have a text file containing rows of data of time and the x- and y-locations of the laser focus at that time. A sample of such a file is shown below:

Such data can be read in to the Interpolation function using the settings shown below. Note that there is just a single argument here, time, and the two columns of data after that represent the x-focus and y-focus, respectively, in units of centimeters. Between the specified points in time, we want the laser to move linearly. We specify the function names as x_f and y_f, respectively, and make sure to set the arguments correctly.

We can then just alter our previous expressions for the focus to be x_focus = x_f(t) and y_focus = y_f(t) and get the moving load pictured below.

A heating profile read in from a text file.

We can see that this Interpolation function quickly lets us read in some very complicated profile patterns, we just need a way to generate these profiles and the text files. For example, the text file format used here is not too different from the G-code format, so if you have a heating path defined in such a format, it can be pretty simple to convert it to a COMSOL®-friendly input. On the other hand, maybe we would like to import a profile created in the ubiquitous 2D DXF file format. Let’s look at that next…

Method 3: Using Paths Imported from CAD Geometries

Suppose we want the load to move along a path we read in from an external file, as shown in the image below. We would like the laser to move smoothly along this path from one end to the other. Now, we need to do a bit more work.

The S-shaped profile of the laser path is read in from a DXF file as a geometry.

The file that we’ve read in doesn’t have any information about time within it: It is just a path that we expect the laser to follow at a constant speed. Now, each edge of this imported path (and there may be thousands of edges) does have parameters s1 and s2 that vary linearly along the length, but if there are many edges, we probably wouldn’t want to work with these parameters. So instead, how do we compute where the laser is at every point in time along the entire set of lines? One way in which we can do this is by introducing another partial differential equation (PDE) to solve, along the desired set of lines. The PDE we want to solve is:

where refers to the tangential direction to the curve.

This PDE, along with the boundary conditions of u = 0 at one end of the path and u = 1 at the other end, will give us a field along the path that varies linearly from 0 to 1, which will be proportional to the total arc length of all of the edges. We can set this up using the Coefficient Form Edge PDE interface, as shown in the screenshots below. All coefficient terms other than the Diffusion Coefficient, c, are set to zero.

Left: Settings of the Coefficient Form Edge PDE interface needed to compute the path. Right: The diffusion coefficient term, c, is a constant; all other coefficients are set to zero.

Then, two Dirichlet boundary conditions set the field, u, at either ends, and we solve this PDE in a stationary step, prior to solving the heat transfer problem but still within the same study.

Two Dirichlet boundary conditions are used at the start and end of the profile path to constrain the field.

Next, we introduce a single minimum component coupling operator into the model, with the source selected as the edges to follow. This minimum operator is used to define the focal point coordinates, e.g.:

x_focus = minop1(abs(u-t/T0),x)

y_focus = minop1(abs(u-t/T0),y)

Note that the minimum operator is given two arguments. When we call the operator with two arguments, it will return the value of the second argument where the first argument is at a minimum. Thus, at each time, t, it will return the x- and y-locations of a point on the edge that is t/T0 fraction of the way from one end to the other.

Left: The minimum operator is defined over the path that the heat source follows. Right: The laser heat source following the path defined by an imported DXF file.

And what if we would like the laser to traverse different parts of the path at different speeds? We would just need to adjust the coefficient, c, along those sets of edges. Suppose we want the laser to move three times faster along the curved boundaries than along the straight lines: just make c three times larger. Note that the absolute value doesn’t matter, it is just the ratio of the coefficient magnitudes that matters. The one drawback to this approach arises when the path crosses itself. In that situation, you would need to subdivide the path into two, or more, groups of paths; solve a PDE on each; and do a bit more bookkeeping for the variables.

Closing Remarks on Modeling Moving Loads and Constraints

In this blog post, we have looked at three different approaches of modeling a moving load. To try them yourself, click the button below to head to the Application Gallery. There, you can download the MPH-files for the models featured above (must have a COMSOL Access account and valid software license).

Several other examples within the Application Gallery also make use of these techniques, including:

• Laser Heating of a Silicon Wafer
• Traveling Load

Although in this blog post we only considered loads, note that we can also apply these techniques to constraints, as described in How to Make Boundary Conditions Conditional in Your Simulation.

Do you have further questions about using COMSOL Multiphysics for your modeling applications? Please let us know!

Describing the Skin Effect Using the AC/DC Module

Whenever a lossy material, such as a conductor, is exposed to a time-varying electromagnetic field, there will be currents induced in that material. These currents then produce a magnetic field that alters the current distribution within the material, with the net result being that the induced currents will preferentially flow at the surfaces of any lossy material. This is known as the skin effect.

We can model this effect using the AC/DC Module and any of the physics interfaces that solve for the magnetic fields and currents, such as the:

• Magnetic Fields interface
• Magnetic and Electric Fields interface
• Magnetic Field Formulation interface
• Rotating Machinery Magnetic interface

All of these physics interfaces support modeling in the frequency domain under the assumption that the magnetic fields, and all other fields, are varying sinusoidally in time. The Magnetic Fields interface — as well as the Rotating Machinery Magnetic and the Magnetic Field Formulation interfaces — support full time-domain analysis, where the fields can vary nonsinusoidally over time.

Frequency-Domain Simulations for Conductors in Time-Varying Magnetic Fields

To start off, we focus on the frequency domain, a very reasonable thing to do, since most electric devices operate at a known frequency or range of frequencies. Based upon the operating frequency, we can then compute the skin depth, δ, in the material:

where is the operating frequency, is the permeability, is the permittivity of free space, and are the relative permeability and permittivity of the material, and is the material electrical conductivity.

For conductors, this equation can be simplified to:

Strictly speaking, the skin depth is defined in terms of the exponential decrease in the induced currents within a planar, semi-infinite conductor, but it is still a useful measure regardless of the shape of the geometry. First, we always estimate the skin depth of all of the materials in the simulation, since this value governs how we will model them. To understand this key point, let’s look at a simple case of a closed loop of wire (with a wire radius of 1 cm and loop radius of 10 cm) exposed to a uniform background magnetic field at different frequencies, as shown schematically below.

A loop of copper wire exposed to a sinusoidally time-varying magnetic field.

The above illustrated problem can be modeled using a 2D axisymmetric model, as seen below. The infinite element domain is used to truncate the modeling space for the reasons outlined in this previous blog post.

A schematic of the coil model.

Let’s look at the results at several different frequencies. The image below shows the magnitude of the current flow in the coil. At higher frequencies, we can observe how the current primarily flows near the surface of the coil. In fact, at the highest frequency, the current in the center of the coil is, for all practical purposes, zero. That is, the skin effect has shielded the inside of the conductor.

The current flow within the coil cross section at different frequencies.

To appropriately model these various cases, we also need to be aware of the finite element mesh used. At higher frequencies, as the current is being driven closer and closer to the boundaries, we need to have a finer mesh to resolve the spatial variation of the fields. However, the fields are only varying strongly in the direction normal to the boundary and varying quite gradually along the perimeter of the coil.

In these cases, it is appropriate to use the boundary layer meshing functionality, which will insert thin elements normal to the boundary, as shown in the image below. Depending upon how accurately you want to resolve the current distribution in the coil, you can adjust the thickness of the boundary layer elements to be between one half to one skin depth and use as few as two or as many as eight or more boundary layer elements. On the other hand, at frequencies that are low enough, the boundary layer meshing is not needed at all.

The mesh within the wire at varying frequencies, corresponding to the previous plots of current distribution.

Equivalent Boundary Conditions

Now, we can also see from the image above that at higher frequencies, the current distributions extend very negligibly into the coil interior. Therefore, for all practical purposes, we can say that at frequencies that are high enough, the currents flow on the surface. In these cases, we can use the Impedance boundary condition and not model any of the coil interior at all, as shown in the image below.

Schematic and mesh of a model using the Impedance boundary condition.

This approach saves us a significant amount of computational effort, since we now only need to mesh the air domain and apply the Impedance boundary condition. Obviously, we do lose some information here: the current distribution within the conductor. But if we do not care about that, then this approach can be a superior alternative to meshing the conductor interior. The first plot below shows the losses in the coil versus frequency, computed via the Impedance boundary condition and via a domain model of the coil with a boundary layer mesh.

Plot of the computed losses via a domain model and the Impedance boundary condition.

The next figure plots the ratio of the losses computed by using the Impedance boundary condition to the losses computed by explicitly modeling the domains, and this ratio is plotted against the ratio of the wire radius to the skin depth. As the characteristic dimension of the parts (in this case, the radius) approaches ten times the skin depth, the losses computed via these two approaches are similar.

Plot of the ratio of computed losses versus the ratio of object size to skin depth.

We can conclude from the plot above that the Impedance boundary condition gives us an accurate prediction of total losses as long as the skin depth is relatively small compared to the dimensions of the conductors that we want to model. This is an important result, as it can significantly simplify a lot of our frequency-domain modeling within the AC/DC Module.

Time-Domain Simulations for Conductors in Time-Varying Magnetic Fields

Let’s finish up this topic by addressing time-domain simulations. The Impedance boundary condition is not available in this case, since this boundary condition is formulated based upon the frequency-domain form of Maxwell’s equations. For time-domain simulations, we must model and mesh the interior of all conductors. Boundary layer meshing is still appropriate, but you will want to adjust the thicknesses of the elements based on both the average and maximum expected frequency content of your time-domain excitations. This can sometimes lead to a much more computationally expensive model, of course, so try to model in the frequency domain as much as possible.

And what if you have materials that are nonlinear with respect to field strength or materials that you might think you have to model in the time domain? What do you do then? If you’re imagining a ferromagnetic material with a nonlinear magnetic permeability, you can still model the magnetic material in the frequency domain using the effective H-B curve functionality.

Closing Remarks

Having a good understanding of how to model conductive, lossy materials interacting with time-varying magnetic fields is important for effective use of the AC/DC Module. You can either explicitly model the conductive domains or model the conductors via the Impedance boundary condition at higher frequencies. If you do model the domains explicitly, you will need to use a boundary layer mesh to give a good resolution of the currents at higher frequencies, which does increase the computational requirements. If you use the Impedance boundary condition, you introduce an approximation, but you will not need to model the interior of the conductor domains at all, saving you significant computational resources.

Next Steps

To learn more about the specialized features and functionality for electromagnetics modeling available in the AC/DC Module, click the button below.

Additional Resources

To work through a set of supplemental exercises on this topic, see the following tutorials:

• Iron Sphere in a 60 Hz Magnetic Field
• Iron Sphere in a 20 kHz Magnetic Field
• Iron Sphere in a 13.56 MHz Magnetic Field
• Mutual Inductance and Induced Currents Between Single-Turn Coils

Understanding Ohm’s Law and Resistive Heating

One of the first physical laws that we learn as engineers is Ohm’s law: The current through a device equals the applied voltage difference divided by the device electrical resistance, or I = V/R_e, where the electrical resistance, R_e, is a function of the device geometry and material’s electrical conductivity.

Shortly after learning that law, we probably also learned about the dissipated power within the device, which equals the current times the voltage difference, or Q = IV, which we could also write as Q = I²R_e or Q = V²/R_e. Maybe a little bit later in our studies, we also learned about thermal conductivity and equivalent device thermal resistance, R_t, which let us compute, in a lumped sense, the rise in temperature of a device via ΔT = QR_t relative to ambient conditions. We can then determine the absolute device temperature using .

We start our discussion from this point and consider a completely lumped model of a device. (Yes, we’re starting so simple that we don’t even need to use the COMSOL Multiphysics® software for this part!) Let’s consider a lumped device with electrical resistance of R_e = 1 Ω and thermal resistance of R_t = 1 K/W. We can drive this device with either a constant voltage and compute the temperature as or drive it via constant current where the peak temperature is .

We choose an ambient temperature of 300 K, or 27°C, which is about room temperature. Let’s now plot out the device lumped temperature as a function of increasing voltage (from 0 to 10 V) and current (from 0 to 10 A), as shown in the image below. Unsurprisingly, we see a quadratic increase in temperature.

Device temperature as a function of applied voltage (left) and applied current (right), assuming constant properties.

We might think that we can use the curve to predict a wider range of operating conditions. Suppose we want to drive the device up to its failure temperature, where the material melts or vaporizes. Let’s say that this material will vaporize when its temperature gets up to 700 K (427°C). Based on this curve, some simple math would indicate that the maximum voltage is 20 V and the maximum current is 20 A, but this is quite wrong!

Introducing Material Nonlinearities into the Simple Lumped Model

At this point, you’re probably ready to point out the simple mistake that we’ve made: Electrical resistance is not constant with temperature. For most metals, the electrical conductivity goes down with an increasing temperature and since resistivity is the inverse of conductivity, the device resistivity goes up. So, let’s introduce a temperature dependence for the resistivity:

This is known as a linearized resistivity model, where ρ₀ is the reference resistivity at , the reference temperature, and α_e is the temperature coefficient of electrical resistivity.

Let’s choose ρ₀ = 1 Ω, = 300 K, and α_e = 1/200 K. Now, the resistance is 1 Ω at a device temperature of 300 K and 2 Ω at a temperature rise of 200 K above the set temperature. The equations for lumped temperature as a function of voltage and current now become:

and

These equations are a bit more complicated (the first is a quadratic equation in terms of T) but still possible to solve by hand. The plots of temperature as a function of increasing voltage and current are displayed below.

Device temperature as a function of applied voltage (left) and applied current (right) with the electrical resistivity as a function of temperature.

For the voltage-driven problem, as the temperature rises, the resistance rises. Since the resistance occurs in the denominator of the temperature expression, higher resistance lowers the temperature and we see that the temperature will be lower than that for the constant resistivity case. If we drive the device with constant current, the temperature-dependent resistance appears in the numerator. As we increase the current, the resistive heating will be higher than that for the linear material case.

We might be tempted at this point to compute the maximum voltage or current that this device can sustain, but you are probably already realizing the second mistake we’ve made: We also need to incorporate the temperature dependence of the thermal resistance. For metals, it’s reasonable to assume that the electrical and thermal conductivity will show the same trends. Thus, let’s use a nonlinear expression that is similar to what we used before:

Now, our voltage-driven and current-driven equations for temperature become:

and

Although only slightly different from before, these nonlinear equations are now quite a bit more difficult to solve. Simulation software is starting to look more attractive! Once we do solve these equations (let’s set r₀ = 1 K/W, α_t = 1/400 K, and = 300 K), we can plot the device temperature, as shown below.

Device temperature as a function of applied voltage (left) and applied current (right) with the electrical and thermal resistivity as a function of temperature.

Observe that for the current-driven case, the temperature rises asymptotically. Since both the electrical and the thermal resistance increase with an increasing temperature, the device temperature rises very sharply as the current is increased. As the temperature rises to infinity, the problem becomes unsolvable. This is actually entirely expected; in fact, this is how your basic car fuse works. Now, if we were solving this problem in COMSOL Multiphysics, we could also solve this as a transient model (incorporating the thermal mass due to the device density and specific heat) and predict the time that it takes for the device temperature to rise to its failure point.

Things are luckily a bit simpler for the voltage-driven case. Here, we also see a predictable behavior: The rising thermal resistivity drives the temperature higher than when we only considered a temperature-dependent electrical conductivity. Now, the interesting point here is the temperature is still lower than for the constant resistivity case. This also sometimes confuses people, but just keep in mind that one of these nonlinearities is driving the temperature down while the other is driving the temperature up. In general, for a more complicated model (such as one you would build in COMSOL Multiphysics), you don’t know which nonlinearity will predominate.

What other mistake might we have made here? We have used a positive temperature coefficient of thermal resistivity. This is certainly true for most metals, but it turns out that the opposite is true for some insulators, glass being a common example. Usually, the total device thermal resistance is mostly a function of the insulators rather than the electrically conductive domains. In addition, the device’s thermal resistance should incorporate the effects of the cooling to the surrounding ambient environment. So, the effects of free convection (which increases with the temperature difference) and radiation (which has a fourth-order dependence on temperature difference) could also be lumped into this single thermal resistance. For now, though, let’s keep the problem (relatively) simple and just switch the sign of the temperature coefficient of thermal resistivity, α_t = -1/400 K, and directly compare the voltage- and current-driven cases for driving voltage up to 100 V and current up to 100 A.

Device temperature as a function of applied voltage (pink) and applied current (blue) with a negative temperature coefficient of thermal resistivity.

We now see some results that are quite different. Observe that for both the voltage- and current-driven cases, the temperature increases approximately quadratically at low loads, but at higher loads, the temperature increase starts to flatten out due to the decreasing thermal resistivity. The slope, although always positive, decreases in magnitude. The current-driven case starts to asymptotically approach T = 700 K, but the voltage-driven case stays significantly below the failure temperature.

This is an important result and highlights another common mistake. The nonlinear material models we used here for electrical and thermal resistivity are approximations that start to become invalid if we get too close to 700 K. If we anticipate operating in this regime, we should go back to the literature and find a more sophisticated material model. Although our existing nonlinear material models did solve, we always need to check that they are still valid at the computed operating temperature. Of course, if we are not close to these operating conditions, we can use the linearized resistivity model (one of the built-in material models within COMSOL Multiphysics). Then, our model will be valid.

We can hopefully now see from all of this data that the temperature has a very complicated relationship with respect to the driving voltage or current. When nonlinear materials are considered, the temperature might be higher or lower than when using constant properties, and the slope of the temperature response can switch from quite steep to quite shallow just based on the operating conditions.

Have these results thoroughly confused you yet? What if we went back and changed one of the coefficients in the resistance expressions? Certain materials have negative temperature coefficients of electrical and thermal resistivity. What if we used an even more complicated nonlinearity? Would you feel confident in saying anything about the expected temperature variations in even this simple lumped device case, or would you rather check it against a rigorous calculation?

Concluding Thoughts on Common Pitfalls in Electrothermal Analysis

What about the case of a real-world device? One that has a combination of many different materials, different electrical and thermal conductivities as a function of temperature, and complex shapes? Would you model this under steady-state conditions only or in the time domain, to find out how long it takes for the temperature to rise? Maybe — in fact, most likely — there will also be nonlinear boundary conditions such as radiation and free convection that we don’t want to approximate via a single lumped thermal resistance. What can you expect then? Almost anything! And how do you analyze it? Well, with COMSOL Multiphysics, of course!

Next Step

Evaluate how COMSOL Multiphysics can help you meet your multiphysics modeling and analysis goals. Contact us via the button below.

Electromagnetic Heating Around Sharp Corners

One of the most common problems solved with the COMSOL Multiphysics® software is that of electromagnetic heating, combining the solution to Maxwell’s equations, which solves for the current flow and resultant losses, and the solution to the heat transfer equation, which solves for the temperature distribution.

As mentioned in a previous blog post, when solving for the electromagnetic fields, sharp reentrant corners lead to locally nonconvergent electric fields and current density. Electromagnetic losses are the product of the electric field and current density, so the peak losses at a sharp corner will similarly go to infinity with mesh refinement.

However, the integral over the losses around the sharp corner will be convergent with respect to mesh refinement. This is one of the strengths of the finite element method, which solves the governing equation in the so-called “weak form”, which satisfies the governing partial differential equations in an integral sense: minimizing the total error in the model, but allowing (possibly infinite!) local errors.

A schematic of a simple electromagnetic heating problem with a singularity at the inside sharp corner.

Let’s review this concept with a simple example, as shown in the image above. A rectangular domain with a sharp notch has an electric potential difference applied, leading to current flow and resistive losses in the material.

Below, we see a color plot of the resistive losses and the mesh used for different levels of mesh refinement at the sharp inside corner. At the highest level of mesh refinement, the losses appear very localized around the sharp corner.

The electromagnetic losses on several different meshes.

At this sharp inside corner, the electric fields are actually theoretically infinitely large, since this geometry and the boundary conditions imply that the current must instantaneously change direction at a point. Also note that the sharp outside corners do not lead to singularities. As a consequence of the geometry and boundary conditions, the electric currents are not forced to change direction instantaneously at these points.

The resistive losses in log scale, plotted along a cut line, and a table of the integral of the losses for different meshes.

If we plot the losses at a cross-sectional line, as shown above, we can observe that the losses at the sharp point get larger and larger as the mesh is refined. However, the integral of the losses over the domain (roughly speaking, the area underneath the plotted curves) converges very quickly with mesh refinement.

Now let’s make this a multiphysics problem by additionally solving the heat transfer equation for the temperature distribution under steady-state conditions. These temperature fields are plotted below for several levels of mesh refinement, as well as the temperature at the sharp point.

The temperature field and a table of the temperature evaluated at the sharp corner for different levels of mesh refinement.

We can see from these results that the temperature at the singular point — and, of course, everywhere else — is also very insensitive to the mesh refinement. This is for two reasons. First, as we just saw, the total resistive losses are quite insensitive to the mesh. Second, the diffusive nature of the steady-state heat transfer governing equation will return very similar temperature solutions as long as the total heat loads are similar. The transient temperature solution, on the other hand, can predict very high local temperatures if the heat load is very high, but this is also a local and relative effect, albeit in time. That is, spikes in the heat load distribution in space will be smoothed out over time, and in the limit of very long simulation times, the transient solution will approach the steady state solution.

Closing Remarks

What can we conclude from all of this information? If you are solving an electromagnetic heating problem and are only interested in computing the total electromagnetic losses and temperature distribution, you can usually avoid adding fillets to your model.

The advantages here are twofold. You do not need to go through the CAD modeling effort of adding any fillets to your geometry and you do not need an overly refined mesh in the sharp corners, which can save you the most valuable resource: time!

This post was originally published in 2013. It has since been updated to include all of the turbulence models currently available with the CFD Module as of version 5.3 of the COMSOL® software.

Introduction to Turbulence Modeling

Let’s start by considering the fluid flow over a flat plate, as shown in the figure below. The uniform velocity profile hits the leading edge of the flat plate, and a laminar boundary layer begins to develop. The flow in this region is very predictable. After some distance, small chaotic oscillations begin to develop in the boundary layer and the flow begins to transition to turbulence, eventually becoming fully turbulent.

The transition between these three regions can be defined in terms of the Reynolds number, , where is the fluid density; is the velocity; is the characteristic length (in this case, the distance from the leading edge); and is the fluid’s dynamic viscosity. We will assume that the fluid is Newtonian, meaning that the viscous stress is directly proportional, with the dynamic viscosity as the constant of proportionality, to the shear rate. This is true, or very nearly so, for a wide range of fluids of engineering importance, such as air or water. Density can vary with respect to pressure, although it is here assumed that the fluid is only weakly compressible, meaning that the Mach number is less than about 0.3. The weakly compressible flow option for the fluid flow interfaces in COMSOL Multiphysics neglects the influence of pressure waves on the flow and pressure fields.

In the laminar regime, the fluid flow can be completely predicted by solving Navier-Stokes equations, which gives the velocity and the pressure fields. Let us first assume that the velocity field does not vary with time. An example of this is outlined in The Blasius Boundary Layer tutorial model. As the flow begins to transition to turbulence, oscillations appear in the flow, despite the fact that the inlet flow rate does not vary with time. It is then no longer possible to assume that the flow is invariant with time. In this case, it is necessary to solve the time-dependent Navier-Stokes equations, and the mesh used must be fine enough to resolve the size of the smallest eddies in the flow. Such a situation is demonstrated in the Flow Past a Cylinder tutorial model. Note that the flow is unsteady, but still laminar in this model. Steady-state and time-dependent laminar flow problems do not require any modules and can be solved with COMSOL Multiphysics alone.

As the flow rate — and thus also the Reynolds number — increases, the flow field exhibits small eddies and the spatial and temporal scales of the oscillations become so small that it is computationally unfeasible to resolve them using the Navier-Stokes equations, at least for most practical cases. In this flow regime, we can use a Reynolds-averaged Navier-Stokes (RANS) formulation, which is based on the observation that the flow field (u) over time contains small, local oscillations (u’) and can be treated in a time-averaged sense (U). For one- and two-equation models, additional transport equations are introduced for turbulence variables, such as the turbulence kinetic energy (k in k-ε and k-ω).

In algebraic models, algebraic equations that depend on the velocity field — and, in some cases, on the distance from the walls — are introduced in order to describe the turbulence intensity. From the estimates for the turbulence variables, an eddy viscosity that adds to the molecular viscosity of the fluid is calculated. The momentum that would be transferred by the small eddies is instead translated to a viscous transport. Turbulence dissipation usually dominates over viscous dissipation everywhere, except for in the viscous sublayer close to solid walls. Here, the turbulence model has to continuously reduce the turbulence level, such as in low Reynolds number models. Or, new boundary conditions have to be computed using wall functions.

Low Reynolds Number Models

The term “low Reynolds number model” sounds like a contradiction, since flows can only be turbulent if the Reynolds number is high enough. The notation “low Reynolds number” does not refer to the flow on a global scale, but to the region close to the wall where viscous effects dominate; i.e., the viscous sublayer in the figure above. A low Reynolds number model is a model that correctly reproduces the limiting behaviors of various flow quantities as the distance to the wall approaches zero. So, a low Reynolds number model must, for example, predict that k~y² as y→0. Correct limiting behavior means that the turbulence model can be used to model the whole boundary layer, including the viscous sublayer and the buffer layer.

Most ω-based models are low Reynolds number models by construction. But the standard k-ε model and other commonly encountered k-ε models are not low Reynolds number models. Some of them can, however, be supplemented with so-called damping functions that give the correct limiting behavior. They are then known as low Reynolds number k-ε models.

Low Reynolds number models often give a very accurate description of the boundary layer. The sharp gradients close to walls do, however, require very high mesh resolutions and that, in turn, means that the high accuracy comes at a high computational cost. This is why alternative methods to model the flow close to walls are often employed for industrial applications.

Wall Functions

The turbulent flow near a flat wall can be divided into four regions. At the wall, the fluid velocity is zero, and in a thin layer above this, the flow velocity is linear with distance from the wall. This region is called the viscous sublayer, or laminar sublayer. Further away from the wall is a region called the buffer layer. In the buffer region, turbulence stresses begin to dominate over viscous stresses and it eventually connects to a region where the flow is fully turbulent and the average flow velocity is related to the log of the distance to the wall. This is known as the log-law region. Even further away from the wall, the flow transitions to the free-stream region. The viscous and buffer layers are very thin and if the distance to the end of the buffer layer is , then the log-law region will extend about away from the wall.

It is possible to use a RANS model to compute the flow field in all four of these regions. However, since the thickness of the buffer layer is so small, it can be advantageous to use an approximation in this region. Wall functions ignore the flow field in the buffer region and analytically compute a nonzero fluid velocity at the wall. By using a wall function formulation, you assume an analytic solution for the flow in the viscous layer and the resultant models will have significantly lower computational requirements. This is a very useful approach for many practical engineering applications.

If you need a level of accuracy beyond what the wall function formulations provide, then you will want to consider a turbulence model that solves the entire flow regime as described for the low Reynolds number models above. For example, you may want to compute lift and drag on an object or compute the heat transfer between the fluid and the wall.

Automatic Wall Treatment

The automatic wall treatment functionality, which is new in COMSOL Multiphysics version 5.3, combines benefits from both wall functions and low Reynolds number models. Automatic wall treatment adapts the formulation to the mesh available in the model so that you get both robustness and accuracy. For instance, for a coarse boundary layer mesh, the feature will utilize a robust wall function formulation. However, for a dense boundary layer mesh, the automatic wall treatment will use a low Reynolds number formulation to resolve the velocity profile completely to the wall.

Going from a low Reynolds number formulation to a wall function formulation is a smooth transition. The software blends the two formulations in the boundary elements. Then, the software calculates the wall distance of the boundary elements’ grid points (this is in viscous units given by a liftoff). The combined formulations are then used for the boundary conditions.

All turbulence models in COMSOL Multiphysics, except the k-ε model, support automatic wall treatment. This means that the low Reynolds number models can be used for industrial applications and that their low Reynolds number modeling capability is only invoked when the mesh is fine enough.

About the Various Turbulence Models

The eight RANS turbulence models differ in how they model the flow close to walls, the number of additional variables solved for, and what these variables represent. All of these models augment the Navier-Stokes equations with an additional turbulence eddy viscosity term, but they differ in how it is computed.

L-VEL and yPlus

The L-VEL and algebraic yPlus turbulence models compute the eddy viscosity using algebraic expressions based only on the local fluid velocity and the distance to the closest wall. They do not solve any additional transport equations. These models solve for the flow everywhere and are the most robust and least computationally intensive of the eight turbulence models. While they are generally the least accurate models, they do provide good approximations for internal flow, especially in electronic cooling applications.

Spalart-Allmaras

The Spalart-Allmaras model adds a single additional variable for an undamped kinematic eddy viscosity. It is a low Reynolds number model and can resolve the entire flow field down to the solid wall. The model was originally developed for aerodynamics applications and is advantageous in that it is relatively robust and has moderate resolution requirements. Experience shows that this model does not accurately compute fields that exhibit shear flow, separated flow, or decaying turbulence. Its advantage is that it is quite stable and shows good convergence.

k-ε

The k-ε model solves for two variables: k, the turbulence kinetic energy; and ε (epsilon), the rate of dissipation of turbulence kinetic energy. Wall functions are used in this model, so the flow in the buffer region is not simulated. The k-ε model has historically been very popular for industrial applications due to its good convergence rate and relatively low memory requirements. It does not very accurately compute flow fields that exhibit adverse pressure gradients, strong curvature to the flow, or jet flow. It does perform well for external flow problems around complex geometries. For example, the k-ε model can be used to solve for the airflow around a bluff body.

The turbulence models listed below are all more nonlinear than the k-ε model and they can often be difficult to converge unless a good initial guess is provided. The k-ε model can be used to provide a good initial guess. Just solve the model using the k-ε model and then use the new Generate New Turbulence Interface functionality, available in the CFD Module with COMSOL Multiphysics version 5.3.

k-ω

The k-ω model is similar to the k-ε model, but it solves for ω (omega) — the specific rate of dissipation of kinetic energy. It is a low Reynolds number model, but it can also be used in conjunction with wall functions. It is more nonlinear, and thereby more difficult to converge than the k-ε model, and it is quite sensitive to the initial guess of the solution. The k-ω model is useful in many cases where the k-ε model is not accurate, such as internal flows, flows that exhibit strong curvature, separated flows, and jets. A good example of internal flow is flow through a pipe bend.

Low Reynolds Number k-ε

The low Reynolds number k-ε model is similar to the k-ε model, but does not need wall functions: it can solve for the flow everywhere. It is a logical extension of the k-ε model and shares many of its advantages, but generally requires a denser mesh; not only at walls, but everywhere its low Reynolds number properties kick in and dampen the turbulence. It can sometimes be useful to use the k-ε model to first compute a good initial condition for solving the low Reynolds number k-ε model. An alternative way is to use the automatic wall treatment and start with a coarse boundary layer mesh to get wall functions and then refine the boundary layer at the interesting walls to get the low Reynolds number models.

The low Reynolds number k-ε model can compute lift and drag forces and heat fluxes can be modeled with higher accuracy compared to the k-ε model. It has also shown to predict separation and reattachment quite well for a number of cases.

SST

The SST model is a combination of the k-ε model in the free stream and the k-ω model near the walls. It is a low Reynolds number model and kind of the “go to” model for industrial applications. It has similar resolution requirements to the k-ω model and the low Reynolds number k-ε model, but its formulation eliminates some weaknesses displayed by pure k-ω and k-ε models. In a tutorial model example, the SST model solves for flow over a NACA 0012 Airfoil. The results are shown to compare well with experimental data.

v2-f

Close to wall boundaries, the fluctuations of the velocity are usually much larger in the parallel directions to the wall in comparison with the direction perpendicular to the wall. The velocity fluctuations are said to be anisotropic. Further away from the wall, the fluctuations are of the same magnitude in all directions. The velocity fluctuations become isotropic.

The v2-f turbulence model describes the anisotropy of the turbulence intensity in the turbulent boundary layer using two new equations, in addition to the two equations for turbulence kinetic energy (k) and dissipation rate (ε). The first equation describes the transport of turbulent velocity fluctuations normal to the streamlines. The second equation accounts for nonlocal effects such as the wall-induced damping of the redistribution of turbulence kinetic energy between the normal and parallel directions.

You should use this model for enclosed flows over curved surfaces, for example, to model cyclones.

Meshing Considerations for CFD Problems

Solving for any kind of fluid flow problem — laminar or turbulent — is computationally intensive. Relatively fine meshes are required and there are many variables to solve for. Ideally, you would have a very fast computer with many gigabytes of RAM to solve such problems, but simulations can still take hours or days for larger 3D models. Therefore, we want to use as simple a mesh as possible, while still capturing all of the details of the flow.

Referring back to the figure at the top of this blog post, we can observe that for the flat plate (and for most flow problems), the velocity field changes quite slowly in the direction tangential to the wall, but quite rapidly in the normal direction, especially if we consider the buffer layer region. This observation motivates the use of a boundary layer mesh. Boundary layer meshes (which are the default mesh type on walls when using our physics-based meshing) insert thin rectangles in 2D or triangular prisms in 3D at the walls. These high-aspect-ratio elements will do a good job of resolving the variations in the flow speed normal to the boundary, while reducing the number of calculation points in the direction tangential to the boundary.

The boundary layer mesh (magenta) around an airfoil and the surrounding triangular mesh (cyan) for a 2D mesh.

The boundary layer mesh (magenta) around a bluff body and the surrounding tetrahedral mesh (cyan) for a 3D volumetric mesh.

Evaluating the Results of Your Turbulence Model

Once you’ve used one of these turbulence models to solve your flow simulation, you will want to verify that the solution is accurate. Of course, as you do with any finite element model, you can simply run it with finer and finer meshes and observe how the solution changes with increasing mesh refinement. Once the solution does not change to within a value you find acceptable, your simulation can be considered converged with respect to the mesh. However, there are additional values you need to check when modeling turbulence.

When using wall function formulations, you will want to check the wall resolution viscous units (this plot is generated by default). This value tells you how far into the boundary layer your computational domain starts and should not be too large. You should consider refining your mesh in the wall normal direction if there are regions where the wall resolution exceeds several hundred. The second variable that you should check when using wall functions is the wall liftoff (in length units). This variable is related to the assumed thickness of the viscous layer and should be small relative to the surrounding dimensions of the geometry. If it is not, then you should refine the mesh in these regions as well.

The maximum wall liftoff in viscous units is less than 100, so there is no need to refine the boundary layer mesh.

When solving a model using low Reynolds number wall treatment, check the dimensionless distance to cell center (also generated by default). This value should be of order unity everywhere for the algebraic models and less than 0.5 for all two-equation models and the v2-f model. If it is not, then refine the mesh in these regions.

Concluding Thoughts

In this blog post, we have discussed the various turbulence models available in COMSOL Multiphysics, highlighting when and why you should use each one of them. The real strength of the COMSOL® software is when you want to combine your fluid flow simulations with other physics, such as finding stresses on a solar panel in high winds, forced convection modeling in a heat exchanger, or mass transfer in a mixer, among other possibilities.

If you are interested in using the COMSOL® software for your CFD and multiphysics simulations, or if you have a question that isn’t addressed here, please contact us.

Manually Creating a Model Method in COMSOL Multiphysics®

As we saw in a previous blog post on creating randomized geometries, you can use the Record Method functionality to record a series of operations that you’re performing within the COMSOL Multiphysics graphical user interface (GUI) and then replay that method to reproduce those same steps. Of course, this doesn’t do us any good if we have already created the file — we don’t want to go back and rerecord the entire file. As it turns out, though, COMSOL Multiphysics automatically keeps a history of everything that you’ve done in a model file as Java® code. We can just extract the relevant operations directly from this code and insert them into a new model method.

The Compact History option.

To extract all of the history of all operations within a file, there are a few steps you need to take. First, go to the File menu and choose the Compact History option. We do this because COMSOL Multiphysics keeps a history of all commands, but we only want the minimum set of commands that were used to generate the existing model. Next, go to File Menu > Save As and save to a Model File for Java file type. You now have a text file that contains Java® code. Try this out yourself and open the resulting file in a text editor. This file always has lines of code at the beginning and end that are similar to what is shown below:

/*example_model.java */
import com.comsol.model.*;
import com.comsol.model.util.*;
public class example_model {
  public static Model run() {
    Model model = ModelUtil.create("Model");
    model.modelPath("C:\\Temp");
    model.label("example_model.mph");
    model.comments("This is an example model");
         ...
         ... /* Lines of code describing the model contents */
         ...
     return model;
 }
 public static void main(String[] args) { run();}
}

The above code snippet shows us what we can remove. Only the code between the Model model = ModelUtil.create("Model"); and return model; is used to define all of the features within the model. In fact, we can also remove the model.modelPath();, model.label();, and model.comments(); lines. Go ahead and remove all of these lines of code in your text editor and you are left with just the set of commands needed to reproduce the model in a model method.

Next, open a new blank model file, go to the Application Builder, and create a new model method. Copy all of the lines from your edited Java® file into this new model method. Then, switch back to the Model Builder, go to the Developer tab, and choose Run Model Method to run this code. Running this model method reproduces all of the steps from your original file, including solving the model. Solving the model may take a long time, so we often want to trim our model method.

A model method within the Application Builder.

Trimming the Model Method

There are two approaches that you can take for trimming down the code. The first is to manually edit the Java® code itself, pruning out any code that you don’t want to rerun. It’s helpful to have the COMSOL Programming Reference Manual handy if you’re going to do this, because you may need to know what every line does before you delete it. The second, simpler approach is to delete the features directly within the COMSOL Multiphysics GUI. Start with a copy of your original model file and delete everything that you don’t want to appear within the method. You can delete the geometry sequence, mesh, study steps, results visualizations, and anything else that you don’t want to reproduce.

Let’s take a look at a quick example of this. Suppose that you’ve built a model that simulates thermal curing and you want to include this thermal curing simulation in other existing models that already have the heat transfer simulations set up.

As we saw in a previous blog post, modeling thermal curing in addition to heat transfer requires three steps:

1. Defining a set of material parameters
2. Adding a Domain ODE interface to model the evolution of the cure over time
3. Coupling the heat of reaction from the curing into the thermal problem

We can build a model in the GUI that contains just these steps and then write out the Java® file. Of course, we still need to do some manual editing, and it’s also helpful to go through the Application Programming Guide to get an introduction to the basics. But once you’re comfortable with all of the syntax, you’ll see that the above three steps within the GUI can be written in the model method shown here:

model.param().set("H_r", "500[kJ/kg]", "Total Heat of Reaction");
model.param().set("A", "200e3[1/s]", "Frequency Factor");
model.param().set("E_a", "150[kJ/mol]", "Activation Energy");
model.param().set("n", "1.4", "Order of Reaction");
model.component("comp1").physics("ht").create("hsNEW", "HeatSource");
model.component("comp1").physics("ht").feature("hsNEW").selection().all();
model.component("comp1").physics("ht").feature("hsNEW").set("Q0", "-ht.rho*H_r*d(alpha,t)");
model.component("comp1").physics().create("dode", "DomainODE", "geom1");
model.component("comp1").physics("dode").field("dimensionless").field("alpha");
model.component("comp1").physics("dode").field("dimensionless").component(new String[]{"alpha"});
model.component("comp1").physics("dode").prop("Units").set("SourceTermQuantity", "frequency");
model.component("comp1").physics("dode").feature("dode1").set("f", "A*exp(-E_a/R_const/T)*(1-alpha)^n");

The first four lines of this code snippet define an additional set of global parameters. The next three lines add a Heat Source domain feature to an existing Heat Transfer interface (with the tag ht), define the heat source term, and apply the heat source to all domains. The last five lines set up a Domain ODE interface that is applied by default to all domains in the model and sets the variable name, the units, as well as the equation to solve.

Running the model method from the Developer tab.

We can run the above model method in a file that already has a heat transfer analysis set up. For example, try adding and running this model method in the Axisymmetric Transient Heat Transfer tutorial, available in the Application Library in COMSOL Multiphysics. Then, just re-solve the model to solve for both temperature and degree of cure.

Now, there are a few assumptions in the above code snippet:

• We want to model curing in all of the domains in our model
• There is already a component with the tag comp1 to which we can add physics interfaces
• There is not already a Domain ODE interface with the tag dode in that component
• The temperature variable is defined as T, which we can use in the Domain ODE interface
• A heat transfer physics interface with tag ht already exists and that we can add a feature with tag hsNEW to it

Of course, as you develop your own model methods, you need to be able to recognize and address these kinds of general logical issues.

Closing Remarks on Model Methods

From this simple example, you can also see that you can create a model method that acts as a reusable template for any part of the modeling process in COMSOL Multiphysics. You might want to run such a template model method in every new file you create, possibly to load in a set of custom material properties, set up a complicated physics interface, or define a complicated set of expressions. You might also want to reuse the same model method in an existing file to set up a particular customized study type, modify solver settings, or define a results visualization that you plan to reuse over and over again.

Once you get comfortable with the basics of this workflow, you’ll find yourself saving lots of time, which we hope you’ll appreciate!

Learn About Other Ways to Use Model Methods

• How to Generate Random Surfaces in COMSOL Multiphysics®
• How to Model Gearbox Vibration and Noise in COMSOL Multiphysics®
• How to Create a Randomized Geometry Using Model Methods

Oracle and Java are registered trademarks of Oracle and/or its affiliates.

Starting Simple: An Optically Flat Surface

Before we get to the rough surface, let’s start with something simple: a thin uniform layer of gold coating on top of optically flat glass, as shown in the image below. Such a model exhibits negligible structural variation in the plane of glass. In addition, it can be modeled quite simply in the COMSOL Multiphysics® software by considering a small two-dimensional unit cell that has a width much smaller than the wavelength.

This computational model is based on the Fresnel equation example, one of the verification models in the Application Gallery, but is modified to include a layer of gold with a wavelength-dependent refractive index. This type of index requires that we manually adjust the mesh size based on the minimum wavelength in each material as well as the skin depth, as described in a previous blog post.

Light incident on a metal coating on top of a glass substrate is reflected, transmitted, and absorbed.

The model includes Floquet periodic boundary conditions on the left and right sides of the modeling domain and a Port boundary condition at the top and bottom. The Port boundary condition at the top launches a plane wave at a specified angle of incidence and computes the reflected light, while the one at the bottom calculates the transmitted light. We can integrate the losses within the metal layer to compute the absorbance within the gold layer.

The computational model that calculates the optical properties of a metal film on glass.

If we are interested in computing incident light at off-normal incident angles, then we also have to concern ourselves with the height of the modeling domain — the distance between the material interfaces and the Port boundary conditions. This distance must be large enough such that any evanescent field drops off to approximately zero within the modeling domain.

The reason for this has to do with the Port boundary conditions, which can only consider the propagating component of the electromagnetic field. Any evanescent component of the field that reaches the Port boundary condition is artificially reflected, so we must place the port boundary far enough away from the material interfaces. In the most general cases, it is difficult to determine how far the evanescent field extends. A simple rule of thumb is to place the Port boundary conditions at least half a wavelength away from the material interfaces and to check if making the domain larger alters the results.

The sample results below show the transmitted, reflected, and absorbed light as well as their total — which should always add up to one. If these do not add up to one, then we must carefully check our model setup.

The transmittance, reflectance, and absorbance of light normally incident on a flat glass surface with a metal coating as a function of wavelength.

The transmittance, reflectance, and absorbance of 550-nm light at various angles of incidence.

Adding Complexity: A Surface with Periodic Variations

Let’s now make things a little bit more complicated and introduce a periodic structural variation: a sinusoidal ripple. Clearly, we now need to consider a larger unit cell that considers a single ripple.

A surface with periodic variations reflects and transmits light into several different diffraction orders.

We can still apply the same domain properties and all of the same boundary conditions. However, if spacing is large enough, then we can have higher-order diffraction. In other words, light can be reflected and transmitted into several different directions. To properly compute the reflection and transmission, we need to add several diffraction order ports. The software computes the appropriate number of ports based on the domain width, material properties, and specified incident angle. If we are studying a range of incident angles, we must make sure to compute all of the diffraction orders present at the limits of the angular sweep.

There can be multiple diffraction orders present, depending on the ratio of wavelength to domain width, refractive index, and incident angles.

The conditions under which higher-order diffraction appears and the appropriate modeling procedure is presented in depth in the example of a plasmonic wire grating, so let’s not go into it at length here. In short, the wider the computational domain relative to the wavelengths in the materials above and below, the more diffraction orders can be present (the number of diffraction orders varies with the incident angle). The results shown below plot the total transmittance and reflectance; i.e., all of the light reflected into the different diffraction orders is added up, as is all of the transmitted light.

The transmittance, reflectance, and absorbance of light normally incident on a rippled glass surface with a metal coating.

The transmittance, reflectance, and absorbance of 550-nm light at various angles of incidence.

Solving a More Difficult Case: A Surface with Random Roughness

Let’s now move on to the most computationally difficult case: a surface with many random variations in the surface height. To model the randomness, we must model several different domains of increasing widths and different subsets of the rough profile. As the domain width increases — and as different subsets of the surface are sampled — the average behavior computed from these different models converges. That is, we generate a set of statistics by sampling the rough surface. Rather than going into detail on how to calculate these statistics, let’s focus on how to model one domain that approximates a rough surface by defining the height variation as the sum of different sinusoids with random height and phase, as described here.

A rough surface with random variations reflects and transmits light in random directions. The computational model must sample a statistically significant subset of the roughness profile.

Our computational domain must now be very wide, many times longer than the wavelength. As we still want to model a plane wave incident at various angles on the structure, we use the Floquet periodic boundary conditions, which require that we have an identical mesh on the periodic boundaries. Practically speaking, this means that we may need to slightly alter the geometry of our domain to ensure that the boundaries on the left and right side are identical. If we do use a sum of sine functions, as described here, then the profile will automatically be periodic.

We still want to launch the wave with a Port boundary condition. However, it is no longer practical to use diffraction order ports to monitor the reflected and transmitted light, as this can result in hundreds (or thousands) of diffraction orders. Furthermore, since this model represents a statistical sampling, the relative fraction of light scattered into these different orders is not of interest; we’re only interested in the sum of the total reflected and transmitted light. That is, this modeling approach computes the total integrated scatter plus the specular reflection and transmission of the surface.

The computational domain for a model of a rough surface. Light is launched from the interior port toward the material interface. Light reflected back toward this port passes though it and is absorbed in the PML, as is the transmitted light. Two additional boundaries are introduced to monitor the total reflectance and transmittance.

Thus, we introduce an alternative modeling strategy that does not use ports to compute reflection and transmission. Instead, we use a perfectly matched layer (PML) above and below to absorb all reflected and transmitted light as well as probes to compute reflection and transmission. PMLs absorb any fields incident upon them, as described in this blog post on using PMLs for wave electromagnetics problems.

The PML absorbs both propagating and evanescent components of the field, but we only want it to absorb the propagating component. Thus, we again need to ensure that we place the PMLs far enough away from the material interfaces. We use the same rule of thumb as before, placing the PML at least half a wavelength away from the material interfaces.

As we approach grazing angles of incidence, even the PML domain does not, by default, absorb all of the light. At nearly grazing angles, the effective wavelength in the absorbing direction is very long, and we need to modify the default wavelength in the PML settings (shown below). This change to the settings is only necessary if we are interested in angles of incidence greater than ~75°.

The PML settings modified to account for grazing angles of incidence.

Since our domain is now bounded by PMLs above and below, the port that launches the wave must now be placed within the modeling domain. To do this, we use the Slit Condition option to define an interior port that is backed by a domain. This means that the port now launches a wave in one direction, emanating from this interior boundary. Any light reflected back toward the boundary passes through unimpeded and then gets absorbed by the PML.

Although this is a good way to launch the wave, we will no longer use the Port boundary condition to compute how much light is reflected, since we would have to add hundreds of diffraction ports, and similarly, we’d need hundreds of ports to compute the total transmittance.

To monitor the total transmitted and reflected light, we instead introduce two additional interior boundaries to the model, placed just in front of the PML domains (shown in the schematic above). At these two boundaries, we integrate the power flux in the upward and downward directions, normalized by the incident power, which gives us the total reflectance and transmittance. To more accurately determine the integral of the power flux at these boundaries, we also introduce a boundary layer mesh composed of a single layer of elements much smaller than the wavelength.

On the incident side, we place this monitoring boundary above the interior port. The launching port introduces a plane wave propagating toward the material interface. The light reflected at the interface passes through this interior port, then moves through the boundary at which we monitor reflectance, and is absorbed in the PML.

The plots below show sample results of the transmittance, reflectance, and absorbance. They are notably different from the smooth surface and periodically varying surface results. Note that the sweep over the angle of incidence terminates at 85° off normal. Of course these plots will look slightly different for each different random geometry case that we run.

The transmittance, reflectance, and absorbance of light normally incident on a rough glass surface.

The transmittance, reflectance, and absorbance of 550-nm light at angles of incidence up to 85° off normal.

Concluding Thoughts on Calculating the Optical Properties of Rough Surfaces

Here, we have introduced a modeling approach that is appropriate for computing the optical transmission and reflection from a rough surface. This method contrasts with the approach for modeling a uniform optically flat surface as well as the one for modeling surfaces with periodic variations. The modeling method for rough surfaces can also be used for the modeling of periodic structures that have a very long period, such as when the scattering into different diffraction orders is not of interest.

Modeling truly random surfaces does require some care, as the geometry needs to be altered to ensure that it is periodic. Furthermore, the domain size and number of different random geometries studied must be large enough to give statistically meaningful results. Since this requires solving many different variations of the same model and postprocessing the results, it is helpful to use the Application Builder, LiveLink™ for MATLAB®, or LiveLink™ for Excel® in our modeling workflow.

Further Resources

• See how to create a rough surface as a sum of sine functions
• See how to create a random geometry using model methods
• Check out other blog posts related to simulating wave optics:
  • Modeling of Materials in Wave Electromagnetics Problems
  • Modeling of Metallic Objects in Wave Electromagnetics

MATLAB is a registered trademark of The MathWorks, Inc. Microsoft and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Building a Model of Swiss Cheese

Determining the best cheese in the world is a hotly contested task, but I’ll go ahead and add my opinion: a good Emmentaler cheese is hard to beat. A master cheesemaker might joke that it’s really the holes that add the flavor, so if we’re going to build a good COMSOL Multiphysics model of a wheel of cheese, we need to include the holes.

A model of Emmentaler cheese, with randomly positioned and sized holes.

It turns out that the reasons for the holes in Swiss cheese are quite complicated, so we aren’t going to try to model the hole formation itself. Instead, we will simply set up a model of the cheese, as shown in the image above. We want to include a randomly distributed set of holes within the cheese, with a random hole radius between some upper and lower limit on the radius. We can build this randomized geometry in COMSOL Multiphysics version 5.3 using the new Model Method functionality. Let’s find out how…

Introducing Model Methods in COMSOL Multiphysics®

When you’re running COMSOL Multiphysics® version 5.3 on the Windows® platform and working with the Model Builder, you will now see a Developer tab in the ribbon, as shown in the screenshot below. One of the options is Record Method. When clicked, this option prompts you to enter a new method Name and Method type. You can enter any string for the method name, while the method type can either be Application method or Model method.

An Application method can be used within a COMSOL app — a process introduced in this tutorial video. A Model method can be used within the underlying COMSOL Multiphysics model and can operate on (and add information to) the existing model data.

The Developer tab, showing the Record Method and Run Model Method buttons.

After you click the OK button in the Record Method dialog box, you can see a red highlight around the entire graphical user interface. All operations performed are recorded in this method until you click the Stop Recording button. You can then switch to the Application Builder and view your recorded method. The screenshot below shows the Application Builder and the method after we record the creation of a single geometry object. The object is a cylinder with the tag cyl1, a radius of 40 cm, and a height of 20 cm — a good starting approximation for a wheel of cheese.

The Application Builder showing code for a model method used to create a geometry.

When we’re working with the Model Builder, we can call this model method within any other model file (as long as it doesn’t already have an existing object with tag cyl1 within the geometry sequence) via the Run Model Method button in the Developer tab. Of course, this simple model method just creates a cylinder. If we want to model the holes, we need to introduce a bit of randomness into our method. Let’s look at that next.

Creating a Random Set of Geometry Features

Within a model method, you can call standard Java® classes, such as the Math.random class, which returns a double-precision number greater than or equal to 0.0 and less than 1.0. We want to use this class, along with a little bit of extra code, to set up a specified number of randomly positioned and sized holes within the model of the wheel of cheese.

Let’s say that we want 1000 holes randomly distributed throughout the cheese that each have a random radius between 0.1 cm and 1 cm. We also need to keep in mind that Emmentaler cheese has a natural rind within which no holes form. So, we need to add a bit of logic to make sure that our 1000 holes are actually inside the cheese. The complete model method below (with line numbers added and text strings in red) shows how to do this.

1  int NUMBER_OF_HOLES = 1000;
2  int ind = 0;
3  double hx, hy, hz, hr = 0.0;
4  double CHEESE_HEIGHT = 20.0;
5  double CHEESE_RADIUS = 40.0;
6  double RIND_THICKNESS = 0.2;
7  double HOLE_MIN_RADIUS = 0.1;
8  double HOLE_MAX_RADIUS = 1.0;
9  model.component("comp1").geom("geom1").lengthUnit("cm");
10 model.component("comp1").geom("geom1").selection().create("csel1", "CumulativeSelection");
11 while (ind  CHEESE_RADIUS-RIND_THICKNESS) {continue; }
17   if (((hz-hr)  CHEESE_HEIGHT-RIND_THICKNESS)) {continue; }
18   model.component("comp1").geom("geom1").create("sph"+ind, "Sphere");
19   model.component("comp1").geom("geom1").feature("sph"+ind).set("r", hr);
20   model.component("comp1").geom("geom1").feature("sph"+ind).set("pos", new double[]{hx, hy, hz});
21   model.component("comp1").geom("geom1").feature("sph"+ind).set("contributeto", "csel1");
22   ind++;
23 }
24 model.component("comp1").geom("geom1").create("cyl1", "Cylinder");
25 model.component("comp1").geom("geom1").feature("cyl1").set("r", CHEESE_RADIUS);
26 model.component("comp1").geom("geom1").feature("cyl1").set("h", CHEESE_HEIGHT);
27 model.component("comp1").geom("geom1").create("dif1", "Difference");
28 model.component("comp1").geom("geom1").feature("dif1").selection("input").set("cyl1");
29 model.component("comp1").geom("geom1").feature("dif1").selection("input2").named("csel1");
30 model.component("comp1").geom("geom1").run();

Let’s go through this model method line by line:

1. Initialize and define the total number of holes that we want to put in the cheese.
2. Initialize and define an index counter to use later.
3. Initialize a set of double-precision numbers that holds the xyz-position and radius of each hole.
4–8. Initialize and define a set of numbers that defines the cheese height, radius, ring thickness, and maximum and minimum possible hole radius in centimeters.
9. Set the length unit of the geometry to centimeters.
10. Create a new selection set, with tag csel and name CumulativeSelection. Note that if such a selection set already exists, the method fails at this point. You could also modify the method to account for this, if you want to run the method repeatedly in the same file.
11. Initialize a while loop to create the specified number of holes.
12–14. Define the xyz-position of the holes by calling the random method and scaling the output such that the xyz-position of the holes lies within the outer Cartesian bounds of the cheese.
15. Define the hole radius to lie between the specified limits.
16–17. Check if the hole position and size are such that the hole is actually outside of the cheese. If so, continue to the next iteration of the while loop without executing any of the remaining code in the loop. This check can be done in a single line or split into three lines, depending on your preference of programming style.
18. Create a sphere with a name based on the current index value.
19–20. Set the radius and position of the newly created sphere. Although the radius can be passed in directly as a double, the position must be specified as an array of doubles.
21. Specify that this sphere feature is part of (contributes to) the selection set named csel1.
22–23. Iterate the index, indicating that a sphere has been created, and close the while loop.
24–26. Create a cylinder primitive that represents the wheel of cheese.
27–29. Set up a Boolean difference operation. The object to add is the cylinder primitive, while the object to subtract is the selection of all of the spheres.
30. Run the entire geometry sequence, which cuts all of the spheres out of the cylinder, forming the wheel of cheese.

We can run this method in a new (and empty) model file to create a model of a wheel of cheese. Each time we rerun the method, we will get a different model. The geometry sequence in the model file contains all of the spheres and the cylinder primitives as well as the Boolean operation.

If we want to, we could also add some additional code to our model method to write out a geometry file of just the final geometry: the cheese. This geometry file can be written in the COMSOL Multiphysics native or STL file format. We could also write out to Parasolid® software or ACIS® software file formats with any of the optional modules that include the Parasolid® software kernel. Working with just the final geometry after it has been exported and reimported is faster than working with the complete geometry sequence.

We can see the final results of our efforts below. Delicious!

A model of a wheel of Emmentaler cheese, ready to be eaten.

Closing Remarks on Creating a Randomized Geometry via Model Methods

We’ve looked at a simple example of how to use model methods to create a geometry with randomly placed and sized features. There are some questions that we haven’t addressed here, such as how to ensure that the holes are not overlapping and how to come up with a close-packed arrangement, but these turn out to be difficult mathematical questions that are fields in their own right.

Of course, there is a lot more that you can do with model methods, which we will save for another day. There are also other ways to create a random geometry, such as by parametrically defining a surface.

Related Resources

• Read about another use of model methods: generating simulation results that you can see and hear
• Check out the new features in COMSOL Multiphysics® version 5.3 on the Release Highlights page

ACIS is a registered trademark of Spatial Corporation. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Parasolid is a trademark or registered trademark of Siemens Product Lifecycle Management Software Inc. or its subsidiaries in the United States and in other countries. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Starting Simple: The Heat Transfer Coefficient

Let’s start by considering a model of the electrical heating of a busbar, shown below. You may recognize this as an introductory example to COMSOL Multiphysics, but if you haven’t already modeled it, we encourage you to review this model by going through the Introduction to COMSOL Multiphysics PDF booklet.

Electric currents (arrow plot) flowing through a metal busbar lead to resistive heating that raises the temperature (color surface plot).

In this example, we model electric current flowing through a busbar. This leads to resistive heating, which in turn causes the temperature of the busbar to rise. We assume that there is only heat transfer to the surrounding air, neglecting any conductive heat transfer through the bolts and radiative heat transfer. The example also initially assumes that there isn’t any fan forcing air over the busbar. Thus, the transfer of heat to the air is via natural, or free, convection.

As the part heats the surrounding air, the air gets hotter. As the air gets hotter, its density decreases, causing the hot air to rise relative to the cooler surrounding air. These free convective air currents increase the rate of heat transfer from the part to the surrounding air. The air currents depend on the temperature variations as well as the geometry of the part and its surroundings. Convection can, of course, also happen in any other gas or liquid, such as water or transformer oil, but we will center this discussion primarily around convection in air.

We can classify the surrounding airspace into one of two categories: Internal or External. Internal means that there is a finite-sized cavity (such as an electrical junction box) around the part within which the air is reasonably well contained, although it might have known air inlets and outlets to an external space. We then assume that the thermal boundary conditions on the outside of the cavity and at the inlets and outlets are known. On the other hand, External implies that the object is surrounded by what is essentially an infinitely large volume of air. We then assume that the air temperature far away from the object is a constant, known value.

The settings for a constant heat transfer coefficient.

The introductory busbar example assumes free convective heat transfer to an external airspace. This is modeled using the following boundary condition for the heat flux:

where the external air temperature is T_ext = 25°C and is the heat transfer coefficient.

This single-valued heat transfer coefficient represents an approximate and average of all of the local variations in air currents. Even for this simple system, any value between could be an appropriate heat transfer coefficient, and it’s worth trying out the bounding cases and comparing results.

If we instead know that there is a fan blowing air over this structure, then due to the faster air currents, we use a heat transfer coefficient of to represent the enhanced heat transfer.

If the surrounding fluid is a liquid such as water, then the range of free and forced heat transfer coefficients are much wider. For free convection in a liquid, is the typical range. For forced convection, the range is even wider: .

Clearly, entering a single-valued heat transfer coefficient for free or forced convection is an oversimplification, so why do we do it? First, it is simple to implement and easy to compare the best and worst cases. Also, this boundary condition can be applied with the core COMSOL Multiphysics package. However, there are some more sophisticated approaches available within the Heat Transfer Module and CFD Module, so let’s look at those next.

Using a Convective Correlation

A convective correlation is an empirical relationship that has been developed for common geometries. When using the Heat Transfer Module or CFD Module, these correlations are available within the Heat Flux boundary condition, shown in the screenshot below.

The Heat Flux boundary condition with the external natural convection correlation for a vertical wall.

Using these correlations requires that you enter the part’s characteristic dimensions. For example, with our busbar model, we use the External natural convection, Vertical wall correlation and choose a wall height of 10 cm to model the free convective heat flux off of the busbar’s vertical faces. We also need to specify the external air temperature and pressure. These values can be loaded from the ASHRAE database, a process we describe in a previous blog post.

The table below shows schematics for all of the available correlations. They take the information about the surface geometry and use a Nusselt number correlation to compute a heat transfer coefficient. For the horizontally aligned faces of the busbar, for example, we use the Horizontal plate, Upside and Horizontal plate, Downside correlations.

When using the Forced Convection correlations, you must also enter the air velocity. These convective correlations have the advantage of being a more accurate representation of reality, since they are based on well-established experimental data. These correlations lead to a nonlinear boundary condition, but this usually results in only slightly longer computation times than when using a constant heat transfer coefficient. The disadvantage is that they are only appropriate to use when there is an empirical relationship that is reasonable for the part geometry.

	Free Convection	Forced Convection
External
Internal

The available Convective Correlation boundary conditions.

Note that all of the above convective correlations, even those classified as Internal, assume the presence of an infinite external reservoir of fluid; e.g., the ambient airspace. The heat carried away from the surfaces goes into this ambient airspace without changing its temperature, and the ambient air coming in is at a known temperature. If, however, we are dealing with convection in a completely enclosed container, then none of these correlations are appropriate and we must move to a different modeling approach.

Approximating Free Convection in an Enclosure Using an Enhanced Thermal Conductivity

Let’s consider a rectangular air-filled cavity. If this cavity is heated on one of the vertical sides and cooled on the other, then there will be a regular circulation of the air. Similarly, there will be air circulation if the cavity is heated from below and cooled from above. These cases are shown in the images below, which were generated by solving for both the temperature distribution and the air flow.

Free convective currents in vertically and horizontally aligned rectangular cavities.

Solving for the free convective currents is fairly involved. See, for example, this blog post on modeling natural convection. Therefore, we might like to find a simpler alternative. Within the Heat Transfer Module, there is the option to use the Equivalent conductivity for convection feature. When using this feature, the effective thermal conductivity of the air is increased based upon correlations for the horizontal and vertical rectangular cavity cases, as shown in the screenshot below.

The Equivalent conductivity for convection feature and settings.

The air domain is still explicitly modeled using the Fluid domain feature within the Heat Transfer interface, but the air flow fields are not computed and the velocity term is simply neglected. The thermal conductivity is increased by an empirical correlation factor that depends on the cavity dimensions and the temperature variation across the cavity. The dimensions of the cavity must be entered, but the software can automatically determine and update the temperature difference across the cavity.

Temperature distribution in vertically and horizontally aligned cavities using the Equivalent conductivity for convection feature. The free convective air currents are not computed. Instead, the thermal conductivity of the air is increased.

This approach for approximating free convection in a completely closed cavity requires us to mesh the air domain and solve for the temperature field in the air, but this usually adds only a small computational cost. The disadvantage of this approach is that it is not very applicable for nonrectangular geometries.

Approximating Forced Convection in an Enclosure Using Isothermal Domains

Next, let’s consider a completely sealed enclosure, but with a fan or blower inside that actively mixes the air. We can reasonably assume that well-mixed air is at a constant temperature throughout the cavity. In this case, it is appropriate to use the Isothermal Domain feature, which is available with the Heat Transfer Module when the Isothermal domain option is selected in the Settings window.

The settings associated with using the Isothermal Domain interface.

A well-mixed air domain can be explicitly modeled using the Isothermal Domain feature. In the model, the temperature of the entire domain is a constant value. The temperature of the air is computed based upon the balance of heat entering and leaving the domain via the boundaries. The Isothermal Domain boundaries can be set as one of the following options:

• Thermally Insulated: no heat transfer across the boundary
• Continuity: continuity of temperature across the boundary
• Ventilation: a known mass flow of fluid, of known temperature, into or out of the isothermal domain
• Convective Heat Flux: a user-specified heat transfer coefficient, as described earlier
• Thermal Contact: a specific thermal resistance

Of all of these boundary condition options, the Convective Heat Flux is the most appropriate for well-mixed air in an enclosed cavity.

Representative results when using an Isothermal Domain feature. The well-mixed air domain is a constant temperature and there is heat transfer to the surrounding solid domains via a specified heat transfer coefficient.

Modeling the Airflow Explicitly

The most computationally expensive approach, but also the most general, is to explicitly model the airflow. We can model both forced and free convection as well as simulate an internal or external flow. This type of modeling can be done with either the Heat Transfer Module or CFD Module.

An example of computing air flow and temperature within an enclosure.

If you finished the Introduction to COMSOL Multiphysics booklet, you have already solved one example of an internal forced convection model. You can learn more about explicitly modeling airflow in the resources mentioned at the end of this post.

When Can We Ignore Free Convection Entirely?

We will finish up this topic by addressing the question: When can free convection in air be ignored and how can we model these cases? When a cavity’s dimensions are very small, such as a thin gap between parts or a very thin tube, we run into the possibility that the viscous damping will exceed any buoyancy forces. This balance of viscous to buoyancy forces is characterized by the nondimensional Rayleigh number. The onset of free convection can be quite varied depending on boundary conditions and geometry. A good rule of thumb is that for dimensions less than 1mm, there will likely not be any free convection, but once the dimensions of the cavity get larger than 1cm, there likely will be free convective currents.

So how can we model heat transfer through these small gaps? If there is no air flow, then these air-filled regions can simply be modeled as either a solid or a fluid with no convective term. This is demonstrated in the Window and Glazing Thermal Performances tutorial. It is also appropriate to model the air as a solid within any microscale enclosed structure.

If these thin gaps are very small compared to the other dimensions of the system being analyzed, you can further simplify the gaps by modeling them via the Thin Layer boundary condition with a Thermally thick approximation layer type. This boundary condition introduces a jump in temperature across interior boundaries based on the specified thickness and thermal conductivity.

The Thin Layer boundary condition can model a thin air gap between parts.

We can use the previous two approaches within the core COMSOL Multiphysics package. In the Heat Transfer Module, there are additional options for the Thin Layer condition to consider more general and multilayer boundaries, which can be composed of several layers of materials.

Closing Remarks on Modeling Natural and Forced Convection in COMSOL Multiphysics®

Before closing out this discussion, we should also quickly address the question of radiative heat transfer. Although we haven’t discussed radiation here, an engineer must always take it into consideration. Surfaces exposed to ambient conditions will radiate heat to the surroundings and be heated by the Sun. The magnitude of radiative heating from the Sun is significant — about 1000 watts per square meter — and should not be neglected. For details on modeling radiative heat transfer to ambient conditions, read this previous blog post.

There will also be radiative heat transfer between interior surfaces. Radiative heat flux between surfaces is a function of the difference of temperature to the fourth power. Keep in mind that radiative heat transfer between two surfaces at 20°C and 50°C will be 200 watts per square meter at most, but rises to 1000 watts per square meter for surfaces at 20°C and 125°C. To correctly compute the radiative heat transfer between surfaces, it is also important to compute the view factors with the Heat Transfer Module.

Today we looked at several approaches for modeling convection, starting from the simplest approach of using a constant convective heat transfer coefficient. We then discussed using an Empirical Convective Correlation boundary condition before going over how to use an effective thermal conductivity within a domain and an isothermal domain feature, approaches with higher accuracy and only a slightly greater computational cost. The most computationally intensive approach — explicitly computing the flow field — is, of course, the most general. We also touched on when it is appropriate to neglect free convection entirely and how to model such situations. You should now have a greater understanding of the available options and trade-offs for modeling free and forced convection. Happy modeling!

Additional Resources

• Learn about explicitly modeling air flow and heat transfer on the COMSOL Blog
  • Conjugate Heat Transfer
  • Introduction to Modeling Natural Convection in COMSOL Multiphysics®
  • Compressibility Options and Buoyancy Forces for Flow Simulations
  • Which Turbulence Model Should I Choose for My CFD Application?
• Get an introduction to simulating heat transfer in an archived webinar

The Initial Coil Design and Optimization Problem

Let’s suppose that we are tasked with designing a coil such that the magnetic field along part of the centerline is as close to a target value as possible. As we saw in an earlier blog post, we can achieve this by adjusting the current through each turn of the coil to be different. However, this requires that we include a separate current control for each turn in our physical design. Instead, we can use a single current control for the entire coil and adjust the physical spacing of the coils along the axial direction.

A ten-turn axisymmetric coil. The objective is to alter the magnetic field at the centerline (green).

The case that we will consider here is shown in the image above. A ten-turn axisymmetric coil is driven by a single current source; that is, the same current flows through each turn. The initial coil design spaces the 1-cm-diameter coil turns a distance of S₀ = 4 cm apart. Since the coil is axisymmetric (and we are only interested in solutions that are symmetric about the z = 0 plane), we can use the reduced computational domain shown in the schematic below.

The computational model. We want to change the five coil positions and the coil current.

Our optimization objective is to get the B_z field as close as possible to a desired value, B₀, along a portion of the centerline by changing the coil current and z-location of the five coils. Each coil can move and there must be a gap of G₀ between the adjacent coils, so the first coil offset has a different lower bound. We also need to include a constraint on the peak current as well as constrain the current to be greater than zero. Although physically speaking, it isn’t necessary to constrain the current to be greater than zero, it’s a good optimization modeling practice to do so, since this keeps the constrained design space small.

More formally, these statements can be written as:

We solve this problem with a combination of parameter and shape optimization by using the Optimization and Deformed Geometry interfaces in COMSOL Multiphysics.

Setting Up and Solving the Optimization Problem in COMSOL Multiphysics®

We can begin our implementation by reviewing the model developed here, which optimizes for a particular field value. We start with the same Optimization interface and Integral Objective feature introduced in the previous blog post. Two Global Control Variable features are then used. The first sets up the displacements of the five coils, using Control Variables Scaling to scale the optimization variables close to unity. The second Global Control Variables feature similarly defines and constrains the current.

The definitions of the variables that control the five coils’ positions.

The five Control Variables shown in the screenshot above define the displacements of the coils, as well as a small square region of space around each coil, which is shown as the green domains in the illustration below. As these green domains move up and down, the surrounding yellow domains must stretch and shrink to accommodate, while the surrounding blue domain is fixed. Since we know the displacements of the green domains, we can specify a linear variation of displacement along all of the red edges. This linear displacement variation is computed using a Coefficient Form Boundary PDE interface, as described in an earlier blog post on modeling translational motion.

The definitions of the deformations for the various domains in the model.

This information about the specified displacements of the various domains is set up using the Deformed Geometry interface, as shown in the screenshot below. The Prescribed Deformation domain features move the green domains and the yellow domains are allowed to deform due to the Free Deformation domains. The Prescribed Mesh Displacement boundary features apply to the black and red edges and completely define the deformations of the yellow domains.

The control over the coil turn displacement via the Prescribed Deformation feature in the Deformed Geometry interface.

As a consequence of setting up the Deformed Geometry interface in this way, the five control variables for the positions of the coils now represent a shape optimization problem. Previously, we have discussed shape optimization in a more general case from structural mechanics. Shape optimization takes advantage of the ability of COMSOL Multiphysics to compute design sensitivities with respect to changes in the shape of the geometry.

We also need to define a set of Global Inequality Constraints to prevent the green domains surrounding the coils from getting too close to each other and intersecting. The screenshot below shows this implementation. Note that the constraint is scaled with respect to the gap size G₀ so that the constraint equation is also close to one in magnitude.

One of the four constraints that keep the coils from getting too close to each other.

Due to the large deformations that can occur in the domains around the coils that stretch and contract, it is also helpful to use a mapped mesh.

A mapped mesh is used in the deforming domains around the coils. The infinite element domain also has a mapped mesh.

We can then solve this problem using a gradient-based optimization solver (SNOPT), taking advantage of the analytically computed gradients. The current through the coil and the coil positions are adjusted to minimize the above objective function. The results of the optimization are shown in the figure below.

The magnetic flux density’s z-component along the centerline for the optimized coil.

The optimized coil positions.

Concluding Thoughts on Optimizing the Spacing of Electromagnetic Coils

We have introduced a model that uses a combination of shape and parameter optimization to adjust the coil current and spacing between the coils in a 2D axisymmetric coil. By taking advantage of the Optimization and Deformed Geometry interfaces, we are able to analytically compute the derivatives for this problem and converge to an optimum very quickly.

Further Resources

• Read a blog post on modeling a linear electromagnetic plunger
• Browse the Optimization category on the COMSOL Blog