Often there is a need to export the deformed geometry from Ansys Mechanical. Possibly to a 3D printer to show to customers, or maybe a new CAD geometry file is needed that can be used for drawings or further design evaluation. Ansys Mechanical offers two options for users for doing this task.

Exporting STL (Standard Tessellation Language) files from the deformed results is one option. The STL file may be opened within Ansys Discovery and reverse engineered to create deformed solid geometry from the STL facets.

I have posted a YouTube video that demonstrates this technique. In the video, I have a rubber cushion that is compressed between two metal plates as shown. The rubber geometry gets deformed and the goal here is to export the deformed faceted geometry and create smooth solid geometry from that.

Ansys Mechanical can also export a deformed geometry in a proprietary PMDB (Part Manager Database) format which can be opened up within Ansys Discovery and modified further, or it can simply be opened up within Mechanical for further analysis.

I have also posted a YouTube video that shows how to work with this PMDB file format. In this video, we transfer the deformed geometry shown above from a previously solved FEA and then link its Solution cell to the Model cell of a new Static Structural block.

Many companies use Ansys to reduce chance of injury and death when an accident occurs such as the overturning of a tractor or the rear impact crash of a car into the back of a trailer. An effective method to minimize danger to vehicle occupants during an accident is to ensure that that the structure absorbs sufficient energy through plastic deformation during the accident impact.

Many vehicles have Roll Over Protection Systems (ROPS) to reduce injury to operators. Figure 1 shows a Bobcat skid steer loader including its ROPS, which is the black cage structure surrounding the driver.

Manufacturers in the earth-moving and agricultural equipment industries design ROPS structures in accordance with the standards ISO 3471 and SAE J2194, respectively. These standards specify physical tests involving sequential pushes in the lateral, vertical, and longitudinal directions while ensuring that the structure absorbs sufficient energy through plastic deformation in each push direction. In addition, there are limitations on the structure deformation to ensure that the structure does not infringe on the volume occupied by the operator, referred to as the Deflection Limited Volume (DLV).

A cost-effective ROPS design approach is to use engineering simulation to design a vehicle to meet energy absorption and deformation requirements. This type of engineering simulation is difficult, however, and many finite element products are not able to accurately calculate the energy absorption during the tests. The challenges are that the finite element code must be able to represent a nonlinear stress strain curve that extends far into the plastic range; quickly and reliably converge as the structure experiences large deformation, plastic strain, and nonlinear contact; and accurately calculate energy absorption. Ansys Mechanical is very well suited for this type of simulation.

The tractor-trailer industry relies on rear impact guards to absorb energy when a car runs into the back of a trailer. Figure 2 shows the rear impact a Chevrolet Malibu crashing into the rear impact guard of a trailer.

DRD recently teamed up with Wilson Trailer of Sioux City, IA to use Ansys Mechanical for design of trailer rear impact guards. Wilson Trailer uses a test method from the Transport Canada Motor Vehicle Safety called Test Method 223. Test Method 223 requires 5-inch displacement loads to be applied at 3 locations of the rear impact guard as shown in Figure 3 and then removed, and the guard must absorb at least 20,000 Joules energy for each load application.

When we simulate a ROPS test or a rear impact guard test in Ansys, we must accurately track the energy absorption as illustrated in Figure 4, which is a component of Test Method 223.

The Ansys Workbench graphical user interface does not have a built-in button to calculate the absorbed strain energy, however, it’s very easy to perform this calculation using a commands object. Figure 5 shows the content of a commands object to calculate absorbed energy and where it belongs in the model tree.

Note that for convenience the commands object calculates the strain energy in two systems of units, lbf-in and Joules, and stores the values into parameters that start with the character string “my_”. When the commands object has been executed Ansys will display all parameters and their values for parameter names starting with “my_” in the commands object details window as shown in Figure 6.

Occasionally it may be a requirement to report average values of stress or strain from an ANSYS Mechanical analysis. There are tricks to do this either for a group of nodes/elements on a face or elements within a specific volume.

Depending on the requirement, the goal may be to simply report either :

– “Average” stresses on a face (based on nodes)
– “Average” stresses on a face (based on elements)
– “Average” stresses on a volume (based on elements)

Technique 1 : Reporting weighted area average nodal stress

This can be done by implementing the macro in a command object as shown. The weighted area average nodal stress on the surface is reported under the details of the command (in the red circle below) with the parameter named “my_ave_stress1”.

The contents of the command object can be downloaded here.

Note: The surface chosen to do the averaging is defined as named selection ‘Face_01’ (used in the macro). In this technique the weighted averaging is done by calculating area apportioned to the nodes, and multiplied with the corresponding stress values for those nodes, and then summed up, and then we divide that sum by total area of nodes.

Technique 2 : Reporting weighted volume or area average element stress

DRD recommends doing element averaging that is weighted based on volume. This can be done with a command object (shown below) and you can download it here.

If the goal is to use the element area to do the averaging, then there is a technique for this as well. This method is written for 3d solid elements belonging to the ANSYS 18x series solid elements such as : 185 (dropped midside node bricks), 186 (20 node bricks), 187 (10 node tets).

In this technique, you define the surface using a named selection (Face_01). You will additionally create a remote point referenced to that named selection. This is a clever trick, since in a solid 3d mesh, it is not directly possible to know the area of the element face easily. By creating a remote point, we are creating contact/target elements which are then tagged to the solid elements overlaid on that surface, and the area of contacts gives us the area of the solid element faces which can then be used for the element averaging.

This can be done by implementing the command object as shown. The content of the command object can be downloaded here.

The weighted area average element stress on the surface is reported under the details of the command as shown with the parameter named “My_average_elemstress_face”.

Note: If you are running a SOLID 185, 186 or 187, you need to specify that in the command snippet as highlighted below.  In this technique, the weighted averaging is done by calculating area of the elements, multiplied with the corresponding stress values for those elements, summed up, and then we divide that sum by total area of elements.

DRD recommends you test these techniques on a simple part first before attempting on a larger model, and be sure to do the necessary sanity checks to ensure results are accurate.

Boundaries in Ansys Fluent can be broken into two groups: external boundaries and internal boundaries.  External boundaries appear on the outer boundary of meshed regions (inlets, outlets, interfaces, etc.), while internal boundaries exist within a conformal mesh (interiors, porous-jumps, fans, etc.).  Notably, internal boundaries can exist inside a single cell zone, or can even separate different cell zones as long as the mesh is conformal across the boundary. There is one boundary type that can be used as either an external or internal boundary: walls.

While external walls are straight forward, internal walls are a bit more complex. Internal walls are sometimes called coupled walls or two-sided walls because they are formed by a pair of wall boundaries that are by default coupled together. You most often see coupled walls separating fluid and solid cell zones, but they can also be used as infinitely thin baffles with fluid on both sides.  Each coupled wall pair shows up in the boundary list as a zone and its shadow: one for each side of the wall.  When the coupled wall is between two different cell zones, it is easy to determine which side faces which cell zone as the adjacent cell zone is listed in the boundary condition window.

It is possible for a two-sided wall to exist between a single cell zone. When this occurs, the above reference to the “adjacent cell zone” is no longer useful to determine which side of the wall faces a particular direction. In these instances, it is possible to plot the face area in the direction most aligned with the boundary’s normal direction. The face area vector points from the adjacent cell into the wall (this is opposite of face normal direction). Note that you must initialize the solution to be able to generate the necessary contour plot.

In the below example, the “X Face Area” is plotted on the wall-baffle-shadow zone. The plot shows that the area is largely negative, which implies that this wall faces the +X direction. While this may initially seem backwards, keep in mind that the face area points from the adjacent cell towards the wall. This is backwards of the outward facing normal direction.

Hopefully this article sheds some light on wall/wall-shadow pairs. If you require further assistance with this topic, please contact us at support@drd.com.

When setting up rotating machinery in Fluent, users will specify a rotating cell zone with the appropriate angular velocity. The bounds of this domain must be surfaces of revolution for either the frame motion or sliding mesh approaches. This article focuses on the finer details of setting up such a case. Particularly, what needs to be done for walls on the boundary of a rotating zone that should not be rotating? Additionally, sometimes a rotating shaft will exist both within a rotating zone and also within an adjacent stationary zone, how should this be handled? This article will answer these questions.

As an example, consider a case where a fan is placed within a circular duct. It is held in place via the motor and motor mounts. The domain will be split into rotating and stationary zones about halfway along the shaft that connects the fan and motor assembly.

The setup of the rotating zone itself is straightforward. For this analysis, the frame motion approach will be used.  In the Cell Zone Conditions Panel, the “Frame Motion” box will be checked and the appropriate rotation axis, rotation axis direction, and rotational velocity will be set.

In Fluent, all walls are stationary relative to their adjacent cell zone. This means walls within or on a rotating zone are rotating with that zone. Similarly all walls within or on a stationary zone are stationary. Consider the two images below. The duct in the rotating cell zone should not be rotating with the fan. Conversely, the motor shaft that extends into the stationary zone should be rotating, while the cell zone should be stationary. These conditions need to be applied at the boundary level for these two walls.

The small section of shaft in the stationary zone will be treated similarly, but will instead have the same angular velocity as the rotating zone. In this model the small section of shaft in the stationary zone likely does not change the result much, but this will not always be the case.

One very important aspect of applying wall velocities as done for both the duct and the shaft is that no velocity can be applied normal to the wall. In the case of cylindrical walls, only rotational velocity around the axis of the cylinder is allowed.

Porous media is widely used in CFD to reduce the computational expense of modeling things like filters, perforated plates, and tube banks. To accomplish this reduction in computational expense, the losses across the porous device are modeled mathematically using a simple equation rather than by geometrically resolving the flow obstruction.

Using the porous media model requires knowledge of the loss coefficients. These are referred to as the viscous and inertial loss coefficients. These coefficients can be derived from experimental data, empirical correlations in literature, or through CFD. The CFD models used to determine these coefficients are small sections of the full device, which makes the computational expense relatively small.

The pressure loss through a porous domain is represented by the following equation:

The unit cell model will be run at several flow rates and the pressure drop across the model will be recorded. The velocity vs pressure drop curve formed by this data will be curve fit to the form:

Coefficients a and b will then solved for using:

Knowing that the pressure loss will always follow a parabolic curve as described above, any tuning that is perceived to be needed means that the curve fit must be altered. Similarly, if experimental testing reveals that the pressure drop vs velocity curve follows any shape other than a parabola with a y-intercept of zero, then the porous loss model cannot represent this loss accurately across, though a curve fit could potentially be done for some limited range of velocities.

Reflecting on my Time at DRD Technology

Since I had exposure to DRD Technology at previous companies, I now have a seasoned view as a customer and as a team member of DRD Technology. Over the past 15 years, in roles including Senior Applications Engineer and now Chief Technologist, I have had the opportunity to work on some incredible projects.

First, since Ansys is a company that is constantly innovating, a large part of my job is to keep up with the latest developments and evaluate them for our team. When I see a new tool that could be useful, I evaluate it thoroughly to ensure it meets our needs and can integrate smoothly into our workflow. One focus area for me has been on a tool called HFSS, which has become a cornerstone of our company’s offerings, and my role has continued to evolve as I work to identify new Ansys technologies that enhance our company’s offerings.

In general, my role is 80 percent pre-sales work and 20 percent supporting technical questions and conducting training courses periodically. Pre-sales allows me the opportunity to work closely with the sales team in the early stages to understand the client’s needs and requirements, and then develop a solution that would meet those needs.

Over the years, I have worked on many different projects. One of the most memorable was a pre-sales project for uAvionix four years ago. uAvionix is a company that builds innovative products for aircraft many of which have integrated RF antennas and my project was to simulate one of their products as “proof-of-concept” effort. When I presented the results to the client, the output from HFSS and measured scope trace results on the same graph were practically identical! I was completely amazed at the accuracy of the simulation in this case. Most numerical simulations are good if they fall within 10 percent of measured data, but this HFSS solution was within <1% of the measured data. That was the first time I ever experienced a predictive physics simulation being that “predictive.” This specific project has always been stuck in my mind; it was quite amazing.

Today, most CAD program providers include an embedded option for conducting simulation. This option is appealing to many companies as their engineers can expand how they use the tools they already have available for low or no additional cost. For many companies, their existing CAD licenses provide a low-barrier-to-entry way to test drive simulation. As a company gets started with simulation, or if their simulation requirements will remain fairly simplistic, a CAD-embedded tool can be a great option. However, since the simulation technology included by many CAD vendors was acquired as a means to complete their product offerings, oftentimes, the level of simulation available is limited in scope and size of model and may not be a great long-term solution. 

So how do you know when you are outgrowing the capabilities of your CAD-embedded tool? Some examples of questions to ask your simulation team to determine if a CAD-embedded or standalone product is the best option for your needs include the following: 

• What are the limits to your simulation?
• Do you have large assemblies?
• Do you require advanced or coupled physics?
• When it comes to simple physics, do you have lots of parts and/or a complex model?

For a more detailed review of a few examples and additional related issues,  DRD encourages you to read our whitepaper “Six Considerations for Selecting Engineering Simulation Software”.

(link the whitepaper title to the registration page on our website to download it – https://www.drd.com/resources/engineering-simulation-software-wp/)

Bring Your Own License (BYOL) is a feature of Ansys Cloud Direct which allows you to use on-premises licenses in place of Ansys Elastic Credits (AECs) for the software cost of a Cloud Direct job.

What does BYOL do?

Without BYOL, the software cost of a Cloud job is covered by AECs, consumed over time during the job to cover the licenses checkouts that would otherwise occur. The rate of AEC consumption is dependent on which licenses are required to perform the job – see the rate tables here: https://www.ansys.com/legal/terms-and-conditions/elastic-licensing-terms

In addition to the software cost, the hardware cost of the Cloud job can be covered by either AECs or AHCs, Ansys Hardware Credits. The only difference between AHCs and AECs are that AHCs can only be used to cover the hardware cost, so they cannot be used for the software portion. The hardware rates are the same for both but are dependent on region and requested hardware configuration (also listed in the link above). BYOL does not interact with the hardware cost of a Cloud job, so this article won’t go any deeper on the hardware costs of Ansys Cloud.

If you have any questions about the details of AEC purchasing or consumption rates, please contact sales@drd.com.

Why use BYOL? Who should be interested?

BYOL is most attractive to customers who already run Ansys locally on-site with licenses they own or lease, but want to access the power and flexibility of the hardware available with Ansys Cloud while still utilizing the licenses they have already purchased. This can substantially reduce overall AEC consumption by covering some or all of the software cost for a given Cloud job. The remaining cost will be for the hardware and any licenses not owned or available to bring to Cloud.

A common example would be existing users who want to tackle problems which are numerically larger than is feasible or possible with their on-site computing environment. However, this need might be periodic or intermittent and so a long-term investment in hardware is harder to justify, but the work still needs to be done. In this way, Cloud provides increased hardware capability on-demand – the concept of “bursting to the Cloud”. Since this user would be using their existing licenses were they to run locally (and is used to operating that way), it makes sense that they’d want to use those same licenses on Cloud rather than incurring some extra AEC cost. This is exactly what BYOL provides.

Consider this job: a solve on 1 full node (60 cores) from the HB configuration in the US East region, using a CFD Solver license (plus required HPC), and lasting 6 hours. Using the AEC consumption rates at the time of writing this article, the software cost will be 204 AEC and the hardware 21 AEC. That’s a cost of 225 AECs without BYOL, but only 21 AEC if the job can check out the appropriate CFD and HPC licenses through BYOL instead – a reduction of more than 90% in this case!

Some example AEC consumption rates at the time of writing this article: note how on average, the software rate is multiple times that of the hardware rate per node – meaning that BYOL can dramatically reduce AEC usage!

Be aware that since BYOL has Cloud check out licenses from the local license server, it alone does not provide extra licensing “bandwidth”. However, BYOL can be used in conjunction with using AECs to cover software costs (as the Cloud job will “rollover” to using AECs automatically if licenses are not available on the license server to cover Cloud’s requests).

Requirements of BYOL and network security implications

BYOL first requires 1.) owning or leasing Ansys licenses and 2.) having an Ansys Cloud subscription (along with some amount of AECs or AHCs). BYOL does not require any additional product to be purchased, any add-on to Cloud to be switched on, or any extra software to be installed. However, BYOL does come with some very specific network/security considerations, so it’s important to understand these. We will also present some possible examples of accommodating these needs, though the specific way that your company implements a solution may vary, dependent on network configuration and security policies.

The most important technical aspect of BYOL to recognize is that the Ansys hardware running on Cloud will be making its licensing requests to your license server. That is, network communication will be initiated from outside your network and will need to reach the computer where you host your Ansys licenses. For many organizations, this means that they will need to change their license server setup to accommodate BYOL, since letting a foreign computer connect to a machine within your secure network will never be palatable, even with IP/port forwarding mitigating some of the risk.

Note the incoming arrow pointing at the on-prem license server, coming from the “Batch Service” which represents all the remote Ansys Cloud components. The padlock represents the IP forwarding and firewall rules which ensure that the request from a known, static IP on Cloud can be forwarded to the license server. 

Understanding BYOL from a technical standpoint

For the best source of technical details of implementing BYOL (including how it functions with IP forwarding), please refer to the Ansys Cloud Guide, found here: https://cloud.ansys.com/pdf/help. (Access to this page requires an account with an active Cloud subscription.) The chapter “Bring Your Own License (BYOL)” near the end covers some background of how BYOL works as well as detailed instructions on setting it up and testing it.

Especially note the sections “Prerequisites for IP Forwarding” and “Ensure Firewall Access” for network configuration information.

Possible solutions to accommodate BYOL

With the fact that Cloud hardware will need to initiate a connection to your license server in mind, many customers may opt to change their licensing configuration to accommodate BYOL. One possible solution would to be move the license server itself to some cloud solution. Since the license server is no longer within your network, nothing there needs to change with regards to security. Users on-site can send outgoing license requests from their computers running Ansys to this Cloud license manager, as can the Ansys Cloud hardware. There is no proprietary data on this Cloud-hosted license server, as its sole purpose is to serve Ansys licenses, so it offers little to no risk if compromised.

Another possible solution would be to use a network DMZ. This has the benefit of having the license server be a machine on-site, still managed by like other owned systems, but “compartmentalized” to a degree from a network/security standpoint.

DRD support engineers are not experts on network security, and we don’t offer any services to configure or manage customers’ networks for them. However, we’re more than happy to work with the group that handles network security for our customers, filling them in on the technical details of Ansys Cloud and BYOL specifically as needed.

A common technique in distributing ducted flow involves thin guiding vanes or baffles.  One of the biggest hurdles to modeling baffles is how thin they are relative to the rest of the model.  If you were to model their true thickness, you typically have a choice between poor quality skewed elements or an excessively high mesh count.  Instead, thin baffles are often approximated as infinitely thin.  

When using Fluent Meshing, the addition of surface bodies in SpaceClaim to represent each baffle is perhaps the quickest approach to adding in baffle geometry. In some cases it is also possible to split up the fluid volume to account for these baffles, but generation of non-manifold geometry is not a viable approach, so this is typically more challenging than the surface body approach.

It is also important to consider inflation on zero thickness baffles. If one was to resolve the actual thickness of a baffle, inflation could wrap around the baffle without issue, but this is not the case for a zero thickness baffle. Instead, inflation will be forced to stair-step wherever the baffle ends in the middle of the fluid volume. These stair-stepped elements are of poor quality and will negatively affect the convergence behavior of the solution.

To prevent stair-stepping, inflation must be allowed to wrap fully around an object, or extend to an external boundary. To accomplish this for the case of zero thickness baffles, additional surfaces must be added to the geometry. Inflation layers can be grown on surfaces that allow flow to pass through them. It would be typical to consider these as “meshing surfaces” as their only purpose in the model is to aid in mesh quality by preventing stair-stepping of inflation layers.

In the case of turning vanes in a duct as pictured in this article, it makes sense to create extensions to the turning vanes that terminate at the inlet and outlet. Note that these additional surfaces must be separate faces from the actual vanes themselves. This is so that the meshing surfaces can be set to interior type boundaries in the solver. This will allow flow to pass through the meshing surfaces unobstructed.

To achieve continuous inflation using these new meshing surfaces, there are two approaches in Fluent Meshing. First, you can intentionally set the meshing surfaces to the wall boundary type in the Update Boundaries task. This will allow you to grow inflation using the default Add Boundary Layers control. When choosing this option it is important to set the meshing surfaces to “Interior” type boundaries once inside the solver otherwise flow will not be able to pass through these surfaces. The second option while meshing is to set the meshing surfaces to “internal” boundaries in the Update Boundaries task. This will then require that you manually scope your boundary layers for these surfaces, but avoids the need to change the boundary type later in the solver. Note that the terminology for a conformal boundary that allows flow to pass through it is different for the mesher and the solver. In the mesher this is “internal” and in the solver this is “Interior.”

Regardless of approach, the final mesh should have no stair-stepping of inflation as shown below. 

If in your final model you have no need for multiple cell zones, then you can merge the multiple cell zones together inside of the solver. To do so, go to the Domain Tab > Combine > Merge and select the relevant cell zones. This will remove the workflow information from the case file, so be sure that you have saved the .msh.h5 file separately before performing this operation.