# Solving Models with Pulsed Loads in Time

 Solution Number: 1245 Title: Solving Models with Pulsed Loads in Time Platform: Applies to: All Products Versions: All versions Categories: Solver Keywords:

## Problem Description

I am solving a transient model which has loads that change instantaneously in time, but the solver appears to be missing some of these changes in the loads. How to I get the solver to correctly recognize when the load changes?

## Solution

### Background

Many time-dependent problems are modeled by partial differential equations with only first derivatives with respect to time. Common examples of such equations include the heat transfer equation and the chemical species transport equations, but any parabolic partial differential equation will behave similarly: the transient behavior of the solution is characterized by an exponentially decaying response to a change in the load. The default behavior of the software is to assume that the solution is smoothly varying in time. However, if a pulsed load is applied to the model that is relatively short in duration the software may skip over it, unless a very tight solver tolerance is used.

If, on the other hand you model involves second time derivatives such as the transient electromagnetic wave and transient pressure acoustics formulations as well as transient structural problems, then the solution fields will be wave-like and such situations are addressed in Knowledge Base 1244: Solving Wave-Type Problems with Step Changes in the Loads

### Resolution

Rather than relying upon tightening the solver tolerance, the correct approach to modeling pulsed loads is to tell the solver when such a change in the load occurs. This is done via the Events interface.

This interface is found within the list of Physics at Mathematics > ODE and DAE Interfaces > Events. The Events interface includes four features: Discrete States, Indicator States, Explicit Events, and Implicit Events. When an event is triggered, by default it will consistently initialize all variables based upon the previous solution and new loads. You can, optionally, reinitialize some (or all) discrete states, global, or field variables to different values if you want them to change abruptly.

### Periodically Pulsed Heat Loads and Explicit Events

The discrete states interface defines a state variable that can be changed when an event is triggered.

The discrete state can be used to modify a heat load.

The explicit event reinitializes the discrete state, which turns on the load.

The explicit event reinitializes the discrete state to turn off the load.

### Periodically Pulsed Heat Loads without Events

If you have a load that is pulsing very rapidly relative to the simulation time-span, consider instead approximating this pulsed heat load as a cycle-averaged constant heat load. For example, if you are modeling the heating due to a 10W load that is on for 100 milliseconds and off for 400 milliseconds over a total simulation time many times longer than the pulse cycle time, then it is quite likely that you do not need to explicitly model the temperature rise and fall due to each pulse. Instead, take the total time the load is on per cycle (100 milliseconds) and divide by the total cycle time (in this case 500 milliseconds) to get a 2W cycle-averaged heat load. This approach will solve much more quickly, especially for fast pulses, and is especially appropriate if you do not need to capture exactly the temperature rises due to each pulse.

A constant, cycle-averaged, heat load (black line) over time can be a good approximation of the effect of a fast-pulsed load (red line.)

### Conditionally Pulsed Heat Loads and Implicit Events

The Implicit Event feature should be used when a change in load occurs implicitly due to a condition in the model that occurs at some unknown time, such as in the case of thermostatic control. It must be combined with an Indicator States feature, that defines an Indicator Variable. The indicator state variables are used to trigger implicit events when the indicator state variable changes sign and and when the implicit event condition changes from false to true.

For example, consider a model initially at 20°C and being heated until the average temperature is above 95°C. At that point in time, the heater should turn off. The heater should turn back on if the average temperature drops below 90°C. A discrete state is used to control the heat load, as in the above example, but in this case the Initial Value setting is important. In this case, it must be initially one, indicating that the heater is on, and will be modified by the implicit events being triggered.

The discrete state is initially set to one.

To monitor the average temperature of domain within a model, use an average component coupling operator, as described in Knowledge Base 913: Computing Time and Space Integrals along with a variable that stores the average temperature, as shown in the screenshot below.

Defining a component coupling operator and a variable.

The average temperature variable is used within the Indicator States features to define two indicator states that can cause an implicit event to trigger. The first indicator state defines `TooHot = AverageTemp-95[degC]` and the second defines `TooCold = AverageTemp-90[degC]`. Keep in mind that implicit events can only possibly be triggered when an indicator state changes sign.

Defining the two indicator states.

The two indicator states are used within two different implicit events features, the first of which triggers on the condition `TooHot>0` which goes from false to true when the average temperature goes above 95°C. When this event triggers, the `ONOFF` discrete state is set to zero, turning off the heat load. The second condition triggers on the condition `TooCold<0` which goes from false to true when the average temperature drops below 90°C, and sets `ONOFF` to one, turning the load back on.

Two implicit events are used to implement thermostatic control.

The accuracy with which the solver will trigger Implicit Events is controlled by the Event tolerance, as shown in the screenshot below. If you are observing over- and under-shoots of the events, make this value smaller, ` 0.001 ` for example. A sample file implementing these features is also available for download via the link below.

Where to change the event tolerance.

### Solver Options when using Events

By default the software will only save results at the times that you specify in the Time Dependent Study Step settings. You likely also want to store the solution immediately before, and after, any explicit or implicit events are triggered. This can be done by modifying the Time-Dependent Solver settings. Within the Output section, enable Store solution before and after events, as shown in the below screenshot.

The solver settings that enable the storing of solutions before and after events.

Knowledge Base 1255: Reducing the amount of data stored in a model

Knowledge Base 1254: Controlling the Time-Dependent Solver Timesteps

Knowledge Base 1240: Manually Setting the Scaling of Variables

Knowledge Base 1127: Improving convergence in nonlinear time dependent models