Compressive strength of hollow microlattices: Experimental characterization, modeling, and optimal design

Abstract

Recent advances in multiscale manufacturing enable fabrication of hollow-truss based lattices with dimensional control spanning seven orders of magnitude in length scale (from ∼50 nm to ∼10 cm), thus enabling the exploitation of nano-scale strengthening mechanisms in a macroscale cellular material. This article develops mechanical models for the compressive strength of hollow microlattices and validates them with a selection of experimental measurements on nickel microlattices over a wide relative density range (0.01–10%). The limitations of beam-theory-based analytical approaches for ultralight designs are emphasized, and suitable numerical (finite elements) models are presented. Subsequently, a novel computational platform is utilized to efficiently scan the entire design space and produce maps for optimally strong designs. The results indicate that a strong compressive response can be obtained by stubby lattice designs at relatively high densities (∼10%) or by selectively thickening the nodes at ultra-low densities.

Appendix: Architecture of the Computational Platform

All the FEs calculations described in this work were generated with the recently developed PMAT.19,20 This modeling platform consists of three interconnected tools: (i) a geometric modeling and meshing algorithm, (ii) a data management system, and (iii) an interface for automatic communication with a FEs package (Abaqus, in the current implementation). The entire platform is almost completely parameterized and automated, with minimal input required from the operator. Input parameters include the cellular lattice topology (e.g., a periodic pyramidal lattice), the space of design parameters (e.g., the allowable ranges of each dimension, possibly interdependent), the objective function, and the constraints. The PMAT code may be designed to sample the entire parameter space (as in its current implementation) or include a family of discrete optimizers; the code identifies the specific designs to be modeled, automatically generates representative geometries and meshes as appropriate, creates input files for FE execution, controls the FE job submissions, extracts results from the FE output files, and handles the results.

Code architecture

The architecture of the entire code is schematically depicted in Fig. A1. Colored boxes represent cohesive system components or modules. Double-boxes represent process boundaries and are effectively single executable programs. Single square boxes denote complicated multiobject systems and rounded boxes represent single objects; stacks represent arrays of either. The Database Manager provides a user interface for interacting with loaded databases and preparing simulations for operation. For systematic exploration of the parameter space (which is the operation described in Sec. IV), the databases are created with a number of constants describing the structure (topology, angle, fillets, defect type, defect magnitude, material) while leaving two dimensionless unknowns to be swept: L/D and t/D. Each of these databases contains an array of Database Part objects, each of which corresponds to a discrete L/D value. Each Database Part object includes a quadratic optimizer that calculates t/D to match a prescribed relative density to a high degree of precision. With each t/D value, a Database Entry is constructed, which is a fully described design corresponding to a particular density within the database. Each Database Entry object has an arbitrary number of Database Boundary Property objects associated with it. Each Boundary Property contains the formal description of a particular class of simulations relating to that design, e.g., boundary conditions, lattice dimension, element type, and property of interest. Simulation results reside here, including stresses, strains, reaction loads, elastic/shear moduli, eigenvalues, predicted buckling loads, etc.

FIG. A1.

Schematic of the PMAT code architecture.

The Network Interface Management System (STORM) is a highly threaded object that manages inbound clients (e.g., the commercial FE package ABAQUS) and acts as an interface layer between the Data Management System and the simulation application. When being prepared for operation, each Database triggers all its designs (Database Entry objects) to generate a set of related analysis jobs (STORM job objects). Each job corresponds to a discrete simulation and contains information on its identity (session and job number, type) as well as pointers in memory for where to find and where to put relevant information (e.g., the design of interest, boundary conditions, and results). To enable more complex simulations and dependencies, each job may link to other jobs and other resources on disk. The STORM Server communicates with FE analysis packages through TCP/IP protocol. Administrative interaction with the STORM Server is enabled by a STORM Network Controller, which merely acts as a remote user interface. Dedicated modules can be written to optimize the interaction with commercial packages. For the case of the FE package ABAQUS, two modules are implemented: (i) The STORM CAE Client, written in Python and executed within CAE, is responsible for communicating availability to the STORM Server, receiving job data, initiating and monitoring simulations, then analyzing and returning results to the server. (ii) The STORM HYDRA Client is a multirole tool for managing ABAQUS CAE, including an interface for programming the clients behavior, initiating an appropriate number of client processes, and the monitoring and respawning of new clients as necessary. This also allows for rudimentary manual load-balancing and license management of the system when job types of different performance characteristics are available for execution. The STORM Server handles and processes all STORM jobs. Once the STORM Client (e.g., ABAQUS) confirms resource availability (in terms of computational power and licenses), the STORM Server selects one job from the queue and, through the STORM Particle interface, retrieves the database entry associated with it (containing all the geometric information), adds the requested Database Boundary Properties (lattice dimension, boundary conditions, etc…), and invokes the geometry engine (described above) to create a suitable mesh and an a properly formatted input file for ABAQUS analysis. The input file is then sent to the ABAQUS Client via TCP/IP, and the result of the analysis is stored back into the Database Entry after completion. This process is schematically represented by the arrows in Fig. A1.

Geometric modeling and meshing

This component of the modeling platform (contained in the geometry kernel) is responsible for parametric generation of solid and/or shell geometries and their adequate meshing for FE analysis. Conceptually, this operation is carried out in five subsequent steps: (i) definition of lattice points; (ii) definition of nodal connectivity (members locations); (iii) member profiling (the cross-section of each lattice bar has been assumed uniformly circular in this work, but more complex sections are possible); (iv) generation of fillets and smooth member connections (the most mathematically intense section of the code, where complex surfaces simultaneously tangent to all truss members are created); and (v) meshing and assembly of the lattice (Fig. A2). The mathematical details are omitted for the sake of conciseness (see Ref. 18 for details).

FIG. A2.

Sequence of steps in the geometric modeling platform. (a) Lattice points definition. (b) Truss members definition (nodal connectivity). (c) Truss member profiling. (d) Generation of fillets and smooth member connections. (e) Assembly and meshing.