Thermal mechanical lattice search that reports unsatisfiable requests
A property-registry contract for retrieve-or-refuse thermal-mechanical lattice search
Computational Engineering, Finance, and ScienceArtificial Intelligence
Summary
When engineers look for special materials that are light, stiff, conduct heat well, and cheap, they often find no perfect match in existing libraries. The authors created a system that doesn’t just return the closest match but can also explain which requirements conflict and suggest the smallest changes needed to find a suitable design. Their method checks many possible material and lattice combinations quickly and accurately determines when no design fits all the constraints, helping engineers decide what to adjust. This approach improves design searches by refusing impossible requests and pinpointing trade-offs clearly.
What this means in practice
- •For materials engineers: Identify when materials and design constraints cannot be jointly met and get precise suggestions on which requirements to relax for feasible lattice structures.
- •For mechanical design teams: Ensure design searches quickly refuse impossible property combinations and return exact advice on requirement adjustments for optimized thermal-mechanical lattices.
Authors
Shaoliang Yang, Henry Chu, Zu Yashengjiang, Jun Wang
Abstract
Early thermal-mechanical lattice requirements are knowledge-intensive and often jointly unsatisfiable: an engineer asks for a cell that is light, stiff, laterally conducting and cheap, and no cell in the library satisfies it. A design system should say so, and say which requirement to loosen and by how much, rather than return the nearest row. A generative model can return a candidate even when the library holds none. This work applies established conflict diagnosis to a catalogue of homogenised properties. Search over 1,397 homogenised unit cells and 19 base materials (26,543 combinations) returns a catalogue row that a second solver can rebuild, or, for an empty feasible set of at most eight constraints, inclusion-minimal unsatisfiable subsets (MUS) and the slack of a repair, not a neighbour. One registry declaration generates the prompt and the evaluator, so undeclared parsed keys cannot reach search. On a frozen suite of 64 typed queries, retrieve-or-refuse matches min-repair on every feasible query (48/48) and refuses every empty one (16/16) with MUS and slack. Constraint-ignoring nearest-neighbour and penalty search violate stated cost or density limits. On 216 empty queries, repairs printed at three significant figures and rounded outward stay feasible in every case (216/216). When density and cost must be kept, a list of minimum-cardinality repairs keeps them on 209 of 211 queries; a protection-first repair keeps them on all 211, the same as full diagnosis. A 308-request parse benchmark is a template-text check, not unconstrained engineer prose.