Clarke on Coding
What's all this one-way coupling stuff, anyhow?
By Jerry A. Clarke, Scientific Visualization Team Lead
Using the right tool for the job–or more specifically the right code for the job–is critical to getting the right results. So when Dr. Reed Skaggs and his research team, who are investigating landmine effects on vehicle structures, recently heard that we are collaborating on a Common High Performance Computing Software (CHSSI) Portfolio Project called, “An Interdisciplinary Computing Environment for Weapon-Target Interaction,” they thought the ARL MSRC might have some codes and tools to make their jobs easier.
One of the codes in this portfolio, Zapotec, is from the Sandia National Laboratory in Albuquerque, N.M.; the code is a two-way coupling between the 3-D Eulerian shock physics code CTH and the finite element code Pronto3D.
 |
| Coupled calculation of landmine interacting with vehicle hull. |
In particular, they were trying to determine the damage/effects of landmine blasts on various proposed vehicle structures. Now, while CTH is well-suited for simulating the blast, another finite element code, LS-Dyna, is better suited for simulating their vehicle structure.
Additionally, the nature of the problem, as with many blast-structure interaction problems, really didn’t require a two-way coupling of the codes. That is: While the blast has a significant effect on the deformation of the structure, the deformation of the structure has minimal effect on the blast.
In the past, this type of coupling has been accomplished by roughly approximating the finite element structure in CTH, and using CTH “tracer points” to collect a pressure-time history at those points. This table of times and pressures is then used as input to LS-Dyna. The main problem with this approach is that the structure is only a rough approximation, and the placement of tracer points can be a laborious, error-prone effort.
When your primary tool is a hammer, everything starts to look like a nail. So the computer scientist in us saw this problem as one particularly well-suited for a scripting-based set of tools. Specifically, the Python interface to the eXtensible Data Model and Format (XDMF) was used with some computational geometry tools from the visualization toolkit (vtk) to produce a semi-automated method for producing the proper LS-Dyna input loaded with the pressure-time histories derived from CTH. Python allowed us to glue together basic pieces of functionality to produce a somewhat complex system.
The first step in the process is to convert the shell elements of the finite element model into XDMF, which allows our pre-existing tools to operate on the dataset.
Next, we make the shell elements thicker to create hexahedral elements. Using the XDMF-ExodusII converter, these hexahedral elements are written out in a format that CTH can use for material insertion. In addition, the controlling Python script also writes out a CTH input file that defines the explosive, and CTH is then run and post-processed in the normal fashion. The CTH-XDMF converter is a parallel tool that reads CTH output and produces XDMF datasets. While this data is normally used for visualization, in this case, it’s used as input to the next stage in the computational pipeline.
Using a filter from vtk, the structured CTH data is sampled at the cell centers of the original finite-element mesh. This procedure is repeated for every iteration of CTH so that the result is a list of pressures for each shell over the duration of the calculation. These results are formatted by the Python script and written out as LS-Dyna input.
Finally, LS-Dyna is run as normal, and the output from LS-Dyna is converted to XDMF for final visualization. Since the data from CTH and LS-Dyna are written out at different intervals in simulation time, we must be very careful when visualizing the results simultaneously.
We’ve found that viewing the CTH data as alpha-blended point clouds and as finite-element shells results in a poor man’s volume visualization that can be manipulated at interactive rates. Viewed in stereo on our RAVE II system, or in our Augmented Virtuality Center, it provides an impressive presentation of results.
As with any process, there are still some kinks to work out. For example, sampling the pressures directly on the surface of the structure results in oscillating values.
To alleviate this problem, we exploded the finite element structure slightly, moving each shell element in the direction of its normal vector. This allows the sampling to be accomplished just off of the surface, which eliminates the oscillation.
But all these details will eventually be transparent to the user, as software developers like to say. What that means is that while the one-way coupling of these types of problems can be automated somewhat, it still requires a bit of tweaking to get the proper result.
Of course, by having these tools and the ability to glue them together, we’re still better off, even though it might not be perfect. In this case, since we’re primarily interested in functionality, as opposed to raw speed of the entire, complex system, the Python scripting language was definitely the right tool for the job.