Electronics products are built from lots of components, PCBs, etc. which are themselves quite complex. A single IC package can be made of more than half a dozen or so different materials. They also tend to be ‘cluttered’ with the number of individual objects running into the hundreds, and miniaturization is only making this worse. Things tend to get changed and moved around a lot as the design progresses. For each change the CFD model needs to be re-meshed and the boundary conditions to be re-applied. Doing this for each design iteration using the traditional CFD process described in the previous post is just WAY too time consuming.
Accommodating geometry change in the traditional CFD process is a knotty problem.
Actually it’s more than just knotty - it’s a Gordian knot requiring an Alexandrian solution. As Einstein said:
“Problems cannot be solved by the same level of thinking that created them.”
The solution to the problem is not to find a way to do the steps faster. Rather it is to do the steps in a different order.
The key is to associate boundary conditions with geometry at the start of pre-processing, not with the mesh at the end. That way, when geometry is moved any boundary conditions move with the object.
A simple solid object will require a wall boundary condition, known in the trade as a wall function, on its surface to provide friction and heat transfer to the surrounding fluid. So what happens when two solid objects are brought into contact with one another, as below?
Where they contact, shown in red, the solid-fluid wall function boundary condition on each object needs to be replaced by a solid-solid conduction link so the objects are in perfect thermal contact. Hence each object needs to know it’s in contact with the other.
But all objects are not created equal. A fan needs a different set of ‘rules’ or attributes, which govern how it interacts with other objects. If it’s inside the model the fan needs to provide a source of momentum to the fluid passing through it, but if it’s on the boundary of the solution domain it needs to either supply or extract mass. The pre-processor has to be able to interpret an object’s attributes and behaviors - particularly it’s interaction with other objects, to decide what boundary condition information to supply to the solver.
Creating the mesh is the final step before solving. So what about mapping the boundary conditions onto the mesh? That becomes part of the solution process, handled by the software, so is no longer the user’s concern.
The bottom line is that the productivity requirements of systems integrators using CFD for electronics thermal design precludes the traditional CFD process described in the previous post - but that has more to do with mesh generation than anything else. More on that next time.
When I get around to it I’ll tell you about the fluid dynamics problem I have with a BBQ I built a few years back. In the meantime if you have any comments or an interesting CFD meshing story feel free to share!