## Modeling a Periodic Heat Load

##### Walter Frei February 16, 2015

One of the more common questions we are asked is about the modeling of periodic, or pulsed, heat loads. That is, a heat load that turns on and off repeatedly at known times. Modeling such a situation accurately and efficiently in COMSOL Multiphysics is quite easy to do with the *Events* interface. The techniques we will introduce are applicable to many classes of time-dependent simulations in which you have changes in loads that occur at known times.

### A Brief Introduction to Time-Dependent Simulations

First, let’s take a (very) brief conceptual look at the implicit time-stepping algorithms used when you are solving a time-dependent problem in COMSOL Multiphysics. These algorithms choose a time step based upon a user-specified tolerance. While this allows the software to take very large time steps when there are gradual variations in the solution, the drawback is that using too loose of a tolerance can skip over certain transient events.

To understand this, consider the ordinary differential equation:

where the forcing function f(t) is a square unit pulse starting at t_s and ending at t_e. Given an initial condition, u_0, we can solve this problem for any length of time, either analytically or numerically. Here is the analytic solution for u_0=1:

In the above plot, we can observe the exponential decay and rise as the forcing function is zero or one. Let’s now look at the numerical solution to this problem for two different user-specified tolerances:

*The numeric solution (red dots) is shown for a relative tolerance of 0.2 and 0.01 and is compared to the analytical result (grey line).*

We can see from the plot above that a very loose relative tolerance of 0.2 does not accurately capture the switching of the load. At a tighter relative tolerance of 0.01 (the solver default), the solution is reasonably well resolved. We can also observe that the spacing of the points shows the varying time steps used by the solver. It is apparent that the solver takes larger time steps where the solution changes slowly and finer time steps when the heat load switches on and off.

However, if the tolerance is set too loosely, the solver may skip over the heat load change entirely when the width of the heat load gets very small. That is, if t_s and t_e move very close to each other, the magnitude of the total heat load is too small for the specified tolerance. We can of course mitigate this by using tighter tolerances, but a better option exists.

We can avoid having to tighten the tolerances by using *Explicit Events*, which are a way of letting the solver know that it should evaluate the solution at a specified point in time. From that point in time forward, the solver will continue as before until the next event is reached. Let’s look at the numeric solution to the above problem, with *Explicit Events* at t_s and t_e and solved with a relative tolerance of 0.2 (a very loose tolerance):

*When using* Explicit Events*, the numerical solution — even with a very loose relative tolerance of 0.2 — compares quite well with the analytical result. Away from the events, large time steps are taken.*

The above plot illustrates that the *Explicit Events* force a solution evaluation when the load switches on or off. The loose relative tolerance allows the solver to take large time steps when the solution varies gradually. Small time steps are taken immediately after the events to give good resolution of the variation in the solution. Thus, we have both good resolution of the heat load switching on or off and we take large time steps to minimize the overall computational cost.

Now that we’ve introduced the concepts, we will take a look at implementing these *Explicit Events*.

### An Example from Heat Transfer

We will begin with an existing example from the COMSOL Multiphysics Model Library and modify it slightly to include a periodic heat load and the *Events* interface. We will look at an example of the Laser Heating of a Silicon Wafer, where a laser is modeled as a distributed heat source moving back and forth across the surface of a spinning silicon wafer.

The laser heat source itself traverses back and forth over the wafer with a period of 10 seconds along the centerline. To minimize the temperature variation over the wafer during the heating process, we want to turn the laser off periodically, while the heat source is in the center of the wafer. To model this, we will introduce an *Analytic* function, pulse (x), that uses the Boolean expression:

`(x<2)||(x > 3)`

to evaluate pulse (t) to zero between t=2-3 seconds, and one otherwise. The *Periodic Extension* option is used to repeat this pattern every five seconds, as shown in the screenshot below.

*The settings used to define a periodic function, as plotted.*

We can use this function to modify the applied heat flux representing the laser heat source, as illustrated below:

*The settings for the applied heat flux boundary condition.*

The last thing that we need to do is to add the *Events* interface. This physics interface is found within *Mathematics > ODE and DAE interfaces* when using the *Add Physics* browser. Within the *Events* interface, add two *Explicit Events* with the settings shown below to define a periodic event starting at two and three seconds and repeating every five seconds.

*The* Explicit Events* settings. The second of these events starts at 3 s.*

No other changes are needed, but we can take a quick look at the solver settings:

*The settings for the time-dependent solver.*

Note that the entries in the *Times* field are the output times. These settings do not directly control the actual time steps taken by the solver. The *Relative Tolerance* field (default value of 0.01) along with the *Events* — if they are in the model — control these time steps.

*A comparison of unpulsed (left) and pulsed (right) heat loads.*

You can compare the results of this simulation to the original model to see the differences in temperature across the wafer. With a periodic heat load, the temperature rise is more gradual and the temperature variations at any point in time are smaller.

### Closing Remarks

We have looked at using the *Events* interface for modeling a periodic heat load over time and introduced why it provides a good combination of accuracy and low computational requirements. There is a great deal more that you can do with the *Events* interface — if you would like to learn more, we encourage you to consult the documentation. An extended demonstration of the usage of the *Events* interface is featured in the Capacity Fade of a Li-ion Battery example from the Model Library.

On the other hand, when dealing with problems that are either convection dominated or wave-type problems (e.g., fluid flow models or transient structural response, respectively), then we would not want to introduce instantaneous changes in the loads. The reasons behind that — and alternative modeling techniques for such situations — will be the topic of an upcoming blog. Stay tuned!

## Comments

Ivar KjelbergFebruary 16, 2015 10:35 amHi Walter

Thanks for an interesting BLOG again

One thing though: I do not read anything hereabove about the the relation between mesh density, that links to the material heat diffusivity “alpha” equal to k/rho/Cp and the time steps used.

If one does not also carefully consider these variables, there is a good chance that the errors you describe in the beginning are driven mostly by a poor mesh density.

I have noticed that you now propose the heat diffusivity “alpha” as a COMSOL internal variable, but I have not read anything that the mesher analyses this to adapt the mesh accordingly yet (automatically). Or have I missed a new feature ?

Sincerely

Ivar

Walter FreiFebruary 17, 2015 9:22 amHello Ivar,

Yes, you are correct, one should always perform a mesh refinement study, as well as a study of the refinement of the time-dependent solver tolerance.

Do keep in mind that the advantage of the Events interface is that it will ensure proper temporal resolution of the periodic heat load, *regardless* of the mesh size or the time-dependent solver tolerance. Also, the first example presented here is a single degree of freedom problem, so there is no mesh dependency.

With respect to “alpha”: It appears that there are some misunderstanding here, and it is not particularly germane to this discussion about the usage of Events.

With respect to how you do the mesh refinement: You can perform either manual refinement or automatic adaptive mesh refinement. Adaptive mesh refinement in time-domain simulations has been available since several versions ago.

Best Regards,

Walter

Kiran KabothuJuly 20, 2015 7:07 amDear Walter,

Thanks for your support.

I am working on ultra-short pulse laser matter interaction model in COMSOL (pulse duration <1ps).

In order to run simulation in time of 100fs, do i need the work station.

How i can chose the system configuration (processor, ram).

please suggest system requirement to solve my problem.

thanks

kiran

Walter FreiJuly 20, 2015 8:32 amHello Kiran,

Such questions should be directed to your COMSOL Support Team.

Best,

Sergey FedotovOctober 19, 2016 6:01 amHello Walter,

Many thanks for your blog, it’s very usefull for me. I have a question related to using explicit events. I made a model which simulated material heating by one laser pulse and I did it by defining a initial temperature in focal spot. I wanted to simulate pulse train and added analytic function, two explicit events and multiply initial temperature in focal spot on analytic fucntion. Was it enough? Cause I expected to see graph T = f(t) like yours, but I didn’t.

Thanks for your reply!

Caty FaircloughOctober 19, 2016 9:21 amHi Sergey,

Thank you for your interest in this blog post! For questions related to your simulations, please contact our support team.

Online support center: https://www.comsol.com/support

Email: support@comsol.com

Best,

Caty

Melvin LorenzoDecember 10, 2016 9:48 pmIf I need to make pulses that are 100E-6 seconds in length, and they repeat once every second. How would I do this? I tried using this method but it doesn’t work for very small pulses.

Walter FreiDecember 12, 2016 11:44 amHello Melvin,

You may want to double-check your implementation, as this method does work for any pulse duration. You can confirm this by looking over the solver log.