The typical home thermostat for your furnace or heater has two temperature setpoints:

*On*, at which the heat is turned on at the maximum possible rate*Off*, at which the heat is turned off

In practice, you may only directly control one of these setpoints, with the other setpoint automatically set to a few degrees different. Such a control scheme can be modeled with the approach developed in a previous blog post on thermostats. Today, we will include a time delay between switching the heater state in our thermostat simulation.

A delay can be implemented for many reasons, but one of the main reasons is to prevent *short-cycling* of the heater. Turning a device on and off repeatedly can lead to excessive wear on the system components, which will incur repair costs that we want to avoid.

There are various different delay schemes that we can use to prevent short-cycling. One common approach is to maintain the heater in either the on or off state for some defined minimum time before switching. Let’s look at how this control scheme is implemented within COMSOL Multiphysics.

Let’s suppose that you have a thermal model of a house or any other system wherein you want to control a heater using a thermostat with a delay. Within such a model, you can choose one point as the location of the thermostat temperature sensor, as described in our earlier blog post on modeling thermostats. As previously mentioned, we will use the *Events* interface to control the on/off state of the heater in our model.

*A thermal model of a house. The thermostat monitors the sensor temperature and controls the heater’s on/off state.*

Before we get to the implementation, let’s write out exactly how we want our thermostat to work. We have a thermostat with an upper and lower setpoint and we want the heater to maintain its current state, either on or off, for a specified delay time. We can write this as two separate statements:

- If the heater has been in the off state for more than the specified delay time and if the temperature is below the lower setpoint, then turn the heater on.
- If the heater has been in the on state for more than the specified delay time and if the temperature is above the upper setpoint, then turn the heater off.

These two statements can be implemented within the *Events* interface. We simply need to introduce a way to track the time that has elapsed since the last switching of the thermostat. The screenshots below show how to set up these conditions.

*The *Discrete States* interface defines two discrete variables that determine the heater state.*

The *Events* interface contains several features, starting with the *Discrete States* interface shown in the screenshot above. Two discrete variables are defined: `HeaterState`

and `TimeOfSwitch`

. The `HeaterState`

variable is initially one, meaning that at the start of the simulation, the heater is turned on. This variable is used within the *Heat Transfer in Solids* interface as a multiplier on the applied heat load. To turn the heater off, the `HeaterState`

variable is set to zero instead. The `TimeofSwitch`

variable stores the time of the last switching event. For this problem, the initial value is zero, which means that at ` t=0`

, the heater state was switched.

These two *Discrete State* variables are only changed when an event is triggered, and for this to happen, we need to check the elapsed time since the last switching event, and we need to check the temperature of the sensor against the upper and lower setpoints. This is done with the *Indicator States* interface, as shown in the screenshot below.

*The* Indicator States* interface defines three different indicators that will trigger an event.*

We can see in the above screenshot that three different indicators are tracked during the simulation. First, the `TurnOn`

indicator evaluates the expression `T_bot-T_s`

, which will go from negative to positive when we want to turn the heater on, where `T_bot`

is a *Global Parameter*. The variable `T_s`

is the sensor temperature and is defined using a *Point Integration Coupling* and a *Variable Definition*, as described in our earlier blog post on thermostats. Similarly, the `TurnOff`

indicator evaluates ` T_s-T_top`

and goes from negative to positive when we want to turn the heater off.

The `OkToSwitch`

indicator evaluates `t-TimeOfSwitch-Delay`

and goes from negative to positive after the heater is either in the on or off state for longer than the specified delay time, where ` Delay`

is also a *Global Parameter*. These discrete and indicator states are used to trigger two *Implicit Events*, as shown in the following screenshots.

*The first* Implicit Event* controls when the heater is turned on.*

In the above screenshot, the first *Implicit Event* is used to turn on the heater. The *Event Condition* is: `(OkToSwitch>0)&&(HeaterState==0)&&(TurnOn>0)`

. This logical condition can be read as: If the time since the last switching event is greater than the specified delay time, and if the heater is currently off, and if the sensor temperature is below the turn on setpoint, trigger an implicit switching event. When this event is triggered, the solver is restarted and reinitializes `HeaterState`

to one, which turns on the heater. Additionally, `TimeOfSwitch`

is reinitialized to ` t`

, the current time. These two variables will remain unchanged until another implicit event is triggered.

*The second *Implicit Event* controls when the heater is turned on.*

The second *Implicit Event*, shown above, is almost identical to the first, but instead triggers a turn-off event. When the condition `(OkToSwitch>0)&&(HeaterState==1)&&(TurnOff>0)`

is satisfied, this event reinitializes `HeaterState`

to zero and ` TimeSinceSwitch`

to the current time.

You may ask yourself why, in these two implicit events, we check if the heater is off before triggering it to turn on (and similarly check if the heater is on before we trigger it to turn off). This additional check is done to prevent any events from getting triggered and reinitializing `TimeOfSwitch`

too often. The system may naturally (due to some change or fluctuation in the other boundary conditions) get into a state where the sensor temperature goes above the upper setpoint without any heating. Or, the sensor temperature could stay below the lower setpoint even though the heater is on. We do not want such cases to result in any events being triggered, hence these additional checks.

With these features as just described, we have implemented our thermostat with delay between switching. Before solving, make certain that the initial values of the *Discrete States*, the `HeaterState`

and the ` TimeOfSwitch`

variables, are appropriate for the initial heater state, and the last switching event. Also keep in mind that you may need to adjust the *Event Tolerance*, as demonstrated in our previous blog post on thermostats.

Let’s now look at some results.

*The thermostat with delay can switch only every five minutes. The horizontal dashed lines represent the thermostat setpoints.*

In the above plot, we can observe the thermostat delay behavior. The sensor temperature is initially below both setpoints and the heater is switched on at the time of zero. The system takes about seven minutes for the sensor temperature to reach the upper setpoint, at which time the heater turns off. The system starts to cool down quite rapidly, but the thermostat cannot switch back on until five minutes have elapsed. The thermostat temperature dips below the lower setpoint before the heater switches back on. After the heater is switched on, the system temperature rises above the upper setpoint, again due to the five-minute switching delay time. We can observe this over- and under-shoot behavior repeating in time.

The technique we’ve outlined here will enable you to implement a thermostat model with a delay between any switching events and is representative of many real control schemes. The key difference for implementing a delay in your thermostat simulation versus a thermostat without delay is the introduction of an additional *Indicator State* variable that keeps track of the thermostat switching time.

Of course, this approach is useful far beyond just temperature control. Within COMSOL Multiphysics, we can use the *Events* interface whenever we solve a transient problem.

- If you have additional questions about this technique, or would like to use COMSOL Multiphysics for your modeling needs, please don’t hesitate to contact us
- Read these related blog posts for more information on the
*Events*interface and thermal modeling of a house:

Let’s say that you want to quickly predict the temperature of an enclosed structure that is exposed to ambient conditions. This could be a small structure, such as a junction box on a utility pole or a shipping container, or perhaps a structure that is familiar to all of us: a house.

To begin, we can consider a small house, as illustrated below. The house features four walls, a roof, one big room, a door, and a few windows. We will assume that there is a fan that causes the air inside to be reasonably well-circulated, meaning that if we measure the air temperature at any one point inside, it will be the same as it is at any other point inside the room. This is a very good approximation of what happens if we have a mixing ventilation system.

*A very simple model of a house. We are interested in the temperature inside the structure.*

Since the air is well-circulated, we only need to solve for a single spatially uniform air temperature. This room air temperature varies over time due to the air conditioning and heating, along with heat transfer through the walls. At the outside of the walls, we also need to apply thermal boundary conditions to reflect the ambient air temperature, wind speed, and solar heat loads.

Now we all know that weather is notoriously unpredictable. Therefore, rather than trying to build a thermal model of the environment *around* our house, we instead look to historical weather data. The American Society of Heating, Refrigerating, and Air-Conditioning Engineers compiles a database of information gathered at weather stations located around the world. In COMSOL Multiphysics® version 5.2a, this tabulated data is now available as input for simulations in COMSOL Multiphysics.

*A weather station records direct and scattered solar irradiance, wind speed, and air temperature.*

The tabulated meteorological data includes the historical data for over 6000 different weather stations spanning the globe. Temperature, dew point, wind speed, air pressure, and direct and diffuse solar irradiation as a function of calendar day and time are available. Direct solar irradiation refers to the radiation that comes directly from the sun, while diffuse irradiance results from the scattering of direct sunlight through the particulates and clouds in the atmosphere. You can use the data from any nearby weather station as a reasonable estimation of the ambient conditions for your models. It is up to you to decide if you want to use the average, the average low or high, or the peak low or high temperature, dew point, and wind speed. Average high and average low are defined as the average plus or minus one standard deviation.

*Sample plot of average, average high and low, and peak high and low temperature over two days.*

Let’s now look at using such features within COMSOL Multiphysics to help us model the air inside our house and the ambient conditions outside.

To model a well-mixed fluid domain like the air inside our house, we can use the *Isothermal Domains* feature available with the Heat Transfer Module. To use this feature, you first need to check the relevant check box in the *Physical Model* settings, as shown in the screenshot below.

*The “Isothermal domain” check box.*

Once this functionality is enabled, you will be able to add Isothermal Domain features to the *Heat Transfer* interface, as depicted in the following screenshot. By default, this feature will compute the total mass and thermal heat capacity of the domain based on the assigned material properties. You can override these calculations with a user-specified domain mass and specific heat, if desired.

*The* Isothermal Domain *interface.*

The temperature variation of the isothermal domain over time is governed by the heat flux into and out of the domain through its boundaries. This is defined via the Isothermal Domain Interface boundary condition, which is illustrated in the screenshot below. You can specify one of several different conditions: Thermal Insulation, Continuity, Thermal Contact, Ventilation, or Convective Heat Flux. The last of these conditions, the Convective Heat Flux, is the most appropriate for describing the heat transfer between the average temperature of a well-mixed fluid domain and a solid domain.

*The boundary condition between an isothermal domain and surrounding domains.*

Now that we have seen how to define a uniform air temperature within the house, let’s turn our attention outward, addressing the boundary conditions on the outside surfaces that are exposed to ambient conditions.

The first step here is to choose the location of the weather station with the data that we want to use. This is handled in the settings for all of the heat transfer interfaces, as demonstrated below. You can choose from over 6000 different weather stations and select the date and time for the data that you want. By default, the software will update the time from the solver, so the ambient conditions will change if you are simulating for a long period of time.

*Screenshot showing how to define the ambient environmental data.*

Once the location and time defining the ambient conditions are selected, the surrounding air temperature and wind velocity are defined and can be referenced from other features within the physics interface, such as the Heat Flux boundary condition.

*The ambient temperature, pressure, and wind speed are referenced by the Heat Flux boundary condition.*

The ambient solar irradiance is used within the *External Radiation Source* feature, when using the *Solar Position* option, as highlighted below. Note that the ambient data contains the solar flux at noon under clear sky conditions. By entering the location and the time of day within this feature, the software will automatically recompute the orientation of the incident sunlight over the course of the day, as described in our earlier blog post on solar heating.

*The ambient solar irradiance is an input for the External Radiation Source feature.*

Now that we’ve seen all of the features that can be utilized, let’s take a look at some representative results. The animation below, for instance, plots the temperature over time and shows the incident direction of the solar flux.

*Animation showing temperature and incident solar flux.*

Here, we have looked at a set of features that are useful for modeling structures that are exposed to ambient conditions and filled with well-mixed air. If you want to compute the airflow and air temperature variations within your structures, I encourage you to read our blog post “Modeling a Displacement Ventilation System“. You may also want to actively heat or cool your structures. For an introduction to this topic, take a look at my previous blog post “Implementing a Thermostat with the Events Interface“.

Say that you are further interested in modeling ventilation systems within larger buildings. If so, you will also want to consider the Pipe Flow Module, one of the add-on products to COMSOL Multiphysics. This video presentation offers further insight on modeling pipe flow for heating and ventilation.

We have not addressed the modeling of the walls here in detail. The model shown above simply treats the walls as uniform blocks of different materials. COMSOL Multiphysics is an ideal platform for performing a detailed analysis of the heat loss due to thermal bridging. Here are some example models that you can use to get started:

- Thermal Bridges in Building Construction — 3D Structure Between Two Floors
- Thermal Bridges in Building Construction — 3D Iron Bar Through Insulation Layer
- Thermal Bridges In Building Construction — 2D Square Column
- Thermal Bridges in Building Construction — 2D Composite Structure
- Parameterized Window and Glazing Preset Model
- Parameterized Window Preset Model
- Parameterized Roller Shutter Preset Model

Suppose you are working on a COMSOL Multiphysics model and performing thermal analyses of systems. You’re working with a team of people performing other types of analyses. Your colleagues aren’t quite as lucky as you and don’t get to use COMSOL Multiphysics, but they still need access to your modeling results. Fortunately, you can quickly convert your analysis data into a very specific text file format that can be read by the software tool that your colleagues are using.

*A simple COMSOL Multiphysics thermal model that has different element types.*

Now, let’s suppose that you’re performing steady-state thermal analyses of models containing all kinds of different elements, including tetrahedral; pyramidal; prismatic; and hexahedral (brick) types, as shown above. Let’s further suppose that the software tool we will be reading the data into requires that we use a linear discretization, meaning that we need to write out a temperature at each of the nodes (vertices) defining the corners of the elements and a linear interpolation of temperature will be used to compute the temperature fields within the elements. Thus, we need to write out all of the vertex locations; the temperature data at each of these vertices; and a description of which vertices define each element, and how.

There are, of course, many different ways in which this kind of information can be written. For the purposes of today’s blog post, we will assume a simple comma-delimited format, a generic sample of which is shown below.

N, 1, 0.0, 0.0, 0.0 ... N, 1000, 10.0, 10.0, 10.0 D, 1, 332.0 ... D, 1000, 343.0 TET, 1, 2, 4, 6, 3 ... TET, 100, 42, 43, 41, 45 PYR, 101, 47, 48, 41, 40, 44 ... PRISM, 201, 66, 67, 65, 72, 74, 73 ... HEX, 301, 81, 82, 83, 84, 91, 92, 93, 94 ...

Let’s take a look at what these various lines mean. All lines begin with a text string denoting what kind of information is on that line and the information is delimited by commas into various *fields*. On the first line, we have vertex (nodal) location information:

N, 1, 0.0, 0.0, 0.0

The first field after the `N`

character is the node number, which is arbitrary, and the second, third, and fourth fields are the *x*-, *y*-, and *z*-locations of that node, so our first node is at the global origin. In the above sample, there are one thousand nodes in all.

Next, the computed temperature data at each node location is written on a separate line:

D, 1, 332.0

where the first field after the `D`

character is the node number and the second field is the temperature at that node location.

The remaining lines give information about the elements and how they are defined by the nodes. Let’s start by looking at the first element definition:

TET, 1, 2, 4, 6, 3

This line defines a tetrahedral (`TET`

) element. The first field is the element number and the next four fields tell us which nodes define the tetrahedra. Here, nodes 2, 4, 6, and 3 are nodes 1 through 4 of the element. Such information is also known as the *element connectivity* and to understand this, let’s look at an illustration of our element.

*A tetrahedral element is defined by four nodes.*

For our tetrahedral element example, nodes 2, 4, and 6 are the first three nodes. If we use the right-hand rule and follow these three nodes around in order, we get a vector that points in the direction of the fourth node, node number 3. The element ordering for all of the three-dimensional element types is shown below.

*Element number conventions for the four different types of 3D elements.*

Now that we understand the data format that we need to write out to our text file, let’s look at how this can be done with the Application Builder.

We begin our app development with an existing 3D model that already has a steady-state temperature solution computed, as shown earlier. To develop the app, switch to the Application Builder, where we will define the graphical user interface and write the data processing code behind our app. Our interface will be very simple, with just a *button* that calls a *method* and a *message log* that will display some information. The app will do only one thing: When the user clicks on the button, the data format described above is written to a text file and a summary of what was written will be shown in the message log.

*Our app has a button (1) that calls a method (2), which writes the mesh and solution data to a file and writes some statistics to the message log (3).*

The method contains all of the data processing code and is shown below with line numbers added and text strings in red.

1 StringBuffer FileB = new StringBuffer(); 2 double[][] d_Vtx = model.mesh("mesh1").getVertex(); 3 String[][] s_Vtx = toString(d_Vtx); 4 for (int m = 0; m < s_Vtx[0].length; m++) { 5 FileB.append("N, "+(m+1)+", "+s_Vtx[0][m]+", "+s_Vtx[1][m]+", "+s_Vtx[2][m]+"\n"); 6 } 7 model.result().numerical().create("interp", "Interp").setInterpolationCoordinates(d_Vtx); 8 model.result().numerical("interp").set("expr", "T"); 9 double[][][] AllData = model.result().numerical("interp").getData(); 10 model.result().numerical().remove("interp"); 11 for (int m = 0; m < AllData[0][0].length; m++) { 12 FileB.append("D, "+(m+1)+", "+AllData[0][0][m]+"\n"); 13 } 14 int[][] Ei; 15 int numTets = model.mesh("mesh1").getNumElem("tet"); 16 if (numTets > 0) { 17 Ei = model.mesh("mesh1").getElem("tet"); 18 for (int m = 0; m < numTets; m++) { 19 FileB.append("TET, "+(m+1)+", "+(Ei[0][m]+1)+", "+(Ei[1][m]+1)+", "+(Ei[2][m]+1)+", "+(Ei[3][m]+1)+"\n"); 20 } 21 } 22 int numPyrs = model.mesh("mesh1").getNumElem("pyr"); 23 if (numPyrs > 0) { 24 Ei = model.mesh("mesh1").getElem("pyr"); 25 for (int m = 0; m < numPyrs; m++) { 26 FileB.append("PYR, "+(m+1+numTets)+", "+(Ei[0][m]+1)+", "+(Ei[1][m]+1)+", "+(Ei[2][m]+1)+", "+(Ei[3][m]+1)+", "+(Ei[4][m]+1)+"\n"); 27 } 28 } 29 int numPrisms = model.mesh("mesh1").getNumElem("prism"); 30 if (numPrisms > 0) { 31 Ei = model.mesh("mesh1").getElem("prism"); 32 for (int m = 0; m < numPrisms; m++) { 32 FileB.append("PRISM, "+(m+1+numTets+numPyrs)+", "+(Ei[0][m]+1)+", "+(Ei[1][m]+1)+", "+(Ei[2][m]+1)+", "+(Ei[3][m]+1)+", "+(Ei[4][m]+1)+", "+(Ei[5][m]+1)+"\n"); 34 } 35 } 36 int numHexes = model.mesh("mesh1").getNumElem("hex"); 37 if (numHexes > 0) { 38 Ei = model.mesh("mesh1").getElem("hex"); 39 for (int m = 0; m < numHexes; m++) { 40 FileB.append("HEX, "+(m+1+numTets+numPyrs+numPrisms)+", "+(Ei[0][m]+1)+", "+(Ei[1][m]+1)+", "+(Ei[2][m]+1)+", "+(Ei[3][m]+1)+", "+(Ei[4][m]+1)+", "+(Ei[5][m]+1)+", "+(Ei[6][m]+1)+", "+(Ei[7][m]+1)+"\n"); 41 } 42 } 43 writeFile("user:///output.txt", FileB.toString()); 44 message("Data written to file output.txt in the user directory."); 45 message(s_Vtx[0].length+" Nodes\n"+numTets+" Tetrahedral Elements\n"+numPyrs+" Pyramid Elements\n"+numPrisms+" Prismatic Elements\n"+numHexes+" Hexahedral Elements\n");

Let’s go through this method line-by-line.

- Creates a string buffer into which we will store the data that will get written to the file.
- Extracts all of the mesh vertex locations from the model and puts the data into a 2D array of doubles.
- Converts the mesh location numerical data into string data, since it will be written out to a text file.
- Starts a for-loop that will iterate over all node locations.
- Appends a line for each node to the string buffer, with the node index and
*xyz*-locations. - Closes the for-loop over nodes.
- Sets up an interpolation feature to extract the data at the previously extracted node point locations.
- Sets the expression to evaluate at these node points. In this case, the variable “T” means that we are extracting temperature.
- Using the interpolation feature, extracts all of the temperature data. This gets stored in a 3D array of doubles.
- Removes the interpolation feature, since it is no longer needed.
- Sets up a for-loop over all of the extracted data. Since we are only extracting one field (temperature) and are assuming only one solution set exists in our model, we only need to index over the last dimension of our array.
- Appends a data line to the string buffer, with the node number and the value of temperature at that node.
- Closes the for-loop over all of the output data.
- Initializes an empty 2D array that stores the element index data.
- Extracts the number of tetrahedral elements from the model.
- Checks if there are any tetrahedral elements to write out.
- Extracts the tetrahedral element connectivity data from the model.
- Sets up a for-loop over all of the tetrahedral elements.
- Appends a line for each tetrahedral element to the string buffer, with the element number and the node numbers.
- Closes the loop over all tetrahedral elements.
- Closes the if-statement that checks if there are any tetrahedral elements.

Lines 22 through 42 simply repeat the functionality of lines 15 through 21 for the other element types. Note that the element numbers are incremented based upon all previous element numbers. Also, throughout this method, the indices of all nodes are incremented by one. This is because COMSOL Multiphysics internally starts all indices at zero, but in our desired output format, we want to start all node and element indices at one. The entire string buffer is converted to a string and written to the file on line 43. On lines 44 and 45, some information is printed to the message log.

The file that is written out is called `output.txt`

and is found in the user directory. The location of the directory on the disk is specified in the software preferences when you go to *File Menu > Preferences > Files > Application files*, as shown in the screenshot below. You can change the directory as desired.

*The location of the output files is specified in the software preferences.*

And with that, our method is complete. In the screenshot below, we can see our application in action.

*The application reports what has been written to the file.*

We have demonstrated how to create a very simple app that writes out the mesh and results from a COMSOL Multiphysics steady-state thermal simulation. You can simply copy the data from the app and paste it into a text file or spreadsheet. There is, of course, a lot more sophistication that we could build into this app, including:

- Writing out multiple data sets that might represent different load cases or different times from a transient simulation.
- Formatting the data into a fixed-format file type.
- Writing out higher-order element types and interpolation schemes.
- Writing out vector data, or data that is discontinuous between elements.

Of course, we won’t address all of these cases right now, but if you’re interested in adding such modifications into your own customized app, here are some resources to get you started:

- Download the
*Introduction to Application Builder*manual - Watch videos designed to help you learn the basics of using the Application Builder and COMSOL Server™
- Browse our blog posts to see how simulation apps are used in a range of applications

Seeking more information on how to build a specific type of app or have other modeling inquiries? Contact us.

]]>

As a solid material is heated, its temperature will rise and it will eventually undergo a phase transition. This transition can involve either going to the liquid phase and then to the gas phase or going directly to the gas phase. For our purposes, we will consider only those materials that go directly to the gas phase.

Let’s further assume in this case that the material is being heated in such a way that the maximum temperature develops on the surface and that there is no internal heating that might lead to an internal gas-filled void within the solid. Thus, we limit ourselves to situations where sublimation occurs at the surface. We can also assume that once the material transitions to the gas phase, it is no longer thermally significant. This is a reasonable assumption whenever there is some kind of additional surrounding gas flow that carries the vaporized material away. The process of heating the surface of a material to the gaseous state and quickly removing the gas from the vicinity of the solid is often called ablation.

Ablation requires a large heat flux to be delivered to the surface of the material. One of the most practical examples of such a heat source is a laser. This approach is applied to a range of processes, including laser machining, surgical procedures, and laser engraving, among others. The heat source, of course, does not necessarily need to be a laser. In fact, ablative heat shields have been used to help spacecraft survive the high heat loads experienced during atmospheric reentry.

*An artist’s rendition of a heat shield on a reentry vehicle.*

Modeling ablation requires setting up and solving a model that computes the temperature variation in a solid material over time, while also including the heat of sublimation and the resultant material removal. First, we must develop a thermal boundary condition that enforces the condition that the solid material cannot exceed the sublimation temperature. Second, we need to develop a method for modeling the mass removal from the domain of interest. Let’s see how we can accomplish these tasks in COMSOL Multiphysics.

To begin, we’ll consider a highly simplified model of the heat shield on the spacecraft shown above. We will assume that the heat flux across the heat shield is uniform in time and space. Another assumption we make is that the material properties of the heat shield are constant and that there are negligible temperature gradients in the plane of the shield as compared to through the thickness. Under these assumptions, we can reduce our model to a one-dimensional domain, as illustrated below.

*A heat shield (as pictured earlier) with a uniform heat flux can be reduced to a 1D model.*

Our thermal boundary conditions for the 1D domain begin with the thermal insulation condition at one side, meaning that there is no removal of heat through the spacecraft body. At the other side, there is a uniform constant heat flux that approximates the effect of atmospheric heating during reentry.

Lastly, we need to include a set of boundary conditions that model the heat loss due to material ablation. As the material reaches its ablation temperature, it changes its state to a gas and is removed from our modeling domain. Therefore, the solid material cannot become hotter than the ablation temperature, and when the material is at its ablation temperature, there is a loss of mass from the surface that is governed by the material density and the heat of sublimation. To model this element, we will need both a thermal boundary condition and a way to model the material removal.

The thermal boundary condition that we will introduce to model ablation is an ablative heat flux condition of the form:

(1)

q_a = h_a(T_{a}-T)

where q_a is the heat flux due to material ablation, T_a is the ablation temperature, and h_a=h_a(T) is a temperature-dependent heat transfer coefficient that is zero for T < T_a and increases linearly as T > T_a.

The slope of this curve is very steep, enforcing that the temperature of the solid cannot markedly exceed the ablation temperature. In addition to the thermal boundary condition, we must also include the material removal. The rate at which the solid boundary is eroded is:

(2)

v_a = q_a/ \rho H_s

where v_a is the material ablation velocity, \rho is the material density, and H_s is the heat of sublimation.

Let’s now look at how these equations are implemented in COMSOL Multiphysics, starting with the material properties and heat load, as defined via the *Global Parameters* shown below.

*The Global Parameters applied to our 1D model.*

Next, the *Ramp* function is used to define the temperature-dependent heat transfer coefficient needed in Equation (1), as illustrated in the following screenshot. The slope itself is arbitrary, but too small of a value will cause the ablation temperature to be exceeded and too large of a value will cause slow numerical convergence.

*The Ramp function has a very steep slope.*

Our model consists of a 1D domain that is 1 cm long. The *Heat Transfer in Solids* interface is used to model the temperature evolution over time. The incident heat flux is applied at one side and the thermal insulation condition is applied at the other side. The ablative heat flux of Equation (1) is implemented as shown in the screenshot below. Since heat flux conditions contribute, it is the sum of the incident heat flux and the ablative heat flux that is applied to the boundary.

*The implementation of the ablative heat flux condition from Equation (1).*

To model the material removal, the *Deformed Geometry* interface is used. The *Free Deformation* feature allows the domain to change in size, as prescribed by the boundary conditions. On one side (the insulated side), a prescribed deformation enforces no displacement of the boundary. On the other end of the domain, the *Prescribed Normal Mesh Velocity* condition enforces Equation (2), the material removal rate, as depicted below.

*The implementation of the material removal in Equation (2), using the* Deformed Geometry *interface.*

The mesh velocity is given by the expression `ht.hf2.q0/(rho*H_s)`

, where ` ht.hf2.q0`

is the heat flux computed via the Ablative Heat Flux boundary condition that was earlier defined. You can always find the definitions of all such internally defined COMSOL variables by going to *Results* > *Reports* > *Complete Report*.

With those features, we have included the effect of ablation and can solve our model for the temperature evolution over time, as plotted below. We can observe that the temperature at the right side of the solid rises up to the ablation temperature and the material starts to become removed from the domain. As the material is ablated, the temperature at the boundary is maintained. Additionally, note that the derivative of the temperature, with respect to position, changes once the material starts to ablate, indicating that the total heat flux has changed.

*The temperature evolution over time in the 1D domain.*

Let’s finish up our discussion by showing the results from a somewhat more complicated problem. The problem involves an axisymmetric geometry with a heat load that has a Gaussian intensity profile. Our focus is simulating laser heating and ablating the material to machine a hole. We can use the exact same model setup as described above, but on a 2D domain.

The simulation results, highlighted in the following animation, show the hole forming over time. The domain change is significant so, in this example, the *Deformed Geometry* interface uses a *Hyperelastic* smoothing type to deform the mesh. Note that the *Deformed Geometry* interface does not admit any topological changes to the domain. Therefore, we cannot model the formation of a through-hole, only the material removal from one side of the modeling domain.

*An animation showing laser ablation in a 2D axisymmetric model.*

In today’s blog post, we have demonstrated how to use a Heat Flux boundary condition and the *Deformed Geometry* interface with the *Prescribed Mesh Velocity* feature to model ablation of a material. The example presented has been kept as simple as possible to focus only on the modeling of ablation. A more realistic model would also include radiative heat transfer from the surface and temperature-dependent material properties.

Further, it is possible to consider a pulsed heat load, a common element in laser machining. To learn more about modeling such cases, please have a look at this earlier blog entry. When heating with a laser, it is also possible for the light to be penetrated some finite distance into the material. In such a case, you may be able to use the Beer-Lambert law to model the energy deposition, among other methods for modeling the laser heating of materials.

If the material itself first undergoes some chemical changes during the heating, we encourage you to read through our previous blog post on the modeling of thermal curing. You can also consider ablation of a thin thermally insignificant layer by following a different approach of introducing an additional equation to track the material damage.

If you’re interested in modeling thermal ablation with COMSOL Multiphysics or have any other questions regarding these topics, please don’t hesitate to contact us.

]]>

A material with thermal hysteresis will exhibit a solidification temperature that is different from the melting temperature. Such materials have applications in heat sinks and thermal storage systems and are even used by living organisms, such as fish and insects living in cold climates. We won’t concern ourselves here with the exact physical mechanisms by which thermal hysteresis happens, but rather focus on how to model it.

We will begin by considering a representative material with hysteresis that is incompressible and plot out the enthalpy of the material as a function of temperature, as shown below. When the material is in the solid state and is being heated, the enthalpy is given by the bottom curve or path. As the material passes the melting temperature, it becomes completely liquid. When this material is subsequently cooled in the liquid state, it will follow the upper path, thus the material remains liquid at temperatures below the melting temperature. Once the freezing temperature is reached, the material becomes completely solid. If the material is then heated back up, it will follow the bottom path, and so on. In the completely molten or completely solid state, the two enthalpy curves overlap. The latent heat of melting and solidification is the jump in these curves.

*Enthalpy versus temperature for an idealized incompressible material.*

Now, the above curve represents a bit of an idealized case that would only occur in the real world if we had a perfectly pure material. It is also a bit impractical for computational modeling purposes since this immediate transition between states represents a discontinuity that is quite difficult to solve numerically.

However, if we introduce a small transition zone over which the enthalpy varies smoothly, then we have a model that is much more amenable to numerical analysis. The physical interpretation of this is that the material changes phase over some finite temperature and in the intermediate range, the material is a mixture of both solid and liquid. Only once the material is fully outside of the transition zone will it switch over to following the other curve.

Note that we have centered the smoothing around the nominal melting and freezing temperatures, so the fully molten state is at a temperature slightly higher than the nominal melting temperature and the fully solid state is slightly below the freezing temperature. The plot below shows a gradual smoothing, but this transitional zone can be made very narrow to better approximate the behavior if we really did have a perfectly pure material.

*A smoothed enthalpy curve is more amenable to numerical analysis.*

Since the material is assumed to be incompressible, the enthalpy depends only on the temperature. The above plot will also give us the specific heat, which is the derivative of enthalpy with respect to temperature. The specific heat is constant except for a small region around the melting and freezing temperatures.

*The specific heat is the derivative of the enthalpy with respect to temperature and is different if the material is heated or cooled.*

This temperature-dependent specific heat data can be put directly into the governing equation for heat transfer and, along with an appropriate set of boundary conditions, can be solved in COMSOL Multiphysics. In fact, the existing Application Gallery example, Cooling and Solidification of Metal, makes use of such a temperature-dependent specific heat, albeit without hysteresis. The only additional requirement for modeling thermal hysteresis is to introduce a switch to determine which path to follow. Let’s now look at how to implement this in COMSOL Multiphysics.

Here, we will look at a simple example model of a phase-change material within a thin-walled container. One side wall is perfectly insulated and the wall on the other side is held at a known temperature that varies periodically over time. A schematic of this is shown below. We are interested in computing the temperature as a function of time and position through the thickness and can reduce this to a one-dimensional model to get started.

*Schematic of the thermal model. A time-varying temperature is applied at one side.*

Our modeling begins by setting up some physical constants via the *Global Parameters* that define the melting and freezing temperatures and the smoothing to apply to the enthalpy functions. The two smoothed enthalpy functions plotted earlier are implemented as shown in the screenshot below. We can here take advantage of the built-in *Step* function, which additionally features the option to apply a user-defined smoothing.

*Implementation of the enthalpy functions shown above, using the smoothed step function. Note that the units have been defined.*

The geometry of our model is simply a 1D interval representing the phase-change material region. The *Heat Transfer in Solids* interface is used, since we are assuming that there is no fluid flow. The material properties are as shown below.

*Screenshot showing the material properties definitions in the phase-change material.*

The thermal conductivity and the density are constants. The specific heat (the heat capacity at constant pressure) is defined as:

SorL*d(H_StoL(T),T)+(1-SorL)*d(H_LtoS(T),T)

where the differentiation operator takes the derivatives of the two different enthalpy functions with respect to temperature and the `SorL`

variable defines the local material behavior as either *Solid* or *Liquid*. The ` SorL`

variable can be either zero or one and can be different in each element.

A *Domain ODEs and DAEs* interface is used to define this variable, with interface settings as illustrated below. Note that the dependent variable and the source term are both dimensionless and the shape function is of the type *Discontinuous Lagrange — Constant*, meaning that the `SorL`

variable will take on a different constant value within each element.

*Settings for the *Domain ODEs and DAEs* interface that tracks the material state.*

*The Source Term settings.*

The above screenshot depicts the equation that is being solved for in the *Domain ODEs and DAEs* interface. Let’s examine in detail the *Source Term* equation used:

SorL-nojac(if(T> T_top,0,if(T< T_bot,1,SorL)))

This equation is evaluated at the centroid of each element and implements in a single line the following:

If the current temperature is greater than the temperature of complete melting (the nominal melting temperature plus half the smoothing temperature), then the material has passed its solid-to-liquid phase-change temperature, so set `SorL = 0`

. This means that the liquid-to-solid enthalpy curve is followed. If the current temperature is less than the temperature of complete solidification (the nominal freezing temperature minus half the smoothing temperature), then the material has passed its liquid-to-solid phase-change temperature, so set `SorL = 1`

. This means that the solid-to-liquid enthalpy curve is followed. Otherwise, when neither of the previous two conditions are satisfied, leave the ` SorL`

variable at its previous value, meaning that there is no change of path while in the intermediate zone.

The `nojac()`

operator tells the software to exclude the enclosed expression from the Jacobian computation, thus it does not try to differentiate the enclosed expression but merely evaluates the expression itself at each time step.

The `SorL`

variable is used in one place in the model: in the definition of the specific heat in the phase-change material domain, as shown earlier. It is also important to set the initial value of the variable appropriately. If the initial temperature of the phase-change material is above or below the temperature of complete melting or solidification, then this choice is unambiguous; otherwise, you must choose the initial state of the material. In the example here, we will consider the initial temperature of the system to be below the freezing temperature, so the material will initially follow the solid-to-liquid path. Therefore, the initial value of the ` SorL`

variable is set to one.

*The solver settings showing the usage of the *Previous Solution *operator.*

In terms of solving the model, we only need to keep in mind that the `SorL`

variable needs to be evaluated at the previous time step using the *Previous Solution* operator in the solver sequence, as shown in the screenshot above. We can also use a segregated solver and, of course, we should investigate tightening the time-dependent solver tolerances, the scaling of the dependent variables, and study the convergence of the solution with mesh refinement.

Let’s now look at some results. In the plots below, we see the temperature through the thickness of our modeling domain for the heating and cooling of the phase-change material. Observe that the slope of the temperature as a function of position changes as the material passes through the melting and freezing points. This is due to extra heat that must be added or removed as the material changes phase.

*Temperature over time in the phase-change material during heating. The blue line is the melting temperature.*

*Temperature over time in the material during cooling. The red line is the freezing temperature.*

*An animation showing the combined temperature profile over time during heating and cooling. The blue and red lines are the melting and freezing temperatures.*

Today, we have introduced an approach appropriate for modeling materials exhibiting thermal hysteresis under the assumption of constant density and that the material must go completely above and below the melting and freezing temperatures to change phase. This modeling approach makes use of the *Previous Solution* operator and equation-based modeling. For more details on the usage of the *Previous Solution* operator and further examples, please see:

- Using the Previous Solution Operator in Transient Modeling
- Tracking Material Damage with the Previous Solution Operator

The approach shown here is a bit simplified for the sake of explanation. If you are interested in the modeling of heat transfer with phase change, either with or without hysteresis, we recommend that you look to the Heat Transfer Module, which has a built-in interface for modeling heat transfer with phase change, as introduced here.

If you are instead interested in the modeling of irreversible changes in phase, then you may also want to take a look at our previous blog post on thermal curing as well as tracking material damage with the *Previous Solution* operator.

Looking to model thermal hysteresis in COMSOL Multiphysics or have other questions about this process? Please contact us.

]]>

As we introduced in our previous blog post on the basics of coil modeling, whenever you are modeling an electromagnetic coil, you need to think in terms of a closed current loop. The current loop can be entirely within the modeling domain or closed via a boundary condition, as illustrated in the figure below.

*A coil connected to a voltage source (left) and two different approaches to closing the current loop (right).*

As we learned earlier, if the coil extends to the boundaries of the modeling domain, then the current flowing through the coil will return along the modeling domain boundaries. Otherwise, to close the current loop, the coil must loop within the modeling domain. Here, we will concern ourselves with two questions. First, what boundary conditions should we use? And second, how far away from the coil should these boundaries be?

We will start by thinking of our coil as sitting in a space that extends to infinity and does not contain anything else. Obviously, we cannot model an infinitely large domain. We must truncate our modeling domain to some finite size that will give reasonably accurate results but will not require too much computational effort to solve. First, let us consider the case of an axisymmetric coil that is closed within the modeling domain. This case can be analyzed via a 2D axisymmetric model, as shown below.

*A circular coil in a spherical modeling domain can be modeled via a 2D axisymmetric model. The domain radius is normalized with respect to the coil radius.*

We will consider two different boundary conditions along the outside radius of the modeling domain shown above: the Magnetic Insulation (MI) boundary condition and the Perfect Magnetic Conductor (PMC) boundary condition. The Magnetic Insulation condition can be physically interpreted as a boundary to a domain that has infinite electrical conductivity. That is, the Magnetic Insulation condition implies that our coil is enclosed within a sphere of very high conductivity. Currents can flow and be induced on a magnetic insulation boundary. Mathematically speaking, the magnetic insulation fixes the field variable that is being solved for to be zero at the boundary; it is a homogeneous Dirichlet boundary condition.

On the other hand, the Perfect Magnetic Conductor boundary condition can be thought of as the opposite boundary condition. Mathematically, it enforces the homogeneous Neumann condition, meaning the derivative of the solution field in the direction normal to the boundary is zero. No current can flow, nor be induced on, a perfect magnetic conductor boundary.

Since these two boundary conditions can be thought of as opposites, let’s take a look at what happens to the solution as we solve the above problem with an increasing radius of the surrounding air sphere and monitor the computed coil inductance. We can perform a parametric sweep over the domain radius and then take the average of the solutions for the two different boundary conditions by joining solutions. These results are shown in the plot below, and we can observe that the solution for the inductance converges with increasing domain radius. We can also observe that the average of the two solutions converges even faster.

*Normalized inductance of a coil with an increasing radius for different boundary conditions.*

From the above plot, we can conclude that it doesn’t matter which boundary condition we use for this axisymmetric problem, as long as we study the solution with an increasing domain radius. We can also conclude that we can run the model with a relatively smaller domain radius and with both Magnetic Insulation and Perfect Magnetic Conductor boundary conditions to take the average of the two cases. This average, even for a small radius, will give a good prediction of the solution at larger domain radii.

We can, in fact, avoid the question of boundary conditions entirely by truncating our modeling domain with a domain condition known as an *infinite element* domain. The infinite element domain requires that you add an additional domain as a layer around the exterior of the modeling domain. The software then internally performs a coordinate stretching within this domain such that the domain is infinitely large, for all practical purposes. Thus, the solution from a model with infinite element domains will be the same as when the domain radius is increased.

The advantage of the infinite element domain is that it obviates the question of choosing between boundary conditions as well as the question of the domain size. The infinite element domain can be placed in very close proximity to the coil — it could even be touching. The only additional work that the infinite element introduces is in the model and the meshing setup. Also, the solution time and memory requirements for larger 3D models can be greater. These are, however, only very small prices to pay for the added convenience.

*The meshes for typical 2D axisymmetric and 3D infinite element domains.*

We have looked at three different approaches for truncating a domain when modeling an electromagnetic coil in free space: the Magnetic Insulation boundary condition, the Perfect Magnetic Conductor boundary condition, and the infinite element domain. When using the Magnetic Insulation and Perfect Magnetic Conductor boundary conditions, you must study model convergence with an increasing domain radius, and as the domain radius increases, the solutions will all converge toward the same value. Taking the average of the two cases can predict what will happen at larger domain radii. You can also put in a little bit more effort and use the infinite element domains to get to the same answer.

Also keep in mind that, if your coil extends to the boundaries of the modeling domain, you need to provide a current return path via the Magnetic Insulation boundary condition. If there are domain boundaries that represent a metallic enclosure and if you are modeling in the frequency domain, then also look toward the Impedance boundary condition, which is useful for modeling lossy materials such as metals.

If you have a model with symmetry, you can also use the Magnetic Insulation and Perfect Magnetic Conductor boundary conditions to enforce different kinds of symmetry, as explained in our earlier blog post on exploiting symmetry to simplify magnetic field modeling.

If you are just getting started with coil modeling in the AC/DC Module in COMSOL Multiphysics, you should also take a look at the following example models:

- Modeling of a 3D Inductor
- Inductance of a Power Inductor
- Magnetic Field of a Helmholtz Coil
- Multi-Turn Coil Above an Asymmetric Conductor Plate
- Multi-Turn Coil Winding around a Ferromagnet
- Mutual Inductance and Induced Currents Between Single-Turn Coils
- Mutual Inductance and Induced Currents in a Coil Group
- Mutual Inductance and Induced Currents in a Multi-Turn Coil
- Modeling a Spiral Inductor Coil
- Integrated Square-Shaped Spiral Inductor

What kind of coil modeling would you like to do with COMSOL Multiphysics and the AC/DC Module? Contact us and let us know.

]]>

Thermosets are a class of polymer materials that undergo an irreversible chemical reaction, causing the polymer chains to cross-link and form a rigid material. This chemical reaction can be due to heat, light, or the addition of a chemical catalyst. Bakelite, one of the first thermosets, is often credited as kicking off the polymer industry. Bakelite is a very hard material that is resistant to many chemicals, is a good electrical insulator, and has an attractive surface finish. The material was used in a variety of early consumer products, such as telephones and radio cabinets.

*A Bakelite radio cabinet. Image by Joe Haupt — Own work. Licensed under CC BY-SA 2.0, via Wikimedia Commons.*

Bakelite and other thermosets come in various precursor forms, such as powders and thick viscous liquids. These precursors are put into a mold and heated under high pressure. Additional filler materials are often added to improve the properties of the final product. Carbon fiber and fiberglass composites, for example, bond relatively strong but flexible fibers together using a relatively rigid thermoset matrix.

Now, depending upon the exact manufacturing process, the precursor material might not move around or flow significantly during the curing step. If this is so, then you can develop a very simple model to predict the curing based upon the temperature. Let’s now look at how to implement such a model in COMSOL Multiphysics.

We will look at simulating curing during a transfer molding process, wherein the material is loaded into a mold and then heated, as shown in the schematic below. During heating and curing, the material does not move around inside the mold, and for simplicity, we won’t consider any filler materials. A thin-walled part, such as the radio cabinet shown earlier, can be reasonably modeled with a one-dimensional model through the thickness. Since the material is heated uniformly and at a known rate on both sides, we can exploit symmetry to only model one half of the material.

*Schematic of a mold with a thermoset curing inside and the equivalent model for temperature and degree of cure.*

Our model will compute the variation in time of the temperature, T, and the degree of cure, \alpha, of the thermoset from the centerline to the mold wall. Assuming no flow, the equation governing heat transfer in the thermoset precursor is:

(1)

\rho C_p \frac{\partial T}{\partial t} + \nabla \cdot (-k \nabla T) = -\rho H_r \frac{\partial \alpha}{\partial t}

where \rho, C_p, and k are the density, specific heat, and thermal conductivity of the material.

The degree of cure is \alpha and as the material cures, it absorbs heat, thus there is a negative volumetric heat source that is a function of H_r, the heat of the reaction. The rate of change of the degree of cure is often described by:

(2)

\frac{\partial \alpha}{\partial t} = A e^{-E_a/RT}(1-\alpha)^n

where the Arrhenius equation defines the temperature-dependent reaction rate, with A being the frequency factor, E_a being the activation energy, R as the universal gas constant, and n as the order of the reaction.

Let’s now look at how to set up this model in COMSOL Multiphysics, starting with the definitions of a few *Global Parameters* defining the properties of our representative thermoset material.

*The Global Parameters define a set of representative material properties of a thermoset.*

Our modeling domain is simply a 5-mm-long 1D interval, with the material properties as shown above. The *Heat Transfer in Solids* interface solves for the temperature distribution over time, starting with the specified initial temperature along with a Thermal Insulation boundary condition on one end. A Heat Flux boundary condition at the other end of the domain applies 10 kW/m^{2} due to the heating of the mold.

*The absorption of heat due to the material curing is modeled via the *Heat Source* feature.*

The endothermic effect of the curing is accounted for via a volumetric heat source, `-rho0*H_r*d(alpha,t)`

, as shown above. This feature implements the right-hand term from Equation 1 based upon the time derivative of the degree of cure.

We now need to add one more interface to solve for the degree of cure, and this is done via the *Domain ODEs and DAEs* interface, as shown below. Note that the field name is `alpha`

. Pay special attention to how the units are set up.

*Settings for the *Domain ODEs and DAEs* interface, which solves for the degree of cure.*

Lastly, looking at the settings for the *Distributed ODE* feature, we see that the *Source Term* is `A*exp(-E_a/R_const/T)*(1-alpha)^n`

and the *Damping* term is unity, while the *Mass Coefficient* is zero, thus giving us Equation 2. An initial condition of zero means that the material is modeled starting from the uncured state.

*Settings for the Distributed ODE feature that solves for the degree of cure.*

And that’s all there is to it: We can solve our model for a ten-minute curing time and plot the temperature and degree of cure through the thickness and at the inside and midpoint of the material, as shown below. Here, we apply a constant heat load at one side, so we will want to check the maximum temperature and the degree of cure through the thickness.

*The temperature increases through the thickness of the material over time. Darker lines indicate increasing time. *

*The degree of cure through the material over time. Darker lines indicate increasing time.*

*The degree of cure at the center (blue) and side (green) of the thermoset material.*

We have shown how to quickly set up a thermal curing model entirely within the core capabilities of COMSOL Multiphysics. Of course, you can use a similar approach if you want to model the curing of other materials, such as concrete. If the material curing is due to light, such as in a photopolymerization process, you may also want to look over the various ways of modeling the interaction of light with materials, and in particular the modeling of light being absorbed within the volume of a solid as governed by the Beer-Lambert law.

The model presented here can be easily extended in many ways, including adding temperature nonlinearities to all of the materials properties, incorporating the effect of a filler material, and solving these equations in a 3D model. If you would like to see work that includes these examples, please read:

- T. Behzad and M. Sain, “Finite element modeling of polymer curing in natural fiber reinforced composites“,
*Composite Science and Technology*, vol. 67, pp. 1666-1673, 2007.

If you have other questions or are interested in using COMSOL Multiphysics for your thermal curing modeling needs, please contact us.

]]>

A single *Radial Basis Function* (RBF) is any function defined in terms of distance (radius) from a point:

(1)

z(x,y)=w \phi \left(\sqrt{(x-x_c)^2+(y-y_c)^2} \right) = w \phi ( || \mathbf {x- c}||) = w \phi(r)

where w is the *weight* of this RBF; \mathbf{c}=(x_c,y_c) are the coordinates of the point, or *center*; and r is the distance from any other point in the xy-plane to this center.

The RBF itself can be one of many different types of functions. The family of polyharmonic splines is often used for interpolation, particularly the thin-plate spline function. The thin-plate spline basis function is:

(2)

\phi(r)=r^2 \log (r)

Now, just a single one of these RBFs is not all that interesting, but we can take a sum over a finite number of different centers with different weights and optionally add a linear polynomial term with weights a_0, a_1, a_2, giving us the function:

(3)

z(x,y)= \sum_{i=1}^N w_i \phi(r_i) + a_0 + a_1x + a_2y

If there are enough centers, then this sum of a set of RBFs can be used to represent very complicated single-valued functions. When using the thin-plate spline basis, there is the added advantage that this function is also smooth everywhere and infinitely differentiable.

Let’s now take a look at how to interpolate a smooth surface with these RBFs. If we are given a finite set of center point locations, \mathbf{c}_1, \mathbf{c}_2, … \mathbf{c}_N, and their corresponding known heights, z_1, z_2, … z_N, then we can write a system of linear equations:

(4)

\left[\begin{array}{cccccc}\phi_{1,1} & \dots & \phi_{1,N} & 1 & x_{c,1} & y_{c,1}\\\vdots & \ddots & \vdots & & \vdots & \\\phi_{N,1} & \dots & \phi_{N,N} & 1 & x_{c,N} & y_{c,N}\\1 & & 1 & 0 & 0 & 0 \\x_{c,1} & \dots & x_{c,N} & 0 & 0 & 0 \\y_{c,1} & & y_{c,N} & 0 & 0 & 0\end{array}\right]\left\{\begin{array}{c}w_1\\\vdots\\w_N\\a_0\\a_1\\a_2\end{array}\right\}= \left\{\begin{array}{c}z_1\\\vdots\\z_N\\0\\0\\0\end{array}\right\}

where the terms of the system matrix, \phi_{i,j} = \phi ( || \mathbf {c}_i- \mathbf{c}_j||) , are the Radial Basis Functions evaluated between the centers.

Almost all of the off-diagonal terms will be nonzero when using the thin-plate spline basis, hence this system matrix is quite dense. The linear system can be solved for all of the weights and we can then evaluate the sum of our weighted RBFs at any other point in the xy-plane, giving us a smooth interpolation function. Let’s now look at how to compute these weights and visualize the interpolation function using the core capabilities of COMSOL Multiphysics.

We start with a model containing a 3D component with a dimensionless units system. The units system is selected in the settings for *Component 1*. A dimensionless units system is simpler to use if our data represents material properties rather than a geometry.

The geometry in the model consists of two features. First, a *Point* feature is used to define the set of points. (The list of coordinates can be copied from a text file.) The *Cumulative Selection* is used to define a named selection of all of these points, as shown in the screenshot below. There is additionally a *Block* feature, which has dimensions that are slightly larger than the range of data points and is positioned to enclose all data points.

*A screenshot showing the definition of the data points to interpolate and the cumulative selection definition.*

*The data points and the bounding block.*

Once the geometry is defined, we define an *Integration Component Coupling* operator over the points that we just created. Since the integration is done over a set of points, this operator is equivalent to taking a sum of an expression evaluated over the set of points. Next, we define three variables, as shown in the screenshot below.

First, the variable `r = eps+sqrt((dest(x)-x)^2+(dest(y)-y)^2)`

will be used to compute the distances between all of the centers. Note the usage of the `dest()`

operator, which forces the expression within the operator to be evaluated on the destination points instead of the source points. A very small nonzero term (` eps`

is machine epsilon) is added so that this expression is never precisely zero.

Next, the variable `phi = r^2*log(r)`

is Equation (2), the thin-plate spline basis function. Note that this function converges to zero for a radius of zero, but we did need to make the radius very slightly nonzero because of the log function so that the basis function can be evaluated at zero. It is also worth remarking that this function could be changed to any other desired basis function.

Lastly, the definition `RBF = intop1(w*phi)+a0+a1*x+a2*y`

is Equation (3), the interpolated surface itself, with weights that are not yet computed. Keep in mind that the integration component coupling operator takes a sum of the expression within the operator over those points.

*A screenshot showing the definitions of the variables.*

Now that the geometry is set up and all variables are defined, we are ready to solve for the weights for the RBF and the polynomial terms. This is done with a *Point ODEs and DAEs* interface, defined over the points that we want to interpolate, as shown in the screenshot below. We can set all of the units to dimensionless, since the point locations are also dimensionless. These settings define a set of unknowns, `w`

, which will have a different value for each point.

*Settings for the *Point ODEs and DAEs* interface.*

Within this physics interface, only two features need to be modified. Firstly, the settings for the *Distributed ODE* need to be adjusted as shown below. The *Source Term* is defined as `z-RBF`

. Since all other terms in the equation are zero when a Stationary study is solved, this term means that ` RBF=z`

at all of the selected points. With this one feature, we define rows 1 through N of Equation (4).

*The settings for the Source Term at each point.*

Secondly, we need to define the last three rows of Equation (4). This is done with a *Global Equations* feature, as shown in the next screenshot. These three equations solve for the weights `a0`

, `a1`

, and ` a2`

. Again, the integration coupling operator takes a sum of the expression over all selected points. With these two features, the problem is completely defined and almost ready to solve.

*A screenshot showing the Global Equations for the polynomial weights.*

Solving this model requires that we have a mesh on all points, so we apply a free tetrahedral mesh to the bounding box and then solve with a Stationary solver. Once the problem is solved, we can plot our interpolation function, the variable `RBF`

, as shown below.

*The smooth and differentiable interpolation surface passes through all of the data points. *

If you would like to use this functionality without setting up all of these features in your own models, you are also welcome to download our demonstration app from our Application Gallery, which takes in the *xyz* data points from a comma-delimited file and computes the interpolation surface. Up to 5000 data points can be interpolated with this demo app.

In addition to computing this surface, the app can write out the complete analytic function describing the surface, and also write out a COMSOL-format CAD file of the surface itself, all within the core capabilities of COMSOL Multiphysics. The CAD data is a NURBS surface and thus only approximately represents the function, but to a very high accuracy for reasonably smooth surfaces. A screenshot of the app’s user interface is shown below.

*Screenshot of an app that computes an interpolation function and writes out the function and CAD surface.*

If you’re interested in finding out more about the Application Builder and COMSOL Server™, which can be used to build and run this app, check out the resources below.

- Read a complete rundown of instructions in the
*Introduction to Application Builder*manual - Watch these videos to learn about how to use the Application Builder and COMSOL Server™
- Read these blog posts to see how simulation apps are used in a variety of applications

What would you like to do with COMSOL Multiphysics? Do you have further questions about the capabilities of Radial Basis Functions? Contact us for help.

]]>

Let’s start with a simple example of a conductive wire that is bent into a loop and connected to a constant voltage source, a battery (shown below). Due to the voltage difference, a current will flow through the wire. The magnitude and direction of this current throughout the conductor can be computed from Ohm’s law and the Charge conservation equation, along with a set of boundary conditions.

*A very simple electromagnetic coil connected to a DC voltage source.*

For this single wire, we can consider a grounded boundary condition at one end, meaning an electric potential of zero, and a higher electric potential on the other end. Current cannot flow in or out of the wire anywhere else, so the electric insulation condition is applicable on the remaining boundaries. This problem can be solved using the finite element method as implemented in the AC/DC Module in COMSOL Multiphysics.

As a consequence of the computed current flow, a magnetic field arises and surrounds the wire. This is a vector field, having both a magnitude and direction, and can be computed from Ampère’s law. We are interested in learning how to model this magnetic field and how it interacts with other objects.

For the purpose of learning coil modeling, we won’t concern ourselves with exactly what is happening within the source itself. Instead, we will just assume that a device exists that provides a constant voltage, or a constant current. We also won’t concern ourselves with the wires between the coil and the source, but assume that they are electrically insignificant. Based upon these two assumptions, we will say that a reasonable computational model of a coil might look like the image below, which shows a single wire with a single turn as well as the surrounding magnetic field due to the current flow.

*A computational model of a coil with one turn. The current flow (black arrows) in the wire results in a magnetic field (colored arrows) in the surrounding air region.*

There are actually a couple of other assumptions that have gone into solving the above model. First, we can see that there is a cylinder around the coil representing the air domain. This is the computational domain within which we are solving for the magnetic field. This is a finite-sized domain, yet the magnetic field will actually extend infinitely far away from the coil. The field intensity will drop off with the inverse of distance to a straight wire, so the field magnitude will be quite small far away from the coil. Although it will never be precisely zero, we can reasonably truncate our modeling domain to a finite-sized space.

By choosing a finite modeling region around the coil, we are assuming that we are only interested in the fields in this region. This choice of finite-sized region introduces another assumption at the boundaries. We need to consider some boundary conditions along the boundaries of the cylinder or whatever surrounding domain shape we choose. We will discuss the various possible boundary conditions, their physical interpretations, and why to use each one at length in a later blog post, but for this particular case, we will consider a boundary condition that represents a perfect electrical conductor.

For the physical interpretation of this, we assume that our coil sits inside of a cylindrical metal container. As a consequence of the boundary condition, the current, which is flowing along the wire from one end to the other, will flow back along the surface of the modeling domain as shown in the image below.

*The arrows show the current flowing through the wire and back along the surfaces truncating the modeling domain.*

This brings us to one of the most basic points in coil modeling: the concept of a closed current path.

Whenever you are modeling a coil, or any magnetic field excited by a current flow, you must have a closed path (loop) of current. Your models must satisfy this condition to be valid. If you would try to impose a current flowing through an open circuit coil, that would be equivalent to implying that the current (electrons) instantaneously moves from one end of the open coil to the other, and this would violate Maxwell’s equations. The image below illustrates one such invalid coil model. Since the coil wire does not extend to the boundary, there is no continuous path along which the current can flow.

*An invalid coil model. The current-carrying wires do not reach the boundary, so there is no way for the current to loop back and no current can flow.*

We can take an alternative approach to our coil model by revisiting some of our assumptions. One of the assumptions that we made in the above example is that the source is outside of our modeling domain. We can, however, alter our model in a way that the source is within our modeling space.

In the image below, one such representative model is illustrated. A closed coil is shown with a small region representing the source that feeds the coil. This source (shown in green in the image below) is entirely within the modeling domain and closes the current path. It is also assumed that the wires feeding the coil are unimportant for our modeling needs and it is assumed that a closed torus is a reasonable approximation of the coil.

*A coil model with the source inside of the modeling domain. The source is the small green section. The coil has a current return path entirely within the modeling domain. The current flow (black arrows) in the wire results in a magnetic field (colored arrows) in the surrounding air region.*

An interesting consequence of this approach is that the boundaries of the modeling domain no longer need to provide a current return path. This opens up the possibility for alternative boundary conditions on the exterior of the modeling domain, which can be used to model an insulative surrounding or to approximate an infinite space rather than an enclosing conductive container. We will address the various appropriate ways to truncate a modeling domain in depth at a later point.

For 2D and axisymmetric models, we also need to concern ourselves with the current return path, so let’s take a quick look at the valid configurations for these cases. An axisymmetric model is appropriate to use when the situation that you want to address is invariant, or nearly so, around an axis of rotation. The image below shows one such 3D geometry, and the associated axisymmetric 2D model. All fields are assumed to be invariant around the axis of symmetry, so the formulation itself takes care of closing the current path, thus we only need to model a 2D domain in the positive *rz*-plane.

*A 3D rotationally invariant coil can be modeled in the axisymmetric 2D plane.*

If the coil is very elongated, with negligible end effects such as those seen in motors, then it is also possible to reduce the model down to a simplified 2D model with two different choices for closing the current path. It is possible to model either a cross section of the entire coil, the wires carrying current in opposite directions, or only one half of the coil with a symmetry condition at the centerline.

*An elongated 3D coil model. If the end effects are neglected, this can be modeled in a 2D plane.*

When both turns of the coil are modeled, one turn carries current perpendicularly into the 2D modeling plane, and the other turn carries the current perpendicularly out of the 2D modeling plane. When only one turn is modeled, a symmetry condition must be used at the centerline that permits current to flow back in the opposite direction. The boundary of the 2D modeling plane closes the current path. These two cases are illustrated below.

*Two different approaches to modeling an elongated coil in the 2D plane. The current flowing in the positive and negative out-of-plane directions (gray arrows) flows along either the coil or the symmetry boundary condition.*

We have started to look at coil modeling here by introducing the concept of the current loop. If you are modeling a coil, or indeed doing almost any modeling work with currents and the resultant magnetic fields, you will always need to keep this concept in mind. The next topic that we will look at is the question of the appropriate boundary conditions for our computational model, so stay tuned. In the meantime, have a look at these resources:

- Read more about how you can use the AC/DC Module on the COMSOL Blog
- Learn about modeling computational electromagnetics with the AC/DC Module in under three minutes. Watch the video
- If you want to use COMSOL Multiphysics and the AC/DC Module for your coil modeling, please contact us

Suppose that you have been tasked with performing thermal analyses on many different circuit boards, such as the one pictured below. Notice that there are a lot of different chips, resistors, capacitors, and other components on the board. The data that you have been given includes the amount of heat dissipated within each of these components in addition to their locations on the board and their overall dimensions.

*A typical circuit board can have hundreds of components mounted on it. Image by Chris Whytehead — Chris’s Acorns. Licensed under CC BY-SA 3.0, via Wikimedia Commons.*

The actual thermal analysis of the circuit board is quite straightforward from the point of view of the analysis itself. Setting up the model in the graphical user interface for COMSOL Multiphysics, however, requires adding many different *Block* and *Cylinder* primitives and defining their sizes and locations. You also need to define a different dissipation within each device. This can quickly become tedious if you have to do everything by hand.

Now suppose that you’ve been given all of the component types, heat dissipation, locations, and sizes in a spreadsheet.

*A spreadsheet containing component layout information.*

Each row of the spreadsheet represents a different component. This format is very compact and a bit cryptic, so let’s go through what the data means, column-by-column.

The first column can contain a letter, either ** B** or

` C`

For the example shown above, the first row of the spreadsheet represents the circuit board itself, which is 1.57 mm thick and 350 mm x 200 mm. It is offset from the origin by -1.57 mm in the *z*-direction and does not dissipate any heat.

We can write the data in the spreadsheet out to a comma-delimited text file. Let’s now look at how we can read this text file into COMSOL Multiphysics using a simplified app.

The development of our app begins with a blank model file where we define a *3D Component* with a *Geometry* that is tagged as *geom1*. These are all default settings. Additionally, we change the unit system in our geometry branch to millimeters, as illustrated in the following screenshot.

*The blank model file within which we build our app. The unit for geometry length is millimeters.*

To develop the app itself, we switch over to the Application Builder, which contains the graphical user interface layout and the logic behind our app. The app that will process our text file features a very simple user interface with just four elements:

*File Import*feature*Graphics*window*File*menu*Save*feature

The Save feature, found within the File menu, enables us to save our imported data back to a COMSOL Multiphysics file.

*Our app includes a File Import feature, a Graphics window, and a File menu with a Save feature.*

In the above screenshot, note that there are two other nongraphic elements included in our app. The first of these elements is a *Declaration*, a data structure that is used to store the file name that we are importing. The second element is a method called ** populateBoard**, which processes the text file.

*The Declaration settings define how to access the text file.*

The one graphical element that the user can interact with here is the File Import feature. The screenshot below highlights the settings for the feature, three of which are important. First, the *File types* have been set to *CSV File*, meaning that we can only import comma-delimited files into our app. Second, the *File Destination* is set to the *inputFile* declaration, thus passing the name of the file into this data structure. Finally, when there is a data change (when a different file is selected), the ** populateBoard** method is called upon.

*The settings for the File Import feature specify the file type and the method to call upon after a file is imported.*

The last part of our app that we need to look at is the method that converts the text file into a COMSOL Multiphysics model. This method is illustrated below, with line numbers added on the left and text strings highlighted in red:

1 String[][] D = readCSVFile("upload:///inputFile"); 2 model.geom("geom1").feature().clear(); 3 for (int k = 0; k < D.length; k++) { 4 if (D[k][0].equals("B")) { 5 model.geom("geom1").create("P"+k, "Block").set("pos", new String[]{D[k][2], D[k][3], D[k][4]}); 6 model.geom("geom1").feature("P"+k).set("size", new String[]{D[k][5], D[k][6], D[k][7]}); 7 } 8 if (D[k][0].equals("C")) { 9 model.geom("geom1").create("P"+k, "Cylinder").set("pos", new String[]{D[k][2], D[k][3], D[k][4]}); 10 model.geom("geom1").feature("P"+k).set("r", D[k][5]); 11 model.geom("geom1").feature("P"+k).set("h", D[k][6]); 12 } 13 model.geom("geom1").feature("P"+k).set("selresult", "on"); 14 model.variable().remove("var"+k); 15 model.variable().create("var"+k).model("comp1"); 16 model.variable("var"+k).selection().named("geom1_P"+k+"_dom"); 17 model.variable("var"+k).set("Q", D[k][1]); 18 } 19 model.geom("geom1").run();

Now we’ll go through the method line-by-line:

- Read the data from the CSV file, accessing the filename as defined by the declaration.
- Clear out the existing geometry sequence in the file (necessary if we want to read in a different CSV file).
- Set up a for loop over all of the lines (rows) in our CSV file.
- If the first entry on the line is the text string “B”, then we are defining a block.
- Create a new block primitive, located at the
*xyz*-position and specified by columns 3-5 of the CSV file. - Set the size of this block primitive to the dimensions specified by columns 6-8 of the CSV file.
- Close the “if” statement for the block creation.
- If the first entry on the line is the text string “C”, then we are defining a cylinder.
- Create a new cylinder primitive, located at the
*xyz*-position and specified by columns 3-5 of the CSV file. - Set the radius of the cylinder.
- Set the cylinder height.
- Close the “if” statement for cylinder creation.
- Create a selection out of the feature that was just created. Regardless of the type, it will have a tag identifier of “Pk”, where k is the integer index.
- Remove any defined variables that exist with conflicting names.
- Create a new variable with an “s” name based upon the integer index.
- Apply the newly created variable to the selection corresponding to the new part.
- Define a variable “Q” that is the dissipation in this part, specified by column 2 of the CSV file.
- Close the for loop over the input file.
- Finalize the geometry.

So, in just under twenty lines of code, we have converted a text file into a COMSOL Multiphysics model! And that’s all there is to our app. Of course, this code assumes that our input file is error free and doesn’t contain any invalid data or unrecognized characters. We could extend this code to be fault tolerant and to do some sanity checking, such as making sure there are no overlapping parts, if desired.

Let’s now take a look at the results we would obtain with some sample input…

*The graphical user interface of our app after reading in a sample CSV file.*

We can also write out a full COMSOL Multiphysics file from this app. The file will contain all of the geometry as well as all of the heat loads in each part, defined as variables. You could then perform the thermal analysis in COMSOL Multiphysics, or you could extend the current app to perform a thermal analysis of the entire board within the app itself. You will, of course, still need some boundary conditions and you will need to define material properties in all of the components. Hopefully, however, it is clear by now that you have the ability to extend the app to read such information in from the same CSV file.

*Once all of the part geometries and different heat loads are defined within a COMSOL Multiphysics model, you can compute the temperature distribution on the circuit board.*

- Want to build this app yourself but haven’t used the Application Builder yet? Here are some resources to get you started:
- Download the
*Introduction to Application Builder*manual - Watch videos designed to help you learn about and use the Application Builder and COMSOL Server™
- Browse our blog posts to see how simulation apps are applied to a range of applications

- Download the
- Interested in learning more about the thermal analysis of circuit boards? Try out these tutorials from our Application Gallery:
- Seeking more information on how to build a specific type of app or have other modeling inquiries? Contact us

When using either the AC/DC Module, the MEMS Module, or the Plasma Module, the Terminal condition can be applied to the boundaries of any domains through which conduction or displacement currents can flow. With this boundary condition, it is possible to apply a *Current*, *Voltage*, or *Power* excitation as well as a connection to an externally defined *Circuit* or a *Terminated* connection with known impedance.

Regardless of the type of excitation or the physics interface being used, the Terminal condition always specifies the voltage, but optionally adds more equations to the model. For example, when using a Terminal condition with a specified current, the software automatically adds an *Integration Component Coupling* feature to integrate the total current through the specified boundary. The software also adds a *Global Equation* that introduces one additional degree of freedom to the model for the terminal voltage, such that the current through the terminal equals the user-specified current.

This combination of Global Equations with an Integration Component Coupling is quite flexible and you may already be familiar with its usage for structural mechanics and heat transfer modeling. Let’s now see how we can easily switch between different terminal types.

*A schematic of a block of material with a ground and a Terminal condition on opposite sides. The Terminal boundary condition will be switched between a voltage or a current source.*

We will look at a very simple electric current model involving just a block of material with a grounded boundary on one side and a current-type Terminal boundary condition on the other. We will start by considering the steady-state case and address how to apply a current or voltage excitation by adding a Global Equation. The Global Equation itself is added to the *Electric Currents* interface (To add Global Equations to a physics interface, make sure to toggle on *Advanced Physics Options* underneath the *Show* menu in the Model Builder.)

First, we take a look at the Terminal settings. As we can see from the screenshot below, the Terminal type is Current, and the applied current is the variable `Current`

, which will be solved for via the Global Equation.

*The current-type Terminal condition with an applied current, which will be controlled by the Global Equation.*

*The Global Equations settings control the applied current for the Terminal condition.*

The settings for the Global Equation are shown in the screenshot above. There is a single equation for the variable `Current`

, and the equation that must be satisfied is

(Current-1[A])/1[A]

Since this equation, by definition, must equal zero, the applied current equals 1 Amp. This is a straightforward equation; it does not include any feedback from the model, but rather sets the value of `Current`

. The Global Equation itself is nondimensionalized, since we will also want to satisfy an equation for voltage. Switching to a voltage excitation can be done by simply changing this equation to

(ec.V0_1-3[V])/3[V]

where the variable `ec.V0_1`

is automatically defined by the Terminal boundary condition.

We are thus applying a current such that the terminal voltage is equal to 3 Volts. This equation does introduce a feedback from the model, but the model is still linear. It will still solve in a single iteration, but it does require using a direct solver. If you try this out yourself, you can see that you can now switch between a voltage and a current excitation simply by changing the Global Equation for a stationary problem. Next, we will look at how you can dynamically switch between these excitations during a transient simulation.

Let’s suppose that we have a power source driving a system that exhibits variable resistance. For example, resistance changes with temperature due to Joule heating and induction heating. Let’s also suppose that, as the resistance changes, our power source can supply a constant current up to some peak voltage, or a constant voltage up to some peak current.

To model this type of switch, we will use the *Events* interface. We have previously written about the *Events* interface for implementing a thermostat for a thermal problem and we recommend reviewing that blog post for technical details and relevant solver settings.

The *Events* interface contains four features: a *Discrete States* feature, an *Indicator States* feature, and two *Implicit Events* features. First, the Discrete States feature defines a single-state variable, `CC`

, which acts as a flag indicating if the power supply is in constant-current mode, `CC=1`

, or constant-voltage mode, `CC=0`

. Initially, our power supply will be in constant-current mode. Next, there is an Indicator States feature defining two indicator-state variables, `PeakV`

and `PeakI`

, which should vary smoothly over time. Lastly, there are two Implicit Events features, which will track these two indicator-state variables and change the discrete-state variable, ` CC`

, to zero or one if the logical conditions are met. These settings are all shown in the screenshots below.

*The Discrete States feature defines a flag that signals the Terminal state.*

*The Indicator States feature defines two different possible events indicators.*

*The Implicit Events toggle the Discrete States variable.*

There is only one task left to do: modify the global equation for the variable `Current`

to be

CC*((Current-1[A])/1[A])+(1-CC)*(ec.V0_1-3[V])/3[V]

You can see that this is a sum of the two expressions developed earlier for either current control or voltage control using the `CC`

flag to switch between them. Once this is done, it is only a matter of solving in the time domain with the study settings described in our earlier blog post and using a direct solver for the *Electric Currents* voltage field, the Terminal voltage, and the Global Equation for the current, as shown in the screenshot below. The *Events* variables can be solved in a separate segregated step.

*Solver settings showing how the variables are segregated and that a direct solver is being used.*

With these features, we have now implemented the following power supply behavior:

- Initially, apply a constant current of 1 Amp and adjust the applied voltage to maintain this current.
- If the voltage exceeds 3 Volts, switch over to constant-voltage mode.
- If the current exceeds 1 Amp, switch back over to constant-current mode.

To generate some representative results, we will explicitly make the total resistance of our domain vary over time, as shown in the plot below. We can see from the subsequent plots of current and voltage that the supplied current is initially constant but the voltage rises due to increased resistance. The power supply then switches over to constant-voltage mode and the current varies. As the resistance goes back down, the current rises to its peak and then the power supply switches back to fixed-current mode.

*As the device resistance varies over time, the source switches between constant current and constant voltage to ensure that the maximum current and voltage are never exceeded.*

We have demonstrated a control scheme that enforces both a current and voltage maximum, implemented with Global Equations and the Terminal boundary condition. The functionality of the Terminal boundary condition used here is not limited to the *Electric Currents* interfaces. The Terminal condition is also available within the *Magnetic and Electric Fields* interface as well as the *Magnetic Fields* interface, where it is called the Boundary Feed or Gap Feed condition. The *Magnetic Fields* interface also includes a *Multi-Turn Coil* domain feature that can be used equivalently.

It is also possible to use this type of control scheme during a *Frequency-Transient* study, which often occurs in Joule or induction heating, wherein the electromagnetic problem is solved in the frequency domain and the thermal problem, which solves for the temperature variations that lead to impedance changes, is solved in the time domain. This can be particularly useful in the modeling of, for example, RF heating and ablation.

The Batteries & Fuel Cells Module, Corrosion Module, Electrochemistry Module, and Electrodeposition Module all contain the Electrode Current and Electrolyte Current boundary conditions that can be used equivalently to the Terminal condition demonstrated here. In particular, the Capacity Fade of a Lithium-Ion Battery tutorial model shows how to model the charging and discharging of a battery.

We hope you can see that with a little bit of imagination, it is possible to implement some quite complex control schemes with the Terminal boundary condition and the *Events* interface.

If you have a particular application that you’d like to model with COMSOL Multiphysics, please don’t hesitate to contact us.

]]>