The thought of setting up and running a complex PCB and Enclosure thermal model was something that used to strike fear in the heart of engineers. That is no longer true. In this video, we step through the process of importing, setting up, and solving a PCB thermal simulation.
With Icepak now falling under the umbrella of Electronics products in the Ansys Pro Premium Enterprise licensing scheme, it is easier than ever to obtain conjugate heat transfer simulation results without a dedicated Fluids license. Because of this, we have received multiple requests regarding methods to transfer Icepak’s results to a workbench environment for more accurate thermal and Mechanical results. So, without further ado, I will outline the procedure for four different methods along with their general use-cases. Before that if you want to know about icepak then do visit sustainabilitystreet .
1: Temperature from Classic Icepak
The first, and most straightforward, method is simply transferring body temperature directly from the Icepak (Classic) workbench application. This may be the preferred method for the majority of use-cases where getting thermal CHT results into a mechanical project is the goal. The Icepak node needs to be solved as normal, and then the solution can simply be dragged over to the setup node of another project, such as steady state thermal or static structural. Once this has been linked and updated, the transferred body temperatures are accessed through an “Imported Load” folder where the temperatures for individual bodies can be mapped over. The benefits are that as long as the Icepak simulation is set up as needed, you won’t need to resolve anything on the thermal side, and there is no extra manipulation of data required on the user’s end.
2: Heat Transfer Coefficients from Classic Ansys Icepak
The second method that sits natively within Workbench involves mapping heat transfer coefficients onto surfaces. This of course means that the thermal problem must be solved again, but it does provide extra accuracy over uniform HTC approximations, and some extra flexibility for recalculating body temperatures that result from changing power input conditions. This might be the desired approach if you are working with a forced flow and are looking at thermal stress results across a range of CPU loads, for example. HTC coordinate maps can be exported from Classic Icepak through the “Full Report” command with “Only summary information” disabled.
The complicating factor for this method is that the file format and information is not compatible with Workbench for External Data mapping in its default form.
I wrote a simple python script for this purpose – it reads in the HTC coordinate data, makes it all positive, rewrites it as a CSV, and adds the necessary reference (ambient) temperature column. It is important to note here that there can be an error in reported HTC sign from Icepak. This is because the sign is determined by the direction of heat transfer, which is reported without consideration to the solid body surface normal direction. So, for entirely convex shapes, the sign will be correct, but for more complicated structures like heatsinks with surfaces facing every which way, the signs will be inconsistent. Once this is done, each column needs to be correctly associated in the external data definition and then mapped to the setup of your thermal simulation. In Mechanical, this causes an Imported Load to show up under Analysis, which you will then insert a Convection Coefficient into. This can be scoped to individual faces, which should of course be included with those chosen when exporting from Icepak.
For reference, the python script may look something like:
############################################ import numpy as np import sys ##Usage is 'python HTCCleanup.py inputfilepath AmbientTemperature' inputfile = sys.argv Temperature = float(sys.argv) #Bring in Icepak data file as argument data = np.loadtxt(inputfile,skiprows=25) #Make all HTCs positive data[:,4] = abs(data[:,4]) #Create and append a reference temperature column temparray = np.ones([len(data[:,0]),1])*Temperature data = np.append(data,temparray,axis=1) #Write to file np.savetxt('ProcessedReport.csv',data,delimiter=',',fmt='%.5e',header='Node#, x, y, z, HTC, TRef') ############################################
3: Temperatures from EDT Icepak
The electronics desktop version of Icepak is a newer and, in my opinion, a more user-friendly environment for Icepak simulations. However, since it does not integrate directly with Workbench, mapping over result data for further structural simulation is not as straightforward. Luckily for us, other users have already addressed this obstacle via an ACT extension!
This is the “Write Thermal Loads” extension that can be downloaded for free from the Ansys App Store (https://catalog.ansys.com).
Once loaded, the interface looks like this:
Basically, this is a guided wizard that will export an external data file with coordinate defined temperatures according to the EDT bodies you select with the Wizard. The wizard also generates some workbench script files that can be used to automate the import process, but the most important part to know is that the temperature data file is brought in through External Data in essentially the same way as the aforementioned HTC file. For those who are familiar with the EDT environment and want to take thermal results straight into a structural analysis, this is the preferred approach.
4: HTCs from EDT Icepak
This is perhaps the most awkward (and advanced) workflow, but it provides the same flexibility as with Classic Icepak HTCs, without the potential error in HTC sign, and with the benefit of working in the EDT environment. The portion of this flow most likely to contain errors is generating the HTC data file, as we must make use of a normally inaccessible operation in the Field Calculator. After solving an Icepak project and generating results, we should first create a face list including all of the convection faces of interest – this is done by selecting those faces in the GUI and then using the Modeler > List > Create > Face List to generate this face. Once the list is created, open the field calculator (Icepak > Fields > Calculator), and then perform the following steps:
- Input > Quantity > Heat Transfer Coefficient
- Input > Geometry > Surface > Face List
- Scalar > Mean > Undo (ONE TIME)
- Output > Write
The single undo operation grants us access to the intermediate step where HTC data is accessible as a “SclSrf: SurfaveValue(Surface,HTC)” datatype, and can also be accessed by performing undo after any other scalar operation on a scalar field definition. (such as integration over a surface or body or a min/max calculation, for example)
The .fld file produced with the write operation is close to usable in workbench, but still must be slightly reformatted and appended with a reference temperature column. I would suggest a python script that is very similar to the one used for Classic HTCs.
One thing to note is that these files generated by EDT can end up being much larger than you may expect. This is because the field calculator essentially forms a list of all the surface elements on the surfaces you have specified, decomposes them into triangular elements if necessary, and then reports the HTC value of that triangular element at each connected corner node. So, you end up with 3 times as many data entries as you have surface elements, multiple HTCs reported for each node that touches more than one surface element, and a correspondingly large file for fine meshes on complicated geometries. Still, Workbench will interpret this whole thing fairly well, and you should end up with a good HTC map to make use of in Mechanical.
The role of Ansys Electronics Desktop Icepak (hereafter referred to as Icepak, not to be confused with Classic Icepak) is in an interesting place. On the back end, it is a tremendously capable CFD solver through the use of the Ansys Fluent code. On the front end, it is an all-in-one pre and post processor that is streamlined for electronics thermal management, including the explicit simulation and effects of fluid convection. In this regard, Icepak can be thought of as a system level Multiphysics simulation tool.
One of the advantages of Icepak is in its interface consistency with the rest of the Electronic Desktop (EDT) products. This not only results in a slick modern appearance but also provides a very familiar environment for the electrical engineers and designers who typically use the other EDT tools. While they may not already be intimately familiar with the physics and setup process for CFD/thermal simulations, being able to follow a very similar workflow certainly lowers the barrier to entry for accessing useful results. Even if complete adoption by these users is not practical, this same environment can serve as a happy medium for collaboration with thermal and fluids experts.
Figure 1: AEDT Icepak interface. The same ribbon menus, project manager, history tree, and display window as other EDT products.
So, beyond these generalities, what does Icepak actually offer for an optimized user experience over other tools, and what kinds of problems/applications are best suited for it?
The first thing that comes to mind for both of these questions is a PCB with attached components. In a real-world environment, anyone that has looked at the inside of a computer is likely familiar with motherboards covered with all kinds of little chips and capacitors and often dominated by a CPU mounted with a heatsink and fan. In most cases, this motherboard is enclosed within some kind of box (a computer case) with vents/filters/fans on at least some of the sides to facilitate controlled airflow. This is an ideal scenario for Icepak. The geometries of the board and its components are typically well represented by rectangular prisms and cylinders, and the thermal management of the system is strongly related to the physics of conjugate heat transfer. For the case geometry, it may be more convenient to import this from a more comprehensive modeler like SpaceClaim and then take advantage of the tools built into Icepak to quickly process the important features.
Figure 2: A computer case with motherboard imported from SpaceClaim. The front and back have vents/fans while the side has a rectangular patterned grille.
For a CAD model like the one above, we may want to include some additional items like heatsinks, fan models, or simple PCB components. Icepak’s geometry tools include some very convenient parameterized functions for quickly constructing and positioning fans and heatsinks, in addition to the basic ability to create and manipulate simple volumes. There are also routines for extracting openings on surface, such as the rectangular vent arrays on the front and back as well as the patterned grille on the side. So, not only can you import detailed CAD from external sources, you can mix, match, and simplify it with Icepak’s geometry, which streamlines the entire design and setup process. For an experienced user, the above model can be prepared for a basic simulation within just a matter of minutes. The resulting configuration with an added heatsink, some RAM, and boundary conditions, could look something like this:
Figure 3: The model from Figure 2 after Icepak processing. Boundary conditions for the fans, vents, and grille have been defined. Icepak primitives have also been added in the form of a heatsink and RAM modules.
Monitor points can then assigned to surfaces or bodies as desired; chances are that for a simulation like this, temperature within the CPU is the most important. Additional temperature points for each RAM module or flow measurements for the fans and openings can also be defined. These points can all be tracked as the simulation proceeds to ensure that convergence is actually attained.
Figure 4: Monitoring chosen solution variables to ensure convergence.
For this simple system containing a 20 W CPU and 8 RAM modules at 2 W each, quite a few of our components are toasty and potentially problematic from a thermal standpoint.
Figure 5: Post-processing with Icepak. Temperature contours are overlaid with flow velocities to better understand the behavior of the system.
With the power of a simulation environment in Icepak at our fingertips, we can now play around with our design parameters to improve the thermal management of this system! Want to see what happens when you block the outlet vents? Easy, select and delete them! Want to use a more powerful fan or try a new material for the motherboard or heatsink? Just edit their properties in the history tree. Want to spin around the board or try changing the number of fins on the heatsink? Also straightforward, although you will have to remesh the model. While these are the kinds of things that are certainly possible in other tools, they are exceptionally easy to do within an all-in-one interface like Icepak.
The physics involved in this example are pretty standard: solid body conduction with conjugate heat transfer to a turbulent K-Omega fluid model. Where Icepak really shines is its ability to integrate with the other tools in the EDT environment. While we assumed that the motherboard was nothing more than a solid chunk of FR-4, this board could have been designed and simulated in detail with another tool like HFSS. The board, along with all of the power losses calculated during the HFSS analysis, could have then been directly imported into the Icepak project. This would allow for each layer to be modeled with its own spatially varying thermal properties according to trace locations as well as a very accurate spatial mapping of heat generation.
This is not at all to say that Icepak is limited to these kinds of PCB and CCA examples. These just often tend to be convenient to think about and relatively easy to geometrically represent. Using Fluent as the solver provides a lot of flexibility, and there are many more classes of problems that could be benefit from Icepak. On the low frequency side, electric motors are a good example of a problem where electronic and thermal behavior are intertwined. As voltage is applied to the windings, currents are induced and heat is generated. For larger motors, these currents, and consequently the associated thermal losses, can be significant. Maxwell is used to model the electronic side for these types of problems, where the results can then be easily brought into an Icepak simulation. I have gone through just such an example rotor/stator/winding motor assembly model in Maxwell, where I then copied everything into an Iecpak project to simulate the resulting steady temperature profile in a box of naturally convecting air.
Figure 6: An example half-motor that was solved in Maxwell as a magnetostatic problem and then copied over to Icepak for thermal analysis.
If it is found that better thermal management is needed, then extra features could then be added on the Icepak side as desired, such as a dedicated heatsink or external fan. Only the components with loads mapped over from Maxwell need to remain unmodified.
On the high frequency side, you may care about the performance of an antenna. HFSS can be used for the electromagnetic side, while Icepak can once again be brought in to analyze the thermal behavior. For high powered antenna, some components could very easily get hot enough for the material properties to appreciably change and for thermal radiation to become a dominant mode of heat transport. A 2-way automatic Icepak coupling is an excellent way to model this. Thermal modifiers may be defined for material properties in HFSS, and radiation is a supported physics model in Icepak. HFSS and Icepak can then be set up to alternately solve and automatically feed each other new loads and boundary conditions until a converged result is attained.
What all of this really comes down to is the question: how easy is it for the user to set up a model that will produce the information they need? For these kinds of electronics questions, I believe the answer for Icepak is “extraordinarily easy”. While functional on its own merit, Icepak really shines when it comes to the ease of coupling thermal management analysis with the EM family of tools.