Electronics thermal management
Electronics thermal management and cooling simulation
Getting heat out of a board, a module or a sealed enclosure — by air, by conduction, or by a heatsink that may or may not be earning its volume. Conjugate heat transfer solves the air and the solid in one case, which is what an electronics thermal question almost always needs.
Questions this answers
- What temperature does this part reach in this enclosure?
- Is natural convection enough, or does this need a fan?
- Which path is the heat actually taking out of the assembly?
- What does a transient duty cycle do that steady state hides?
- Does this heatsink geometry beat the simpler one?
The analysis types that do it
Each of these is a case type in the application, not a configuration you assemble. Every one runs in the free build — the free tier limits mesh size and cores, never which physics you may use.
And in the other modules
Structural, thermal and electromagnetics ship alongside fluids. Only the types that run today are listed.
Backends underneath
chtMultiRegionFoamchtMultiRegionSimpleFoambuoyantSimpleFoambuoyantPimpleFoambuoyantBoussinesqSimpleFoamlaplacianFoamsolidFoamthermoFoam
Open-source solvers, selected and configured from the case type. You can still read every dictionary the application writes.
When it will not fit on your machine
Paid accounts can send meshing and solving to SHD Cloud and keep working locally. The estimate is shown before the run starts.
What this does not do
- No component thermal libraries — no two-resistor models, no JEDEC part data.
- No ECAD import; copper distribution is geometry you build, not a layer stack we read.
- Thermal interface materials are a material and a thickness, not a vendor database.
Naming a sector here says the physics suits the work. It is not a claim that anyone in it is a customer.