The size of computational fluid dynamics (CFD) models are increasing exponentially as manufacturers recognize the value of detailed transient flow data for temperature, flow resistance and other critical product data. However, one engineer told FieldView Product Manager Matt Godo that he was only able to post-process 1% of his CFD data because of the volume of information and the available time to interpret it. Herein lies the mission driving the developers at Intelligent Light in Rutherford, NJ.
Intelligent Light has been providing products and services for CFD analysts for 27 years. FieldView 13 is the culmination of five years of development--based on customer feedback as well as internal experience from its consulting organization. The release was guided by the following four principles:
1. Revolutionize CFD data management.
2. Provide unprecedented speed and performance.
3. Enable higher productivity sessions and workflows.
4. Don’t require existing users to significantly adapt or adjust the way they have been working.
The FieldView 13 user interface, now unified for all platforms (Windows, Linux
Setting New Standards
FieldView 13 contains a new graphics processing engine. It uses a many-core, multi-CPU design leveraging GPU acceleration for parallel rendering, multi-threading and hardware optimization to take advantage of all available cores. This release raises the bar for CFD data processing and the benefits scale with the power of the local or client system. The bigger and better the machine, the faster and more powerful the improvements in data visualization and analysis--with interactive operations running at least 20 times faster than the previous release of FieldView.
By default, FieldView displays high-quality renderings of overlapping transparent objects, with anti-aliasing at interactive frames rates. FieldView is designed to deliver the best performance on systems with the latest and most up-to-date graphics cards. It can also be configured to run on systems with more modest graphics resources. High quality rendering extends to batch or automated operation--images generated interactively or in batch are pixel-matched.
A direct numerical simulation of a liquid fuel jet with 6 billion gridpoints is
conducted to elucidate the multi-scale, turbulent physics of liquid fuel spray
atomization. (FieldView image courtesy of Dr. Matsuo, Japan Aerospace
Exploration Agency, or JAXA.)
Another new feature that improves post-processing speed, contributing to better interactive experiences for users, is Sweep Caching. When a user completes a streamline or particle path animation or a transient surface sweep, the post-processing objects for each step are stored in memory. Subsequent animations are played from memory for greatly increased frame rates. Free of the limitations of a movie, users can zoom, rotate and/or translate the dataset as it animates.
Breaking Down Barriers
Graphics processing speed can provide incredible improvements in efficiency, but it doesn’t address one of the critical problems facing analysts as datasets increase. With high-performance computing (HPC) clusters and the anticipation of cloud computing, engineers are no longer solving their large, problematic models on their local computer, which is often a laptop in mobile, global design environments. Traditional CFD post-processing requires that results sets in the double-digit gigabyte or even terabyte range be copied across networks before the data can be viewed.
“Our current high-water mark is a transient model covering thousands of time steps, where each step contains over 2 billion cells,” says Godo. “Even larger and more ambitious modeling efforts will be presented before the end of the year, fully relying on features delivered with FieldView 13.”
FieldView 13 addresses this by using reduced representations of the results of interest called Extract Database, or XDB, files. Users can create compact subsets of all the results data of interest on the server system so that a minimal amount of data gets pulled over the network for processing. The XDB file can be as much as 100 times smaller than the raw results dataset. Even if the raw data exceeds physical or realistic transfer or FTP limits, the XDB file will be portable. Then, once the dataset has been opened, it can be animated, sliced, probed and manipulated--with no loss in numerical accuracy, but at greatly enhanced speeds.
High-resolution CFD simulation of V-22 Osprey rotor. Post-processed with
FieldView on dual-CPU/8-core workstation. Multi-grid OVERFLOW simulation
contains 14k grids. 668M grid points. (FieldView 13 image used with permission:
Chaderjian, N. M. and Buning, P.G., “High Resolution Navier-Stokes Simulation
of Rotor Wakes.” Proceedings of the American Helicopter Society 67th Annual
Forum, Virginia Beach, VA. May 3-5, 2011.)
A single XDB file can be created for an entire model, or one can be made for each component or domain in a model. Separate, identically structured XDB files can be created for each step in a parameter sweep, or each time step in a transient analysis. These multiple XDB files can be processed simultaneously in FieldView 13 so that animations or plots across them can be generated. XDB files can also be created using different time steps in a transient model, so that fewer images of slower-moving segments of an event are captured, but resolution on the critical segments can be retained.
XDB files can also be created using batch operations that work remotely on the server, so that the analyst is freed up to work on other tasks. FieldView 13 calls this True Batch Processing. In addition to the productivity enhancements, True Batch also enhances data security. The database never leaves the server on which it was created, and the file system isn’t manually accessed (with all the risk that entails). The automation tools in FieldView 13 come into play here.
Improving Productivity with Automation
The breakthrough in CFD data management through batch creation of XDB files was built on existing automation methodologies in FieldView. The most basic automation option is Restarts. A Restart stores the information needed by FieldView to recreate an image or plot composed by a user when it is saved.
Moving up one level of complexity, FieldView 13 has implemented a scripting capability to automate simple repetitive tasks. At the top of the automation hierarchy is FieldView FVX, a natural language programming tool that provides access to most of the functions within FieldView. The developers at Intelligent Light recognized that users didn’t need to learn new or abbreviated syntax, so the calls within FVX capture words that are used in the FieldView graphical user interface. FVX can also be used to run existing Restarts or Scripts as the basis for more advanced automation.
Godo confirms that the significant gains in performance and productivity were achieved without disrupting the familiar environment and workflows in prior versions of FieldView. Version 13 is 100% backward compatible, he says, including scripts. DE
Unsteady Flow over Bicycle Wheel
The power of FieldView 13 is best understood in the context of an actual case study. The bicycle racing wheel market is extremely competitive, with manufacturers banking up to $500,000 in development, including simulation and wind tunnel testing, for incremental improvements in stability, aerodynamics and performance (Source: NYvelocity.com, “Zipp Lead Engineer Josh Poertner,” Aug. 27, 2009). The importance of CFD is growing rapidly for this industry--along with the sizes of the models being solved.
One manufacturer examines multiple geometry iterations each week for aerodynamic performance, using a transient solution to capture unstable loads a high-performance rider might experience. Using a 32-core, parallel processing HPC cluster, the raw results file size is 2.8GB per time step. Simulations with up to several hundred time steps are common.
An FVX script was developed to batch process results on the HPC using only eight cores while running four jobs concurrently. The script created Microsoft Excel-compatible files of the time-dependent forces and XDB files of the various components in the assembly, such as the wheel, fork and frame. The total XDB file size was about 60MB per step, which equates to a 46:1 reduction in processed file size for results visualization and analysis.
Furthermore, it took less time to read and animate the XDB files for all components across all time steps than it took to simply call a single time step’s results, using standard interactive visualization in the CFD solver’s native post-processor.
Vince Adams, an account manager for LMS, is a simulation educator, consultant and speaker. He has authored three books on FEA and numerous magazine articles. Contact him via email@example.com.