Example 1. Three heat sources; one not vented but mounted outside the enclosure. The system can be closed or vented. When vented, there is a link between the
internal air temperature node and the ambient, as the exiting mass flow carries heat. To solve this path, a mass flow rate is needed. This mass flow rate, if driven by a fan
(an option not allowed for this design), would be relatively straightforward to estimate. For natural convection, iteration on the flow rate is needed so that the internal air
is no hotter than a certain temperature. Which temperature? For this problem, source 3 was the highest dissipation, so a separate calculation revealed the temperature of source 3. That would be the highest
possible air temperature, and the lowest possible air flow. For sanity, you could also look at higher air flows, to see what that does to the other temperatures. Choose the
range of air flows to be less than what a fan would drive. And what if the enclosure is sealed? The air flow gets set to zero. From this comparison, it was quickly obvious that
the enclosure needed venting. A quick exit-speed calculation lets you determine how much venting is needed; just keep the velocity low (~0.2 m/s max or so).
of Example 1
Example 2. Two heat sources, both within a sealed enclosure. The one with
the critical temperature limit has a variable location within the unit. Source 2 is much higher heat dissipation, but doesn't directly have a maximum
temperature (I asked that question more than once!), so its dissipation goes directly to the internal air. Can you see from the network below that
the strength of source 2 drives the temperature of source 1? The only way to keep this interaction from happening is to somehow break that thermal
link. Physically, this meant a thought shift on the part of the client, to move source 2 so that a direct link to ambient air was possible. Seeing the
network enabled the discussion that led to the revised design.
larger view of Example 2
Example 3. Six heat sources, two of which are mounted on or at the surfaces of the sealed enclosure. Looking at the network below, a few things come to mind:
larger view of Example 3
- Sources 2 and 3 affect each other's temperatures
- The combined dissipation of sources 1 through 4 all heat the air inside the case, while this heat has to dissipate through the case surfaces, and through sources
5 and 6. Notice that we don't know the direction of heat flow between 5 and 6 sources and the internal air; the internal air may be heating them, or allowing some of their heat to dissipate to it.
- If the internal air temperature is above the temperature limit for sources, their allowable dissipation is zero! But this
clearly is impossible, so we have a few options; one is to link the source directly to ambient somehow, and a
few options center around lowering the internal air temperature. Most obvious is to reduce (or better
estimate!) the heat source magnitudes. Another is to facilitate heat transfer between the internal air and the
ambient (e.g. a heat exchanger in addition to the case, or a large fan to generate forced convection over the
entire case area). Can you come up with some others? Of course, the feasibility of these ideas needs to be
developed in close collaboration with the design engineering team. The network schematic helps the communication a lot.
If this network analysis process sounds more difficult than just throwing the problem into your fancy thermal
software you paid a lot of money for, you may be right -- until the software leaves you wondering why the system is
running so hot, and everything you try doesn't help! Let's look at some reasons to do the network analysis first:
- You can see the resistance values to compare, so that big fundamental problems are obvious. They're easy
to communicate, too – most engineer types are already familiar with resistance concepts. No need to impress them with heat transfer coefficient mumbo-jumbo.
- The direction of heat flow shows up easily with so few nodes involved.
- The accuracy of the inputs doesn't justify a lot of software time and expense: here I am thinking about power
dissipation values you're probably getting from the project electrical engineers. Most often they have run a
power budget to size the power supply so that they won't run out of power. But this is usually not the same as
the dissipation budget – what is really heating up the components (and thus the enclosure) in a realistic use scenario.
- Once you get used to doing this type of analysis, it is really fast. This is especially true where natural
convection is involved. For example, I modeled example 3 in Flotherm, software with which I'm very familiar
and productive. After about six hours, I finally had a solution with which I felt reasonably comfortable. But the
solution domain had to be large compared with the enclosure, and the radiation calculation option had to be
turned on and re-calculated for each scenario. Further, I had almost no information about heat distribution in
the "lumped" parts, but both the convection and the radiation calculations needed grid cells quite a bit
smaller than the part size for the solution to be more or less grid independent. Even with solution times of
only a few minutes each, conclusions were slow to come. By contrast, the thermal network and related
conclusions were pretty solid at the end of a couple of hours. I might recommend the Flotherm as a next step – but not before the client goes back and finds realistic heat dissipation values.
Ready to get started? go back to the first Newsletter page for Excel tricks to help you...