How to Simulate Battery Pack Cooling in COMSOL Without the Battery Design Module

Run a liquid-cooled battery pack thermal simulation in COMSOL using the analytical Bernardi heat equation, and see an AI agent set it up end to end.

TL;DR

A full electrochemical-thermal battery model in COMSOL needs the Battery Design Module. If your organization doesn't license it, the coupled model will open, but it won't recompute.

For most cooling-design questions, you don't need the electrochemistry. You need a credible heat source in the cells and a correct flow field in the coolant. The Bernardi equation gives you that heat source from a few cell parameters.

That turns the problem into a conjugate heat transfer study that runs on the Heat Transfer and CFD modules alone, which many simulation teams already have.

The work is in the setup: redefining the heat source, decoupling the studies so nothing calls the unlicensed interface, and making sure the thermal study actually uses the solved flow field.

In the video below, Argus does all of this inside COMSOL, including catching a coupling error that would have produced plausible-looking but wrong results.

The license wall in the middle of a design question

Here is a situation most simulation engineers will recognize. A colleague hands over a battery pack model: eighteen cylindrical cells, an aluminum cooling plate with internal channels, water as the coolant. The question is a thermal-management one: how hot do the cells get, and does more coolant flow help?

You open the file, and the model tree tells you it was built with a Lithium-Ion Battery interface coupled to Laminar Flow and Heat Transfer in Solids and Fluids. The physics is all there. The license for the battery interface is not. You can look at the stored results, but you cannot change a parameter and re-solve.

At that point the options are to wait for a license, borrow one, or rebuild the model around a different heat source. This guide covers the third option, because it is usually the fastest and, for a cooling study, it is often the more appropriate model anyway.

What a battery cooling simulation actually needs

There are two different jobs that both get called "battery simulation."

When you need a battery interface

Electrochemical-thermal modeling. You care about how the cell behaves: voltage response, state of charge, lithium concentration, degradation. Heat is an output of the electrochemistry. This genuinely needs a battery interface.

When an analytical heat source is enough

Thermal management modeling. You care about where the heat goes: cell temperatures, gradients across the pack, coolant temperature rise, pressure drop. Heat is an input. What matters is that the input is right in magnitude and roughly right in how it depends on current and temperature.

A cooling-plate design review is almost always the second job. And for the second job, an analytical heat source is a standard engineering choice, not a compromise.

The Bernardi heat-generation equation

The Bernardi equation estimates the heat a cell generates from its current, internal resistance and entropic coefficient:

```

Q = ( I² · R_int − I · T · dU/dT ) / V_cell

```

- I²·R_int is the irreversible Joule heating.

- I·T·dU/dT is the reversible (entropic) heat, which can add to or subtract from the total depending on the sign of the current and the cell chemistry.

- V_cell converts total heat into a volumetric source for the cell domains.

The inputs are values you can get from a datasheet or a quick cell characterization: applied current, internal resistance, and the entropic coefficient. In the video, the agent uses typical 18650-class values as adjustable global parameters, so you can swap in your own cells without touching the physics.

Method 1: Rebuild the setup by hand

If you are doing this yourself in COMSOL, the steps are:

Add global parameters for current, internal resistance and entropic coefficient, and compute the cell volume from the cell geometry.

Find the existing heat source. In a coupled model, the heat source on the cell domains usually references a variable from the battery interface. Locate where that variable is defined; it is often a component variable rather than a global parameter, which is easy to miss.

Redefine it with the Bernardi expression, using the local temperature from the heat transfer interface so the entropic term responds to the solution.

Decouple the studies. Make sure the flow study solves only Laminar Flow, and the temperature study solves only Heat Transfer with the battery interface disabled. Any study step that still activates the battery interface will fail without the license.

Check that the thermal study uses the solved flow field. This is the step that bites people. If the temperature study's "values of variables not solved for" setting doesn't point at the flow solution, the coolant velocity is effectively zero, convection disappears, and the results look reasonable while being wrong. A simple check is to change the flow rate: if the temperatures don't move, the coupling isn't working.

Sweep and post-process. Run a coolant flow-rate sweep, then plot cell temperature and the velocity field.

None of these steps is difficult. Together they are an afternoon of model-tree archaeology, especially in someone else's model.

Method 2: Let an AI agent do the setup inside COMSOL

The second approach is to hand the job to an agent that operates COMSOL directly. The distinction we keep coming back to is between a copilot that tells you which node to click and an agent that performs the operations in the tool and reports what it did. We have written about the difference between copilots and agents for engineers in more depth.

Here is what that looked like on this model:

1. Opened and inspected the model. Argus, our COMSOL AI agent, loaded the battery pack file, walked through the geometry (a pack of 18 cylindrical cells with a liquid cooling plate, about 31 × 113 × 100 mm), and identified the physics interfaces in use.

2. Hit the license wall and said so. It reported that the Battery Design Module wasn't available and laid out options: view the stored results, run thermal and flow only with a prescribed heat source, or get the license.

3. Wrote the physics. Asked to write the equations itself, it found the variable the heat source depended on, added the Bernardi parameters, and redefined the heat source analytically.

4. Decoupled the studies so the flow and temperature studies ran without touching the battery interface.

5. Caught its own coupling error. During the flow-rate sweep, the temperature results were identical across flow rates. Argus flagged this as a red flag rather than reporting success, traced it to the temperature study not using the flow solution, fixed the reference, and re-verified with two different flow rates.

6. Produced results. It created and exported a temperature plot of the cells and coolant and a velocity-field streamline plot of the cooling channels.

Why the flow-coupling check matters

Step 5 is the one worth dwelling on. A model where convection silently drops out still converges and still makes colorful plots. The value of an agent here is more than speed. It is that it ran the sanity check most of us skip at 6 p.m. and treated a suspicious result as a bug.

Watch it happen: COMSOL Battery Pack Cooling video (2 min)

Argus opens a liquid-cooled battery pack model in COMSOL, works around a missing Battery Design Module license by writing the Bernardi heat equation, and fixes a flow-coupling error before producing results.

Comparison

What a correct analytical battery cooling model has to get right

A heat source with the right magnitude. Sanity-check the volumetric heat rate against cell current and resistance before you trust any temperature.

A temperature-dependent entropic term. Using the local temperature from the solution, not a constant, keeps the reversible heat physically consistent.

Studies that don't call unlicensed physics. Every study step should list only the interfaces you intend to solve.

A thermal study that actually sees the flow. Change the flow rate and confirm the temperatures respond. If they don't, the coupling is broken.

Mesh resolution in the channels. Coolant boundary layers drive heat transfer; a coarse channel mesh will understate cooling.

How long does it take?

It depends on the model and who built it. Rebuilding the heat source by hand in a model you didn't write typically takes a few hours once you include finding the existing coupling, reconfiguring studies and validating the results. In the video, Argus went from opening the file to exported result plots in roughly 75 minutes of wall-clock time, most of it solver time.

The number that matters is the one you measure on your own models. A thermal question that used to wait on a license, or on the one person who understands the model, becomes something you can answer the same day.

Where this matters most

Cooling-plate and channel design. Iterating on channel layout or flow rate needs fast, repeatable thermal runs, not electrochemistry. For the wider picture, see how AI agents work in battery engineering from design through production.

Electronics and power cooling generally. The same pattern of an analytical heat source plus conjugate heat transfer applies to power electronics, GPUs and other dense heat loads. It is the same bottleneck we wrote about in how Frore Systems cools next-generation GPUs without waiting on its simulation queue.

Teams with uneven license coverage. When add-on modules are scarce, an analytical approach keeps thermal work moving while the specialists keep the full licenses.

If you are deciding which simulation tasks to hand to an agent first, our evaluation of AI agent use cases for mechanical engineers covers how teams have prioritized.

A note on your models

Simulation files encode design decisions you would not want leaving the building. Ask any AI tool where the model goes, who can see it, and whether it is retained or used for training. Cosmon is SOC 2 compliant, processes cloud data under a zero data retention contract with Anthropic, with on-premises deployment also available. More on that in adopting AI securely without risking engineering IP.

Final thoughts

A missing Battery Design Module is a real limitation if you need electrochemistry. For cooling design, it usually isn't. The Bernardi equation gives you a defensible heat source, and the Heat Transfer and CFD modules do the rest.

The hard part was never the equation. It is the setup in someone else's model, and verifying that the flow actually reaches the thermal solve. Whether you do that by hand or hand it to an agent, judge the result by whether the temperatures respond to the flow rate, not by how good the plot looks.

FAQs

Can you simulate battery thermal behavior in COMSOL without the Battery Design Module?

Yes, for thermal management questions. Replace the electrochemical heat source with an analytical one such as the Bernardi equation, and solve with the Heat Transfer Module (plus CFD for liquid cooling). You lose electrochemical outputs like voltage and state of charge, but you keep cell and coolant temperatures.

What is the Bernardi heat generation equation?

It estimates battery heat generation as irreversible Joule heating (I²·R) minus reversible entropic heat (I·T·dU/dT). Divided by cell volume, it becomes a volumetric heat source you can apply to the cell domains in a thermal model.

Which COMSOL modules do I need for a liquid-cooled battery pack simulation?

With an analytical heat source, the Heat Transfer Module and the CFD Module, or whichever module provides the Laminar Flow interface in your license. The Battery Design Module is only needed for full electrochemical-thermal coupling.

Why don't my COMSOL temperature results change when I change the coolant flow rate?

Most often the temperature study isn't using the solved flow field. Check the study's "values of variables not solved for" setting and point it at the flow solution, then re-run with two different flow rates to confirm the coupling works.

Can an AI agent run COMSOL simulations?

An agent like Argus can operate COMSOL directly: inspect models, edit physics and parameters, configure and run studies, and export results. Its output is native COMSOL changes you can review in the model tree, and not merely suggested steps.