Posted on November 12, 2019, by: Eric Miller
Here at PADT, we pride ourselves on our ability to make our customers’ ideas for innovation practical and get them to market. No matter how complex the challenge is, we have the engineering expertise and technology tools to work with our customers and deliver tailored solutions to meet their needs. And for every solution we create, there’s a business development team leading the partnership with our customers. We’re excited to welcome the newest leader of this team who introduced the free invoice template, Business Development Manager for Engineering Services, Jeff Wells.
“PADT’s engineering services are thriving behind the work of our outstanding team,” said Eric Miller, co-founder and principal, PADT. “Jeff adds a tremendous amount of experience as both an engineer and a business development leader. His knowledge of the industry and the community will elevate our ability to attract new and innovative customers.”
To help PADT improve its market position in engineering services and product development, Wells will be responsible for building new customer relationships and seeking new opportunities to solve complex challenges. His focus will be on serving customers in a wide variety of industries, including aerospace and defense, medical, and industrial.
“Throughout my many years in engineering here in Arizona, I’ve been keenly aware of the outstanding services provided by PADT,” said Wells. “The company’s reputation and the wonderful people I’ve gotten to know over the years made it an easy decision to join the team. I look forward to contributing to the company’s strategy for growing its engineering services department.”
Wells brings nearly 30 years of engineering, business development, and sales experience to the position. He joins PADT after spending the past five years in the director of business development role at CollabraTech Solutions. Wells joined CollabraTech early in the company’s lifecycle and helped grow the gas and chemical delivery product company from a few million dollars in revenue to over $14 million, by diversifying their customer base, the markets they served and the projects they pursued.
Early in his career, Wells worked as an engineer designing a wide variety of products from parts for Airbus aircraft engines to laser part marking kiosks and semiconductor capital equipment. He quickly realized his propensity for combining his engineering expertise with his communication skills, and in the late ‘90s, he began his career in business development. Wells worked at Advanced Integration Technologies for 10 years as a business development engineer and business development manager. He later worked closely with senior leadership on business development operations at Ultra Clean Technology and led business development for Foresight Processing.
Wells holds a Bachelor of Science in Aerospace Engineering from Arizona State University (ASU). He and his wife, Kate Wells, CEO of the Phoenix Children’s Museum, have been married for 27 years and have two daughters who attend school at Massachusetts Institute of Technology and Barrett, the Honors College at ASU. In their free time, Wells and his family enjoy traveling. A decade ago, Jeff and his wife took their two daughters out of school for 14 months backpacking around the globe, visiting 22 countries. Wells also enjoys being outdoors hiking, playing sports, snowboarding and water skiing.
To learn more about PADT’s engineering service capabilities and to connect with Jeff Wells, please visit www.padtinc.com/services or call us at 1-800-293-7238.
Posted on October 31, 2019, by: Matt Sutton
Customizations developed using ANSYS ACT adhere closely to the user experience that is native to Mechanical and other Workbench apps. Obviously, this is to be expected, but sometimes it can be a little challenging to fit a particular workflow into the “tree object” plus “object properties” model. One way to broaden the available set of user experiences from which to construct a customized behavior is to use what are known as property controllers.
Property controllers are classes, which can be implemented either in C# or Python that are associated with a given property in the details pane of a given ACT object. These classes allow the programmer to specialize the functionality and behavior of the particular property to which they are associated. The association between a given property and its property controller is made in the ACT XML definition file. For this article, like most of the ones I write on ACT, I will be using C# as the implementation language.
The degree to which any given property can be specialized by a property controller is quite vast. Therefore, I won’t be able to touch on all of the possible combinations. However, I will demonstrate two that I have found particularly useful in various ACT apps I’ve written.
The first is a custom “select” controller that allows the user to pick one of a set of given Mechanical objects. For most customizations, perhaps the canonical example, is a select controller that allows a user to pick a particular coordinate system out of all of the defined coordinate systems in the model. Yes, there is a template for this that ships with Mechanical, but I will show a given implementation. Understanding how the controller works will enable you to apply the same technique to other object types, even other ACT objects within the same app.
The second is a way to “fly out” a dialog box that can contain additional custom controls, and that is “anchored” to the side of the given property box within the details pane. This is useful for scenarios when we can’t easily fit a particular data entry within a given property field. Tabular data is a prime example. Again, there are some templates for this in Mechanical, but understanding how to build it up from scratch will allow you to apply the same principles to more complex dialogs. This second example will be covered in a subsequent blog post.
Before we dive into the individual examples above, let’s understand some of the basics of property controllers in general. First, how do we associate a given property controller class with a particular property. This is accomplished by using the “class” attribute in the property tag within the XML definition. So, here is an example from an extension XML file:
<property name="EngineAxis" caption="Coordinate System" control="select" class="PADT.PropertyControllers.CoordinateSystemSelectController"> <attributes type_filter="cylindrical"/> </property>
You can see that we’ve added a “class” attribute inside the property tag and set it equal to a fully qualified class name. All other property attributes are the same as with a typical property. In order for this to work, however, we will need to implement a class called “CoordinateSystemSelectController” in the PADT.PropertyControllers namespace.
You will also notice that there is a nested <attributes> tag inside the <property> tag. This can be used to pass additional configuration data to the controller as we will see. Clearly, in this case, the additional data is designed to constrain the types of coordinate systems that will be populated within the control.
Example 1: Coordinate System Select Property Controller
The method by which behavior is customized for a given property is by implementing overrides for a series of virtual functions defined on the property itself. These virtual functions allow us to hook into various points within the properties lifetime and operation. The names for these virtual functions correspond to the callbacks listed in the ANSYS help for the <property> tag in the ACT XML reference manual. The names are always lowercase. Common ones that I use are functions such as “onactivate”, “onshow”, “isvalid”,”value2string” and “getvalue”. Except for the “value2string” function, most of these are probably self-explanatory as to when they would fire. For this controller, I’ll demonstrate a few of these functions including when and how to use the “value2string”.
Let’s begin with the “onactivate” function. This function is called when the user “selects” or activates the property. So, within this function is a good place to populate the list of currently available coordinate systems. It is tempting to cache this list so that it doesn’t have to be recomputed. However, if the user deletes, or adds a coordinate system after we have cached the list, we would not display it as an option the next time they activated this control. Therefore, on each activation, we build up a list of available coordinate systems. Here is the code:
You can see the parameters to this function are parameter representing the “tree object” to which this property is a member of that object’s details pane, and a parameter representing this “property”. The second parameter might seem counterintuitive. You might think that we are subclassing the property itself and thus this parameter would be redundant. (i.e, it would be equivalent to the “this” object). However, we are not subclassing the property per say, but rather implementing a controller object that property itself makes calls against to modify its own behavior. Sounds convoluted, I understand, but my guess is that this is what allows us to specify all of this within the extension XML file. So, it’s a good thing.
Once we get into the function proper, on line 55 we clear out all of the items within this properties associated drop down control. Then, in lines 56-58 we figure out what are the enum constants that represent the types of coordinate systems (cylindrical, Cartesian, etc…) that we would like to present to the user. Note, our attribute “type_filter” could contain multiple types. Then, in lines 59-67, we iterate over all of the coordinate systems current defined in the Mechanical session and pick out the ones that are of the right type. We then add them to the “options” property of this SimProperty object. Note, however, that we don’t add the coordinate system objects themselves, but rather string representations of the object Ids. This is important. The reason we don’t add the name of the coordinate system is because names (or labels) in Mechanical are not required to be unique. You can create five coordinate systems and name all of them “Bob”, Mechanical doesn’t care and will treat them as unique. So, we need a unique attribute of the coordinate system to store in our list of options. The object Id is guaranteed to be unique. So, we store this instead.
The final bit of code in this function just makes sure to default select one coordinate system if the user hasn’t already selected one. That functionality is on lines 69-83. If the Value property is null, then the user (or this code) has not populated the select with a given coordinate system. So, if there are any coordinate systems that are appropriate we just find the first one and select it automatically. Note, if the user later changes this to a different CSYS and this function fires a second time, it will not overwrite their choice because the null check will fail on line 69. The reason for this behavior is because the extension for which this code was written made extensive use of a single cylindrical coordinate system in a number of different objects. Typically the user would add just this one coordinate system in addition to the default global Cartesian system. So, by adding this code, the user would not be required to select this coordinate system each time they added a new object, but rather, the tool would do it for them.
The next bit of code to examine is the “value2string” function, which is shown below:
You may recall from above that the data we store in the options property was a list of string representations of the various coordinate system Ids. Now, if we didn’t implement this function, when the user interacted with the drop down control what they would see would be a list of numbers. They might see a list like “42” “87” and “94”. Clearly, it’s not very intuitive as to which coordinate system these numbers may refer.
So, what the “value2string” function allows us to do is to transform the data that the property actually stores into a visual representation that is meaningful to the user. However, this is purely a stateless transformation. The actual data store in the property always remains the string representation of the object’s id. So, you can think of this function as sitting between the internal code that pulls a value out of the property, and the internal code that renders that value to the screen. In between these two calls, we have the opportunity to transform what gets rendered.
So, essentially what we do inside this function is parse the Id string back into an integer. If that’s cool, we then lookup the particular mechanical tree object that has this given Id. Finally, if everything is kosher with this object, we return the name of the object we looked up. If at any point something goes wrong, we just return an empty string.
Now, when the user interacts with the property controller, the will see a list of names corresponding to the coordinate systems of the appropriate type. If they sadistically named all of these coordinate systems the same name, then they will see a list with multiple entries of the same name. However, each one in the list is a unique coordinate system. How they figure out which one is the one they actually want is now their problem…
Finally, the last function we will look at is the “getvalue” function. As the “value2string” function made the experience of the end user more palatable, so too the “getvalue” function makes the experience of the developer more palatable. Essentially what it does is analogous to the “value2string” function, but rather than returning a string, it returns an actual coordinate system object that can be used in other places in the system. It looks like the following:
As you can see, it is very similar to the “value2string” object, but instead of returning a string, it returns the actual tree object itself. Note, you have to cast the return value at the caller site to the appropriate type, but meh… it’s still nice to have.
Finally, to see this property controller in action, I’ve taken a quick screen grab of the properties pane of an ACT object I’ve implemented. This is a little symmetry object that implements a homebrewed CPCYC, but you can see the coordinate system object.
That’s all for this post. Next time we’ll look at how to implement the flyout feature. Good luck with your ACT programming needs. Oh, and if you need some help, or ever want to have some ANSYS customization done for you, let us know. We do all sorts of customization work from more run of the mill type
Posted on October 9, 2019, by: Ted Harris
In our last blog, we discussed using Nonlinear Adaptive Region to overcome convergence difficulties by having the solver automatically trigger a remesh when elements have become excessively distorted. You can read it here: http://www.padtinc.com/blog/ansys-mechanical-overcoming-convergence-difficulties-with-automatic-remeshing-nonlinear-adaptive-region/
This time we look at another tool for overcoming convergence difficulties, the Semi-Implicit method. ANSYS, Inc. describes the semi-implicit method as a hybrid, combining features of both implicit and explicit finite element methods.
In highly nonlinear problems involving significant deformations we may get a solver error like this one:
*** ERROR *** CP = 18110.688 TIME= 11:58:42
Solution not converged at time 0.921 (load step 1 substep 185). Run terminated.
Like it does with other problems that lead to convergence failures, the Solution branch will have telltale red lightning bolts, indicating the solution was not able to complete due to nonconvergence.
In this case, it can be difficult to determine from the error message in the solution output exactly what the problem is. Plotting the Newton-Raphson residuals can be a good starting point. In order to plot the Newton-Raphson residuals, though, we need to turn them on prior to solving. See this older Focus blog for instructions on how to do that:
A plot of the Newton-Raphson residuals shows us where the highest force imbalance is in the model:
That’s a nice looking plot, but doesn’t tell us much without knowing more about the simulation. The model is of a plastic bottle, subject to a force load tending to ‘crush’ the bottle from top to bottom. There is a slight off center load as well, so that the force is not purely in the downward direction.
The bottle is constrained with a fixed support on the bottom flat surface, and contact elements between the outer surface of the bottle and a fixed surface representing a table or floor. This is to prevent the bottle from deflecting below the plane of that surface.
The material used is a polyethylene plastic, from the ANSYS Granta Materials Data for Simulation add-on, which is a great tool to get access to hundreds of materials for ANSYS simulations. The geometry of the bottle was created in SpaceClaim as a surface body and meshed with shell elements in ANSYS Mechanical.
The solution was run as nonlinear static, with large deflection effects turned on. Automatic Time Stepping was manually activated with a starting and minimum number of substeps set to 200 and a maximum number of substeps set to 1000.
With these settings, the solution ran to about 92% of the full load, where it failed to solve after bisecting to the maximum number of substeps (minimum ‘time’ step). The force convergence plots showed the bisections and failed convergence attempts started at about iteration 230 and ‘time’ 0.92. (If you are not familiar with the convergence plots from a Newton-Raphson method solution, please see our Focus archives for an article on the topic – look for the link to the GST Plot: http://www.padtinc.com/blog/wp-content/uploads/oldblog/PADT_TheFocus_08.pdf).
Even though our solution has not converged, it is probably helpful to view the deformation results for substeps which did converge (at partial load) as well as the unconverged results which will be written as the last set of results.
This plot shows the total deformation at the last converged substep (time value 0.92):
This plot shows the unconverged solution, ‘extrapolated’ to time 1.0:
From the unconverged deformation plot we can see that the top of the bottle is tending to experience very large deformations. It’s not surprizing that convergence difficulties are being encountered.
One of the techniques we can utilize to get past this problem is the Semi-Implicit method in ANSYS Mechanical. As of 2019 R2, this needs to be activated using a Mechanical APDL command object, but it can be as simple as adding a single word within the Static Structural branch:
There are some optional fields on that command, but minimally just the one word command is needed.
Once the semi-implicit method is activated, if the solver detects the default implicit solver is having trouble, it automatically switches to the semi-implicit solving scheme. Like a traditional explicit solver, the semi-implicit method can better handle very large deformation, transitory-like effects. The method can switch back to implicit if conditions warrant for a more efficient solution and in fact can switch back and forth between the two schemes.
The solver output will tell us if the semi-implicit scheme has been activated:
EQUIL ITER 26 COMPLETED. NEW TRIANG MATRIX. MAX DOF INC= 0.9526
NONLINEAR DIAGNOSTIC DATA HAS BEEN WRITTEN TO FILE: file.nd004
DISP CONVERGENCE VALUE = 0.3918 CRITERION= 1.448 <<< CONVERGED
LINE SEARCH PARAMETER = 0.4113 SCALED MAX DOF INC = 0.3918
FORCE CONVERGENCE VALUE = 44.44 CRITERION= 0.9960
MOMENT CONVERGENCE VALUE = 3.263 CRITERION= 0.1423
Writing NEWTON-RAPHSON residual forces to file: file.nr001
>>> TRANSITIONING TO SEMI-IMPLICIT METHOD
NONLINEAR DIAGNOSTIC DATA HAS BEEN WRITTEN TO FILE: file.nd001
EQUIL ITER 1 COMPLETED. NEW TRIANG MATRIX. MAX DOF INC= 0.8788E-04
NONLINEAR DIAGNOSTIC DATA HAS BEEN WRITTEN TO FILE: file.nd002
*** LOAD STEP 1 SUBSTEP 185 COMPLETED. CUM ITER = 284
*** TIME = 0.920010 TIME INC = 0.100000E-04
Kinetic Energy = 0.2157 Potential Energy = 60.59
*** AUTO STEP TIME: NEXT TIME INC = 0.10000E-04 UNCHANGED
NONLINEAR DIAGNOSTIC DATA HAS BEEN WRITTEN TO FILE: file.nd003
There are some ‘symptoms’ of the switch from implicit to explicit. The most obvious is probably that the force convergence plot will stop updating.
Changing the Solution Output to the Solver Output will show the explicit scheme being used in that case. The telltale is the information on Response Frequency and Period (the example shown is a static structural solution).
Deformation plot trackers and contact trackers continue to work as expected during the solution, however.
Using the semi-implicit method, the solution was able to successfully converge to the full load, and converged results are available at the last time point:
We also used the new keyframe animation technique to animate the results time history.
The semi-implicit method is well documented within the Mechanical APDL 2019 R2 Help, in the Advanced Analysis Guide, chapter 3 on Semi-Implicit Method. We suggest reviewing that information to get a much better handle on the technique.
We hope this is helpful in getting your nonlinear solutions to converge the full value of applied loads.
Posted on September 4, 2019, by: Eric Miller
While attending the 2019 RAPID + TCT conference in Detroit this year, I was honored to be interviewed by Stephanie Hendrixson, the Senior Editor of Additive Manufacturing magazine and website. We had a great chat, covering a lot of topics. I do tend to go on, so it turned into two videos.
The first video is about the use of simulation in AM. You should watch that one first, here, because we refer back to some of the basics when we zoomed in on optimization.
Generative design is the use of a variety of tools to drive the design of components and systems to directly meet requirements. One of those tools, the most commonly used, is Topological Optimization. Stephanie and I explore what it is all about, and the power of using these technologies, in this video:
You can view the full article on the Additive Manufacturing website here.
If you have any questions about how you can leverage simulation to add value to your AM processes, contact PADT or shoot me an email at firstname.lastname@example.org.
Posted on September 4, 2019, by: Eric Miller
While attending the 2019 RAPID + TCT conference in Detroit this year, I was honored to be interviewed by Stephanie Hendrixson, the Senior Editor of Additive Manufacturing magazine and website. We had a great chat, covering a lot of topics. I do tend to go on, so it turned into two videos.
In the first video, we chat about how simulation can improve the use of Additive Manufacturing for production hardware. We go over the three uses: optimizing the part geometry to take advantage of AM's freedom, verifying that the part you are about to create will survive and perform as expected, and modeling the build process itself.
You can read the article and watch the video here on the Additive Manufacturing website. Or you can watch it here:
If you have any questions about how you can leverage simulation to add value to your AM processes, contact PADT or shoot me an email at email@example.com.
For the second interview, we focus on Topological Optimization, Generative design, and the difference between the two. Check that out here.
ANSYS Mechanical – Overcoming Convergence Difficulties with Automatic Remeshing (Nonlinear Adaptive Region)
Posted on August 19, 2019, by: Ted Harris
One of the problems we can encounter in a nonlinear structural analysis in ANSYS Mechanical is that elements become so distorted that the solver cannot continue. We get messages saying the solver was unable to complete, and the solver output will contain a message like this one:
*** ERROR *** CP = 37.969 TIME= 14:40:06
Element 2988 (type = 1, SOLID187) (and maybe other elements) has become
highly distorted. Excessive distortion of elements is usually a
symptom indicating the need for corrective action elsewhere. Try
incrementing the load more slowly (increase the number of substeps or
decrease the time step size). You may need to improve your mesh to
obtain elements with better aspect ratios. Also consider the behavior
of materials, contact pairs, and/or constraint equations. Please rule
out other root causes of this failure before attempting rezoning or
nonlinear adaptive solutions. If this message appears in the first
iteration of first substep, be sure to perform element shape checking.
The Solution branch will have the telltale red lightning bolts, indicating the solution was not able to complete due to nonconvergence.
If you are not aware, one technique we can use to get past this problem of excessive element distortion is to have ANSYS automatically remesh the model or a portion of the model while the solution is progressing. The current state of the model is then mapped onto the new mesh, in the currently deflected state. In this manner we can automatically continue with the solution after a slight pause for this remeshing to occur. Minimally all we need to do as users is insert a Nonlinear Adaptive Region under the Static Structural branch, and review and specify a few settings (more on this later).
Let’s take a look at a simple example. This is a wedge portion of a circular hyperelastic part, subject to a pressure load on the top surface. Other boundary conditions include a fixed support on the bottom and frictionless supports on the two cut faces of the wedge.
For this case, the nonlinear adaptive region is the entire part.
The initial mesh was setup as a default mesh, although note that for 3D models the nonlinear adaptive capability requires a tetrahedral mesh up through the current version, 2019 R2.
Prior to solving with the nonlinear adaptive region included, this model fails to converge at about 56% of the total load. With the addition of the nonlinear adaptive region, the model is automatically remeshed at the point of excessive element distortion, and the solution is able to proceed until the full load is applied. The force convergence graph has a solid vertical orange line at the point where remeshing occurred. The method can result in multiple remeshing steps although in the sample model shown here, only one remeshing was needed.
The image on the left, below, shows the original mesh at the last converged substep before remeshing occurred. The image on the right is the first result set after remeshing was completed.
The tabular view of a result item will show in the last column if remeshing has occurred during the solution.
Here is the final deformation, for the full amount of pressure load applied on the top surface.
Next, let’s take a look at the nonlinear adaptive region capability in more detail.
First, multiple substeps must be used for the solution. If we are performing a nonlinear analysis, this will be the case anyway. Second, Large Deflection needs to be turned on in the Analysis Settings branch. Also, results must be stored at all time points (note that time is a tracking parameter in a static analysis, but all static as well as transient results in ANSYS Mechanical are associated with a value of ‘time’).
There are several restrictions on features that CAN’T be in the model, such as cyclic symmetry (hence the frictionless support BC’s on the simple model shown above), Auto Asymmetric Contact, Joints, Springs, Remote Forces and Displacements, etc. Also certain material properties are excluded, such as Cast Iron plasticity and Shape Memory Alloy. Also, as mentioned above, for 3D models, the mesh must be tetrahedral. For a full listing of these restrictions, refer to the ANSYS Mechanical User’s Guide. A search on ‘nonlinear adaptive’ will take you to the right location in the Help.
Nonlinear Adaptive Regions can be scoped to 3D solid and 2D bodies, or to elements via a Named Selection.
In the Details view for the Nonlinear Adaptive Region, the main option to be defined is the Criterion by which remeshing will be initiated. There are three options available in Mechanical: Energy, Box, and Mesh.
The Energy criterion checks the strain energy of each element within the Nonlinear Adaptive Region. If the strain energy is above a criterion, remeshing is triggered. The input is an energy coefficient between zero and one, and is a multiplier on the ratio of total strain energy of the component divided by the number of elements of the component. Recommended values are 0.85-0.9. A lower coefficient will tend to cause remeshing to be more likely.
The Box criterion defines a geometry region based on a coordinate system and bounds relative to that coordinate system. Elements in the Nonlinear Adaptive Region whose nodes have all moved within the box will be remeshed. The idea is that if it’s known that elements will be highly distorted as they move into a certain region, we can ensure that remeshing will occur there.
The Mesh criterion allows us to specify that remeshing will occur if mesh quality measures drop below certain levels as the mesh distorts. For 3D models, the available measures are Jacobian Ratio and Skewness. These are described in the Mechanical User’s Guide in the section on Nonlinear Adaptive Region.
In the example shown above, the Energy criterion was used with an energy coefficient of 0.85.
There are some things to be aware of when you are trying to implement a Nonlinear Adaptive Region to help overcome convergence difficulties. First, if any of the restricted features mentioned above are included in the model, such as remote displacements, it’s not going to work. Therefore, it’s important to review the list of restrictions in the Help and make sure none of those are applied in your model. Second, ‘buckling’ or element distortion due to an unstable structure is not a behavior that Nonlinear Adaptive Regions can help with. The Nonlinear Adaptive Region capability is more suited to problems like hyperelastic seals being compressed or objects that are undergoing a high degree of bending (but not snapping through).
Also, a coarse mesh that distorts may not produce a usable remesh. The remeshing step may occur, but the simulation may not be able to proceed beyond that and stops with an error in element formulation error. More mesh refinement may be needed in this case.
As a further word of caution, self contact problems may not work very well within the context of Nonlinear Adaptive Regions. If self contact is needed, consider splitting the bodies into multiple parts to avoid self contact.
There are some other considerations for the method as discussed in the Help, but hopefully the guidelines and recommendations presented here will allow you to filter potential applications appropriately and setup models that can take advantage of the Nonlinear Adaptive Region capability. We have a short animation which shows the remeshing step in the sample model.
If you have nonlinear static structural models with convergence difficulties due to excessive element distortion, please consider using this method to help you get a fully converged solution.
Here is a video to help everyone visualize:
Press Release: PADT Awarded U.S. Army Phase I SBIR Grant for Combustor Geometry Research Using 3D Printing, Simulation, and Product Development
Posted on August 15, 2019, by: Eric Miller
We are pleased to announce that the US Army has awarded PADT a Phase I SBIR Grant to explore novel geometries for combustor cooling holes. This is our 15th SBIR/STTR win.
We are excited about this win because it is a project that combines Additive Manufacturing, CFD and Thermal Simulation, and Design in one project. And to make it even better, the work is being done in conjunction with our largest customer, Honeywell Aerospace.
We look forward to getting started on this first phase where we will explore options and then applying for a larger Phase II grant to conduct more thorough simulation then build and test the options we uncover in this phase.
If you have any needs to explore new solutions or new geometries using Additive Manufacturing or applying advanced simulation to drive new and unique designs, please contact us at 480.813.4884 or firstname.lastname@example.org.
PADT Awarded U.S. Army Phase I SBIR Grant for Combustor Geometry Research Using 3D Printing, Simulation, and Product Development
The Project Involves the Development of Sand-Plugging Resistant Metallic Combustor Liners
TEMPE, Ariz., August 15, 2019 ─ In recognition of its continued excellence and expertise in 3D printing, simulation, and product development, PADT announced today it has been awarded a $107,750 U.S. Army Phase I Small Business Innovation Research (SBIR) grant. With the support of Honeywell Aerospace, PADT’s research will focus on the development of gas turbine engine combustor liners that are resistant to being clogged with sand. The purpose of this research is to reduce downtime and improve the readiness of the U.S. Army’s critical helicopters operating in remote locations where dirt and sand can enter their engines.
“PADT has supported advanced research in a wide variety of fields which have centered around various applications of our services,” said Eric Miller, co-founder and principal, PADT. “We’re especially proud of this award because it requires the use of our three main areas of expertise, 3D printing, simulation and product development. Our team is uniquely capable of combining these three disciplines to develop a novel solution to a problem that impacts the readiness of our armed forces.”
The challenge PADT will be solving is when helicopters are exposed to environments with high concentrations of dust, they can accumulate micro-particles in the engine that clog the metal liner of the engine’s combustor. Combustors are where fuel is burned to produce heat that powers the gas turbine engine. To cool the combustor, thousands of small holes are drilled in the wall, or liner, and cooling air is forced through them. If these holes become blocked, the combustor overheats and can be damaged. Blockage can only be remedied by taking the engine apart to replace the combustor. These repairs cause long-term downtime and significantly reduce readiness of the Army’s fleets.
PADT will design various cooling hole geometries and simulate how susceptible they are to clogging using advanced computational fluid dynamics (CFD) simulation tools. Once the most-promising designs have been identified through simulation, sample coupons will be metal 3D printed and sent to a test facility to verify their effectiveness. Additionally, PADT will experiment with ceramic coating processes on the test coupons to determine the best way to thermally protect the 3D printed geometries.
“When we developed new shapes for holes in the past, we had no way to make them using traditional manufacturing,” said Sina Ghods, principal investigator, PADT. “The application of metal additive manufacturing gives PADT an opportunity to create shapes we could never consider to solve a complex challenge for the U.S. Army. It also gives us a chance to demonstrate the innovation and growth of the 3D printing industry and its applications for harsh, real-world environments.”
Honeywell joined PADT to support this research because it is well aligned with the company’s Gas Turbine Engine products. The outcome of this research has the potential to significantly improve the performance of the company’s engines operating in regions with high dust concentrations.
This will be PADT’s 15th SBIR/Small Business Technology Transfer (STTR) award since the company was founded in 1994. In August 2018, the company, in partnership with Arizona State University, was awarded a $127,000 STTR Phase I Grant from NASA to accelerate biomimicry research, the study of 3D printing objects that resemble strong and light structures found in nature such as honeycombs or bamboo.
To learn more about PADT and its advanced capabilities, please visit www.padtinc.com.
About Phoenix Analysis and Design Technologies
Phoenix Analysis and Design Technologies, Inc. (PADT) is an engineering product and services company that focuses on helping customers who develop physical products by providing Numerical Simulation, Product Development, and 3D Printing solutions. PADT’s worldwide reputation for technical excellence and experienced staff is based on its proven record of building long-term win-win partnerships with vendors and customers. Since its establishment in 1994, companies have relied on PADT because “We Make Innovation Work.” With over 80 employees, PADT services customers from its headquarters at the Arizona State University Research Park in Tempe, Arizona, and from offices in Torrance, California, Littleton, Colorado, Albuquerque, New Mexico, Austin, Texas, and Murray, Utah, as well as through staff members located around the country. More information on PADT can be found at www.PADTINC.com.
# # #
Posted on July 12, 2019, by: Ted Harris
Ten years is a long time in the life of a software product. While ANSYS itself has been around since the early 1970’s and what is now known as ANSYS Mechanical is approaching 20 years old, the user interface for ANSYS Mechanical maintained the same look and feel from version 12.0 in 2009 through version 2019 R1 in 2019. That’s 10 years. Certainly, there were many, many enhancements over that 10 year period, but the look and feel of the Mechanical window remained the same.
With the release of version 2019 R2, the Mechanical user interface has changed to a more modern ‘ribbon’ window, as shown in the red region here:
After having used the new interface for a while, here are 5 takeaways that are hopefully useful:
- It’s easy to use. Sure, it’s different but the overall process is the same with a simulation tree on the left, details to enter and adjust at lower left, graphics in the middle, message, and graphs at the bottom, and the main menus across the top.
- ANSYS, Inc. has helped by providing a 12-slide (some animated) usage tips guide which pops up automatically when you launch ANSYS Mechanical 2019 R2.
- As in the old menu, the ‘Context’ menu changes based on what you have clicked on in the tree. For example, if you have clicked on the Mesh branch, the Context menu will display meshing controls across the top of the window.
- As intuitive as the new ribbon interface is, there are some functionalities that you may have trouble finding. Not to worry, though, as there is a new Search field at upper right that will likely take you to the right place. Here I am interested in making a section plane for plotting purposes. My first thought was that it would appear in the Display menu. When I didn’t find it there, I simply typed in ‘section’ in the search field and the first hit was the right one.
After clicking “Take me there”:
And the resulting section plot:
- Some capabilities show up in the File menu other than the expected Save and Save As functionality. For example, Solve Process Settings is now in the File menu. However, the main functionality is in the Solution context menu, such as using Distributed solutions and specifying the number of cores.
In short, the 2019 R2 improvements to ANSYS Mechanical allow for easier and faster setup of our simulations. If you haven’t given it a try, we encourage you to do so.
Posted on July 8, 2019, by: Robert McCathren
In a previous life, I worked in the maritime and offshore energy industries and used ANSYS as part of my daily routine in structural design. I eventually discovered myself in a position where I was designing subsea equipment for use in offshore oil and gas fields. One thing I quickly discovered was that although subsea structures tend to be fairly simplistic looking (think playground equipment…but 10000 feet underwater) there are multiple design factors that can easily cause a domino effect that would require redesign(s). Whether it was a change brought upon by the client, tool manufacturer, or to satisfy the whims of marine warranty companies, there was always a need to evaluate multiple variants of any subsea structure.
Sounds like a very reactive process, right? So how can we bring this process into a more streamlined analysis workflow within ANSYS? Just use parameters with SpaceClaim and ANSYS Mechanical!
So what can parameters do to aid in this process?
- Remove repetitive tasks
- Account for geometric changes to CAD models
- Use a range of values for material properties
- Create associative connections between CAD models and ANSYS results
- Allow for automatic goal driven design exploration
Now let’s look at some common use cases for parameters that I’ve run into in the past:
Accelerations for Onboard Equipment and Cargo
Cargo transported on the ocean is subject to the same accelerations that affect the vessel transporting it (surge, sway, heave, pitch, roll, and yaw). These accelerations are then combined into three representative accelerations and applied in multiple loadcases.
Typically, these loadcases are resolved in independent analysis systems but we can remove all that fluff with a simple parameter driven analysis. All one has to do is tag inputs and result items as parameters and then input values for each load case (or Design Point). In this case I have selected the XYZ components of an acceleration input applied to a mass point as well as the total deformation and maximum equivalent stress. With the push of a button ANSYS will then solve all of these design points and will amend the table to show the selected results corresponding with each design point. Results from the Design Points can be uploaded individually but this parametric analysis has made it very easy for us to determine which Design Points / load cases have the greatest influence on the design.
Geometry Influence Study
So one of the questions often asked during the design process is “Will the design work after we change this dimension to compensate for X?” which is often followed by a discussion on robustness (which is then followed by a change order). So let’s skip the discussion middle-man and move to be proactive by using parameters to quantify just how much we can change our geometry before a problem arises.
Here we have an example subsea Pipeline End Termination (PLET) structure and let’s say a client has asked us to verify if this design can work for various pipeline sizes. The PLET has some major parts that can be influenced by this change: The pipeline clamp, cradle, flanges, ball valve, and bulkhead.
Because we can use parameters there’s no need to make a new model. Merely tag items you wish to create parameters for in SpaceClaim:
Then ANSYS Workbench will start to populate its parameter tables accordingly:
We can then make certain parameters dependent on others, or define them via simple expressions. In this way we can enforce clearances and relations between the various bodies in our model.
From here all we have to do is define our variables for our future analyses:
Then tell ANSYS to solve all the design points with a single click. Note that users can create charts and tables before the solve and ANSYS will populate these live during the solution process. Individual design point results and geometries can also be reviewed at any time.
For this particular analysis we provided the same load to each Design Point but a good next step would be to set a goal driven analysis and have a range of loadings on the pipeline end of the PLET to represent various installation conditions.
Parameters are a very powerful tool within the ANSYS toolbox. They can remove repetitive tasks within FEA, easily create loadcases, and address concerns about design robustness by letting ANSYS and SpaceClaim handle CAD model rework.
That’s it for this blog post! I’ll be creating a few offshore industry-specific posts in the future as well so stay tuned!
Posted on May 22, 2019, by: Eric Miller
ANSYS Mechanical is a very powerful tool right out of the box. Long gone are the days when an FEA tool was just a solver, and users had to write code to create input files and interpret the results. Most of the time you never have to write anything to effectively use ANSYS Mechanical. But, users can realize significant gains in productivity and access greater functionality through customization. And it is easy to do.
Before we talk about the four options, we need to remember how the tool, ANSYS Mechanical, is actually structured. The interface that users interact with is a version of ANSYS Workbench called ANSYS Mechanical. The interface allows users to connect to geometry, build and modify their model, set up their solution, submit a solve, and review results. The solve itself is done in ANSYS Mechanical APDL. This is the original ANSYS Multiphysics program.
When you press the solve button ANSYS Mechanical writes out commands in the languages used by ANSYS Mechanical APDL, called the ANSYS Parametric Design Language, or APDL. Yes, that is where ANSYS Mechanical APDL got its name. We like to call it MAPDL for short. (Side note: years ago we started a campaign to call it map-dul. It didn't work.) Once the file is written, MAPDL is started, the file is read in, the solve happens, and all of the requested output files are written. Then ANSYS Mechanical reads those files and shows results to the user.
Customization Tool 1: Command Snippets for Controlling the Solver
Not every capability that is found in ANSYS Mechanical APDL is exposed in the interface for ANSYS Mechanical. That is not a problem because users can use the APDL language in ANSYS Mechanical to access the full capability of the solver. These small pieces of code are called Snippets and they are added to the tree for your ANSYS Mechanical model. When the solver file is written, ANSYS Mechanical inserts your snippets into the command stream. Simple and elegant.
PADT has a seminar from back in 2011 that lays it all out. You can find the PowerPoint Presentation here. We do have plans to update this webinar soon.
This approach is used when you want to access capabilities in the solver that are not supported in the interface but you want to get to those features and keep track of them from inside your ANSYS Mechanical Model.
If you are not familiar with APDL, find a more “seasoned” user to help you. Or you can teach yourself APDL programming with PADT’s Guide to APDL .
Customization Tool 2: ANSYS Customization Toolkit (ACT) for Controlling the User Interface and Accessing the Model
As mentioned above, ANSYS Mechanical is used to define the model and review results. The ANSYS Customization Toolkit (ACT) is how users customize the user interface, automate tasks in the interface, add tools to the interface, and access the model database. This type of customization can be as simple as a new feature, presented as an app, or it can be used to create a focused tool to streamline a certain type of simulation – what we call a vertical application.
Unlike APDL, ACT does is not have its own language. It uses Python and is a collection of Application Programmer Interface (API) calls from Python. This is a very powerful toolset that increases in capability at every release. PADT has written stand alone applications using ACT to reduce simulation time significantly. We have also written features and apps for ourselves and users that make everyday use of ANSYS Mechanical better.
Do note that ACT is supported in most of the major ANSYS products and more capability is being added across the available programs over time, not just in ANSYS Mechanical. You can also use ACT to connect ANSYS Mechanical to in-house or 3rd party software.
Because this is a standard environment, you can share your ACT applications on the ANSYS App Store found here. Take a look and you can see what users have done with ACT across the ANSYS Product suite, including ANSYS Mechanical. PADT has two in the library, one for adding a PID controller to your model and the other is a tool for saving your ANSYS Mechanical APDL database.
Another great aspect of ACT is that it is fully documented. If you go to the Customization Suite documentation in the ANSYS help library you can find everything you need.
Customization Tool 3: APDL for Automating the Solve
With Code Snippets we talked about using APDL to access solver functions from ANSYS Mechanical that were not supported in ANSYS Mechanical. You can also use APDL to automate what is going on during the solve. Every capability in the ANSYS solver is accessible through APDL.
The most common usage of APDL is to create a tool that solves in batch mode. APDL programs are used to carry out tasks without going back to ANSYS Mechanical. As an example, maybe you want to solve a load step, save some information from the solve, export it, read it in to a 3rd party program, modify it, modify some property in your model, then solve the next load step. You can do all of that with APDL in batch mode.
This is not for the faint of heart, you are getting into complex programming with a custom language. But if you take the time, it can be very powerful. All of the commands are documented in the ANSYS Mechanical APDL help and details on the language are in the ANSYS Parametric Design Language Guide. The PADT Blog is full of articles going back over a decade on using APDL in this way.
Customization Tool 4: User Programable Features in the Solver
One of the most powerful capabilities in the ANSYS Mechanical ADPL solver is the ability for end-users to add their own subroutines. These User Programable Features, or UPF’s, allow you to create your own elements, make custom material models, customize loads, or customize contact behavior.
There are other general purpose FEA tools on the market that heavily publicize their user elements and user materials and they try to use it to differentiate themselves from ANSYS. However, ANSYS Mechanical APDL has always had this capability. Many universities and companies add new capability to ANSYS using this method.
To learn more about how to do create your own custom version of ANSYS, consult the Programer’s Reference in the ANSYS Help. PADT also has a webinar sharing how to make a custom material here.
The key to successful customization ANSYS is to know your options, understand what you really want to do, and to use the wide range of tools you have available. Everything is documented in the help and this blog has some great examples. Start small with a simple project and work your way up.
Or, you can leverage PADT’s expertise and contract with PADT to do your customization. This is what a half-dozen companies large and small have done over the years. We understand ANSYS, we get engineering, and we know how to program. A perfect combination.
Regardless of how you customize ANSYS Mechanical, you will find it a rewording experience. Greater functionality and more efficient usage are only a few lines of custom code away.
Posted on March 12, 2019, by: Joe Woodward
So you have results for a job that took several hours to run, or several days, and now you realize that you need to use a post-processing command snippet. In the past, prior to version 14.5, this would be a huge problem, because just adding the command snippet in the Solution branch would trigger a resolve. So, in those cases, we would usually just jump over to MAPDL to do the post-processing. In version 14.5, however, ANSYS allowed you to add the snippet to the Solution branch without triggering a resolve.
When you hit “Evaluate All Results”, Mechanical will copy the files to a scratch directory and start a separate MAPDL session. This leads to a secondary problem. Often you need to select nodes or elements to use during your snippet. This is usually done with a Named Selection, or a material ID that you saved to a parameter in a Geometry command snippet. The problem is that the Named Selections, or components in MAPDL, are not saved in the RST file, neither are parameters. They are stored in the DB file. If you thought ahead, then in the Analysis Settings, you set the ‘Save DB file’ option to ‘Yes’ before you solved. In your post-processing command snippet you could then use the RESUME command to bring the database back to the state that it was just before the solve – having all your Named Selections and parameters. But since the default is to not save the DB file, odds are that you don’t have it. It’s okay, though. There are still some options.
The first thing I recommend is that you save the solved project, and then do a ‘Save As’ to make a copy from which to work, just in case something goes wrong.
When you hit the Solve button in Mechanical, it writes out a ‘ds.dat’ file that then gets run in a batch MAPDL run.
If you have all of your needed Named Selections setup prior to the Solve, then you can open an MAPDL session and use the File>Read Input From... command to read in the ds.dat file. In interactive mode, the file stops just before the Solve command, so you can then save the database file at that point. You then need to right-click on the Solution branch in Mechanical and hit “Open Solution Directory”, in to which you need to copy the new “file.db” file. Then you can resume the file.db in your post-processing command snippet.
If you need to add a new Named Selection, you can add a new one, even in 14.5, without triggering a resolve, but then you will have to write out a new input file. To do this, highlight the Solution branch in the tree, go to Tools>Write Input File…, and then follow the procedure above.
If you are using version 17.1 or later, you have another option. You can Right-click on a Name Selection and choose “Create a Nodal Named Selection”. Then right-click that new nodal named selection and hit “Export Selections to CDB File”. You can select several Nodal Named Selections to export, and the export will all go to one file. Include that text in your snippet.
In R19.2, the Named Selections are now stored in the RST file. If you don’t need to add a new Named Selection, then can you access the Named Selections that were created prior to the solution run. After a SET command in your snippet, you can just use the name in the NSEL command, as I did in the picture above, with no need to include the CMBLOCK from the CDB file. If you need a new Named Selection, however, then you have to use Methods 1 or 2 above.
Now that all sounds somewhat difficult, and it actually gets worse. With Method 1, you have to know at least enough MAPDL to open it and read in the input file, and then save the database file.
With Method 2 and 3, the parameters are still not saved in the RST file. So if you need parameters that were created in earlier command snippets, then you have to go back to Method 1.
But there’s hope!!
Method 4: Oh, Joy!!!
There is one other thing that you can do, and this is my favorite method. (Probably because I wrote it. J) There is now a new free ACT extension in the ANSYS App store. It is called SAVE_DB, and was written because yours truly got tired of dealing with the other three methods above. SAVE_DB allows you to save the MAPDL database file without having to solve the Mechanical model, or cause a resolve. SAVE_DB will automatically change the Analysis Settings > Analysis Data Management > Save MAPDL DB value to "Yes" so that future resolves are also saved. MAPDL will be run in the background on the same version as the Workbench project, and the “file.db” will be saved to the Solver Files Directory. Now any new Named Selections that you add will be ready at the push of a button. This one:
This is the first of many helpful tools planned for a PADT_Toolkit. I will post another plug, I mean ‘blog’, when I get more tools added and the PADT_Toolkit uploaded to the APP Store. Until then enjoy SAVE_DB!
Posted on February 5, 2019, by: Ziad Melhem
Over time Ziad Melham, one of PADT's support engineers, has developed a variety of tips and tricks for ANSYS Mechanical that he shares with users when providing them with support. In this video, Ziad shares that same information with all users.
Users of ANSYS mechanical, both new and experienced, will find them helpful in making their simulation pre- and post-processing more efficient. Please enjoy and do not hesitate to share with your co-workers.
Posted on January 28, 2019, by: Alex Grishin
Fasteners are one of the most common and fundamental engineering components we encounter
With recent increases in computational power and ease in creating and solving finite element models, engineers are increasingly tempted to simulate their fasteners or fastened joints in order to gain better insights into such concerns as thread stresses
In what follows, PADT’s Alex Grishin digs deeper into how to leverage ANSYS Mechanical to better model fasteners and obtain accurate results. If you did not review Part 1, do so here.
Posted on December 4, 2018, by: Ted Harris
One of the great new features in ANSYS Mechanical 19.2 is the ability to perform a lattice optimization. Accomplished as an option within Topology Optimization, lattice optimization allows us to generate a lattice structure within our region of interest. It includes varying thickness of the lattice members as part of the optimization.
Lattice structures can be very beneficial because weight can be substantially reduced compared to solid parts made using traditional manufacturing methods. Further, recent advances in additive manufacturing enable the creation of lattice structures in ways that weren’t possible with traditional manufacturing.
Here I’ll explain how to perform a lattice optimization in ANSYS 19.2 step by step.
The procedure starts the same as a normal topology optimization in ANSYS Mechanical, with an initial static structural analysis on our original part or assembly. If you’re not familiar with the process, this earlier PADT Focus blog should be helpful: http://www.padtinc.com/blog/the-focus/topological-optimization-in-ansys-18-1-motorcycle-component-example
For the lattice optimization, I’m starting with a part I created that acts as a corner brace:
At this early point in the simulation, the Project Schematic looks like this:
I used the Multizone mesh method to get a hex mesh on the part:
Simple loads and constraints are recommended especially if you’ll be doing a downstream validation study. That is because the downstream simulation on the resulting lattice geometry will most likely need to operate on the FE entities rather than geometric entities for load and constraint application. The boundary conditions in this simple model consisted of a fixed support on one side of the brace and a force load on the other side:
After solving, I reviewed the displacement as well as the stress results:
Satisfied with the results, the next step is to add a Topology Optimization block in the Project Schematic. The easiest way to do this is to right click on the Solution cell, then select Transfer Data to New > Topology Optimization:
You may need to re-solve the static structural simulation at this point. You’ll know if you have yellow thunderbolts in the Project Schematic instead of green checkmarks for the Static Structural analysis.
At this point, the Project Schematic now looks like this:
The Mechanical window now has the Topology Optimization branch added:
The change to make to enable a lattice optimization is accomplished in the details view of the Optimization Region branch:
We then need to specify some settings for the lattice. The first of these is the Lattice Type. The various types are documented in the ANSYS 19.2 Help. In my example I selected the Crossed option.
The other properties to define are:
- Minimum Density (to avoid lattice structures that are toothin. Allowed bounds are 0 and 1)
- Maximum Density (elements are considered full/solid fordensities higher than this value, allowed bounds are 0 and 1)
- Lattice Cell Size (used in downstream geometry steps andadditive manufacturing)
Values I used in my example are shown here:
Assuming no other options need to be set, we solve the lattice optimization and review the results. The results are displayed as a contour plot with values between zero and one, with values corresponding to the density settings as specified above.
Note that at this stage we don’t actually visualize the lattice structure – just a contour plot of where the lattice can be in the structure. Where density values are higher than the maximum density specified, the geometry will end up being solid. The lattice structure can exist where the results are between the minimum and maximum density values specified, with a varying thickness of lattice members corresponding to higher and lower densities.
The next step is to bring the lattice density information into SpaceClaim and generate actual lattice geometry. This is done by adding a free standing Geometry block in the Workbench Project Schematic.
The next step is to drag and drop the Results cell from the Topology Optimization block onto the Geometry cell of the new free standing Geometry block:
The Project Schematic will now look like this:
Notice the Results cell in the Topology Optimization branch now has a yellow lightning bolt. The next step is to right click on that Results cell and Update. The Project Schematic will now look like this:
Before we can open SpaceClaim, we next need to right click on the Geometry cell in the downstream Geometry block and Update that as well:
After both Updates, the Project Schematic will now look like this:
The next step is to double click or right click on the now-updated Geometry cell to open SpaceClaim. Note that both the original geometry and a faceted version of the geometry will exist in SpaceClaim:
It may seem counter intuitive, but we actually suppress the faceted geometry and only work with the original, solid geometry for the faceted process. The faceted geometry should be automatically suppressed, as shown by the null symbol, ø, in the SpaceClaim tree. At this point it will be helpful to hide the faceted geometry by unchecking its box in the tree:
Next we’ll utilize some capability in the Facets menu in SpaceClaim to create the lattice geometry, using the lattice distribution calculated by the lattice optimization. Click on the Facets tab, then click on the Shell button:
Set the Infill option to be Basic:
At this point there should be a check box for “Use Density Attributes” below the word Shape. This check box doesn’t always appear. If it’s not there, first try clicking on the actual geometry object in the tree:
In one instance I had to go to %appdata%\Ansys and rename the v192 folder to v192.old to reset Workbench preferences and launch Workbench again. That may have been ‘pilot error’ on my part as I was learning the process.
The next step is to check the Use density attributes box. The Shape dropdown should be set to Lattices. Once the Use density attributes box is checked, we can then one of the predefined lattice shapes, which will be used for downstream simulation and 3D printing. The shape picked needs to match the lattice shape previously picked in the topology optimization.
In my case I selected the Cube Lattice with Side Diagonal Supports, which corresponds to the Crossed selection I made in the upsteam lattice optimization. Note that a planar preview of this is displayed inside the geometry:
The next step is to click the green checkmark to have SpaceClaim create the lattice geometry based on the lattice distribution calculated by the lattice optimization:
When SpaceClaim is done with the lattice geometry generation, you should be able to see a ghosted image showing the lattice structure in the part’s interior:
Note that if you change views, etc., in SpaceClaim, you may then see the exterior surfaces of the part, but rest assured the lattice structure remains in the interior.
Your next step may need to be a validation. To do this, we create a standalone Static Structural analysis block on the Project Schematic:
Next we drag and drop the Geometry cell from the faceted geometry block we just created onto the Geometry cell of the newly created Static Structural block:
We can now open Mechanical for the new Static Structural analysis. Note that the geometry that comes into Mechanical in this manner will have a single face for the exterior, and a single face for the exterior. To verify that the lattice structure is actually in the geometry, I recommend creating a section plane so we can view the interior of the geometry:
To mesh the lattice structure, I’ve found that inserting a Mesh Method and setting it to the Tetrahedrons/Patch Independent option has worked for getting a reasonable mesh. Care must be taken with element sizes or a very large mesh will be created. My example mesh has about 500,000 nodes. This is a section view, showing the mesh of the interior lattice structure (relatively coarse for the example).
For boundary condition application, I used Direct FE loads. I used a lasso pick after aligned the view properly to select the nodes needed for the displacement and then the force loads, and created Named Selections for each of those nodal selections for easy load application.
Here are a couple of results plots showing a section view with the lattice in the interior (deflection followed by max principal stress):
Here is a variant on the lattice specifications, in which the variance in the thickness of the lattice members (a result of the optimization) is more evident:
Clearly, a lot more could be done with the geometry in SpaceClaim before a validation step or 3D printing. However, hopefully this step by step guide is helpful with the basic process for performing a lattice optimization in ANSYS Mechanical and SpaceClaim 19.2.