Part 3: Semi-Comprehensive CFD Software
Semi-Comprehensive CFD Software – A Review of Top Contenders
In our original post, we defined the highest-performing CFD software class as “Comprehensive”. The following is our not-so-scientific list of criteria we used for classifying software packages as “Comprehensive” or not.
The capability to import complex 3d solid and surface geometries from diverse sources
An all-in-one workflow, including pre-processing, simulation and post-processing
Broad multi-physics simulation capabilities
Efficient data architectures, numerical methods and utilization of diverse hardware and software configurations
Vendor initiated verification and validation of physics and numerical methods
Limited requirements for user-coding and/or command line operations
In this section, we’re discussing software packages that strive to be comprehensive, multi-physics tools but, in our opinion, fall just a little short in some respect. There are many available CFD software packages that could be described as semi-comprehensive, and we couldn’t possibly review them all and still get any real work done. So here, we are focusing on three software packages in this category based on their large user base and/or their potential to become comprehensive: COMSOL Multiphysics, CONVERGE CFD, and Numeca OMNIS. Some of the other software packages in this semi-comprehensive category that we would have liked to review if we had more time include Altair AcuSolve, Flow Science FLOW-3D, MSC SC/Tetra, and SimScale.
All three of the tools discussed here have the potential to be extremely valuable in the right context.
Example #1: COMSOL Multiphysics
COMSOL was established in July, 1986 with a headquarters in Stockholm, Sweden. The founders were former doctoral students of professor Germund Dahlquist at KTH and originally partnered with US based Mathworks as a European distributor of MATLAB. During this period COMSOL developed its own software known as FEMLAB that expanded the capabilities of MATLAB in solving partial differential equations. At first, FEMLAB was dependent upon MATLAB engines, but by the time the two companies parted ways in 2004, COMSOL had developed their own finite-element based meshing and solving routines. As with MATLAB, the software was considered a platform with additionally available toolbox components built for creating and executing simulations in various physics domains. Early successes were primarily with universities and research labs, including close cooperation with Chalmers and Stanford among others.
In 2005 FEMLAB became known as COMSOL Multiphysics (COMSOL). Utilizing a graphical user interface (GUI) combined with a “MATLAB like” programming interface, researchers could customize an analysis utilizing the FEMLAB tools to solve their specific physics application in multi-dimensions as never before. COMSOL very neatly filled the gap between MATLAB’s lack of spatial discretization sophistication and the more widely available GUI based, spatial solvers, such as ANSYS, that lacked an easy-to-use programmatic interface allowing application of general solution routines to researcher specific differential equations and boundary conditions.
Although recently marketed as a general-purpose engineering tool, COMSOL has traditionally been used more by researchers than by engineers. COMSOL, though, has been working to change this, attempting to thread the needle between increasing ease-of-use for engineers without alienating their historically research-oriented user base.
Basic Interface & Workflow
COMSOL Multiphysics 5.4 Graphical User Interface
Lucky for you, at Resolved Analytics we are all about doing the hard work so you don’t have to. Let’s get started with a look at the COMSOL interface and workflow. The COMSOL recommended first step is to use the “model wizard” option to specify the nature of the multi-physics problem that you wish to simulate, such as whether the problem is 2-D or 3-D in nature, what physics will be included, and whether the problem is steady-state or time-dependent. After completing this step, the user enters the “model builder” portion of the workflow.
As with most multiphysics simulation software, geometry is first either created or imported. The COMSOL GUI includes a set of computer-assisted design (CAD) tools for geometry modeling in 1-D, 2-D, and 3-D, but in most engineering cases, it is more efficient to import surface files from existing 3D solid models or create new geometry using the more sophisticated tools available in your company’s 3D solid modeling software of choice. The model explorer on the left-hand side of the “model builder” window displays the menu items that will be subsequently used to define simulation parameters, boundary conditions, and so on.
COMSOL Multiphysics V5.4 Product Suite
Physics Modeling Capabilities
COMSOL adopted and remains committed to the MATLAB model whereby the licensee purchases the platform and additional “toolboxes”, or modules, as needed to fit their project requirements. These toolboxes contain what you’ll need to setup and execute your domain-specific problems. Originally consisting of chemical engineering, electromagnetics and structural mechanics modules, the list has now grown to over 40 as shown in the latest product suite chart below. Within the CFD module, COMSOL offers a variety of multiphase models including the level-set method for free surface interface tracking, a Eulerian-Eulerian dispersed phase model, and a Lagrangian particle tracking model. Fluid structure interaction is possible using either one-way or two-way coupled procedures. All types of flow rheology can be simulated including Newtonian, viscoelastic and other non-Newtonian behavior, as well as flow within porous media. There are also a number of turbulence wall models and turbulence subgrid-scale models available, including the recently added v2-f turbulence wall model. The reader should keep in mind that although all of these physics capabilities can be combined, their combination may require modules purchased separately at substantial additional cost.
CAD Cleanup and Meshing
New users will find a preference for creating geometries from scratch using the geometry creation tool in most of the COMSOL workflow documentation. This is not surprising given its legacy as a MATLAB add-on. The COMSOL geometry creation tool is one of the best-in-the-class. However, such a workflow is simply not aligned with the fast-paced world of product engineering where 3D solid models of significant complexity preexist in most cases. COMSOL has adapted to this reality with the incorporation of CAD Import and LiveLink Modules.
In the base package, only STL files are importable. Purchase of the CAD Import module extends the import capability to include SAT, STEP and IGES file formats, as well as native Inventor, NX, Pro/E and Solidworks parts or assemblies. The LiveLink for CAD module further expands the interoperability of native 3D solid model and the simulation environment, including parameter pass-through which can be especially useful in optimization studies.
COMSOL Tetrahedral Mesh with Prism Elements in Boundary Layer of Ahmed Body Problem
COMSOL has implemented several useful geometry modification tools. First and foremost, individual solids and other features specified in the 3D solid model file can be preserved on import which simplifies model setup. Other useful features include being able to create a 3D solid body from an imported point or surface mesh, Boolean operations amongst imported bodies, surface cleanup and repair tools, and automatic contact pair definitions.
Meshing is accomplished through one of two workflows: physics-controlled or user-controlled meshing. 3D elements that can be specified for either of the workflows include tetrahedron, hexahedrons, pyramids or prisms, with the default being tetrahedrons. Where multiple regions are present, each can be meshed individually with conformal node interfacing driven by the size definitions of the region defined first in the meshing sequence. We created the predominantly tetrahedral mesh with prism elements in the boundary layer shown in the figure below without much difficulty. Implementing a refined mesh in the wake region, or aligning quadrilateral elements with the primary flow direction, proved to be more difficult, requiring additionally partitioned CAD regions.
Simulating
Whenever one uses the finite element method to produce a numerical approximation to the solution of a partial differential equation, the method requires the assumption of the piecewise linear shape function defining how the solution varies between the spatially discretized nodes. Higher accuracy approximations of solutions can be obtained through combinations of higher-order shape functions or by increasing the density of node placements, with both incurring their own computational costs. It has been argued for linear static problems that increasing the order of the shape functions is more efficient than increasing the number of nodes. It has also been argued that the order of the governing equation can be used as the basis for the order of the shape function assumed.
Problematically, though, the non-linearities of the Navier-Stokes equations governing fluid flow lead to numerical instability if higher-order elements are assumed. In this case, only linear elements can be used in combination with artificial dissipate\ion added through a variety of methods to maintain stability. For multiphysics problem including fluid flow, then, the first-order discretization of the fluid flow field justifies using first-order elements throughout the model. The same can be said of problems combining heat transfer in solids with solid mechanics. The requirements for a high node-density using linear shape functions is a significant drawback of the finite element model in multiphysics simulations, as memory requirements quickly become a limiting factor on solution accuracy. Further, domain decomposition-based parallelization of simulations will not demonstrate a linearly scaling reduction in solution times with increasing processing power, as they do for finite volume methods. These numerical inefficiencies are among the reasons why the most prevalent CFD codes are based on the finite volume method instead and why, in our estimation, COMSOL falls short of the comprehensive software categorization.
Post-Processing
COMSOL Streamline and Surface Contour Plot
Post-processing in COMSOL is highly customizable, but at the cost of efficiency and accessibility. The methods used for obtaining surface contour plots and streamline plots are relatively straightforward and painless, though the resulting graphics lack the impact factor of some of the other leading CFD packages or dedicated post-processing packages. In the example below, we started with the marine vessel previously introduced in Figure 1 and were solving only the hull drag moving through the wall with a slip-wall condition at the free surface. Ideally, we would have benefitted from a more elegant visualization that included the marine vessel as a transparent object layered over the flow visualization, but it was not possible to combine the visualization of the surface file (the input) with the visualization of the result in the solution domain (the meshed volume corresponding to the subtract of the surface file from a region corresponding to the liquid). Color tables and heading controls were also limited and tedious. Such impasses are trivial with respect to the performance that the model is predicting, but still, visualization is an incredibly important part of the engineering process.
Another aspect of post-processing in COMSOL that we weren’t fond of was the reliance on creating expressions to perform routine calculations. For example, to check that mass, momentum and energy were being conserved in our simulation we were required to create derived values specifying the surface or volumetric integration of COMSOL internal variables, thusly requiring knowledge of the program language variable expressions. Another example is the calculation of the drag and corrections for angle of attack, both requiring time consuming user-interactions. Other leading software packages have made such common fluid dynamics quantities of interest more easily accessible as direct outputs.
Licensing and Cost
At last check, a node-locked, perpetual COMSOL license could be purchased for around $10,000. To maintain this license annually with support and the latest software updates will cost an added 20% ($2,000). The CFD module can be purchased for an additional $10,000 and 20% maintenance. A fluid-structure interaction problem combining fluid flow analysis and linear structural mechanics would add $15,000 to the capital spend and $3,000 to the annual spend. The module based pricing makes COMSOL quite expensive to firms with diverse physics requirements and makes the most sense for organizations repetitively solving problems of limited combinations of physics. Parallelization is included on a node-locked license on as many processors as are available on the compute node, hyperthreading is not supported, but offers only inconsistent gains across physics problems and platforms.
Summary
COMSOL has an impressive library of physics modeling capabilities, although the module based pricing can get expensive. COMSOL is both easy to learn and to use. However, when it comes to fluid dynamics, the inefficiency of a finite element method solver was felt in a number of test cases investigated. Although, that might not be a make or break for everyone, especially if time is not an issue, for power users it should definitely be a concern.
Example #2: CONVERGE CFD
Here is a fun one. Convergent Science is a relative newcomer that has been building a platform around solid CFD fundamentals and a few innovations while maintaining a focus on quality and accuracy. The company was founded by a group of graduate students at the University of Wisconsin to provide solutions to several challenges associated with simulating internal combustion engines. The company sold its first CFD license in 2008. With a heavy focus on the automotive industry, the company has developed intellectual property related to spray injection, combustion and fluid-structure interaction simulations. This focus has allowed the company to quietly but quickly grow, and the company now claims its software is used by most US, European and Asian automotive companies and engine manufacturers. The company is targeting continued growth through expansion into industries with similar challenges and attributes, including most specifically the gas turbine industry.
So, let’s find out what CONVERGE CFD is all about, shall we.
Since We’re Talking Automotive – Lets Talk About What’s Under the Hood
At its core, CONVERGE CFD is not so different than many of the other software packages we’ve discussed so far as well as the comprehensive packages that will be discussed in the final installment of the series. Like many of the others, CONVERGE CFD employs a central-differenced, finite-volume based scheme for integrating the discretized conservation equations and successive over-relaxation or biconjugate gradient methods for solving the resulting linear matrices.
Where CONVERGE first differentiates itself from most legacy packages is through its implementation of an automated meshing algorithm that occurs at run time and optional mesh refinement operations that occur during the simulation. This Adaptive Mesh Refinement (AMR) process adds local refinement in areas of steep field variable gradients and is now also being pursued by many of the other leading CFD software OEMs. The company calls the process “autonomous meshing” and argues the following benefits:
By eliminating the process of manual mesh creation, inspection and refinement, time is saved
Accuracy is improved through higher grid density where it is needed and where manual meshing strategies might not allocate it
AMR provides a robust method for capturing large or rapid boundary motions
AMR provides run-time savings due to using an optimized number of computational cells
Consistency and standardization can be achieved through the use of a consistent, algorithmic strategy for mesh production.
Additional differentiators, according to the company, are its high-fidelity spray models, detailed chemistry solvers and reaction set integrations, NOx emissions modeling, and its inclusion of a genetic algorithm parameter optimization routine.
Physics Modeling Capabilities
CONVERGE CFD owns an impressive resumé of physics modeling capabilities, especially for a software that is only a little over 10 years old. Capabilities include all the standard fare such as steady-state or transient simulations, incompressible or compressible flows, passive scalar transport, RANS, URANS, DES and LES turbulence modeling, porous media and sources and sinks. Advanced capabilities were initially focused on internal combustion engine simulations, including Lagrangian multiphase with vaporization and breakup models, spray injector models, wall film models, Urea injection and NOx emissions modeling, a chemical kinetics solver, premixed and non-premixed combustion models, surface chemistry models, radiation, and conjugate heat transfer. More recently, a volume-of-fluid (VOF) method for Eulerian multi-phase has been added as well as Eulerian-to-Lagrangian phase transition models. In addition to these capabilities, other recent enhancements include the addition of the multiple reference frame approach (MRF) and fluid-structure interaction (FSI) modeling improvements.Basic Interface & Workflow
Basic Interface & Workflow
CONVERGE CFD User Interface During Setup of a Mixing Tank CFD Simulation
While meshing may be “autonomous”, pre-processing is not. CONVERGE Studio, a pre-processing software included with a standard CONVERGE license, is used to prepare a simulation, including all of the typical processes like geometry preparation, boundary and initial condition specification, continuum definitions, etc.. CONVERGE Studio is setup like many other pre-processors with various windows for interacting with the model and categorized menus (docks) for accessing workflows and commands.
My overall impression is that while functional, the user interface seems a bit crowded, is not the most aesthetically pleasing, and does only an average job at guiding the user through the case setup process. In-turn, these attributes provide for a rigid user experience. CONVERGE Studio feels a bit like an improved version of the pro-STAR and GAMBIT tools of the late 2000s before CD-Adapco and ANSYS went in other directions with their replacements, STAR-CCM+ and Workbench. A few areas in which I see room for improvement are visualizations, organization, user interactions with menu windows, and a greater variety of output capabilities. For us, not having the option to run a meshing sequence and to visualize the output in the pre-processor prior to submitting a simulation is a big deal. That functionality is very useful regardless of whether one is using AMR or not. Currently, one needs to run a time step, albeit without solving the hydrodynamics, and then convert the output file before viewing the mesh in a 3rd party software. Because this is a frequent operation for us, that is a time-consuming workflow that we’d rather avoid. CONVERGE Studio is due a makeover in the next few years, especially given the company’s recent growth and success. At the time of this post, recent job postings on LinkedIn for C++ programmers were hinting that it may already be underway.
CAD Cleanup
Pre-processing starts with importing a geometry surface (.stl) file of the boundaries of the fluid and/or solid domains to be modeled. I’ve found working with .stl files frustrating as they more frequently suffer from boundary edge, surface intersection, and flipped normals errors which require either manual repair or re-export at higher tessellation densities. We imagine this will change in the future as current trends are towards 3D solid file types, such as Parasolids (.x_b, .x_t), due to their superiority and CFD software demand for high quality geometries.
Next, boundary surfaces are “flagged” so that they can be assigned the correct physics for simulation. Per the .stl format, a boundary surface is a composition of neighboring surface triangles. Instead of having to pick each of these surface triangles individually to flag the boundary, CONVERGE Studio provides some additional methods to “fence” individual boundaries and automatically flag all the triangles within the “fence” as belonging to a boundary. Imported surfaces can be translated, rotated or scaled.
Unfortunately, if you plan to tackle assemblies or parts with fine geometric details, you are going to run into surface triangle errors that must be fixed before proceeding. Though CONVERGE Studio provides the standard tools for performing such repair (detection, deletion, stitching, patching, renormalization, etc.), the whole process of manual repair makes me want to switch professions, regardless of the software being used. Honestly, I just can’t stomach the wasted time. I prefer working with 3D solids. In that case, CFD detected geometry errors are due to 3D solid modeling errors, not to faulty surface triangle definitions during export, and can be cured in the native 3D solid model prior to export/import. Trust me when I say that this is a much faster workflow for complex, multi-part assemblies. (Note: Convergent Science has let us know that the forthcoming major release of CONVERGE Studio 3.0 will provide a direct CAD geometry import option via integration of Spatial’s API.)
Case Setup
At this point the user can transition into setting up the simulation conditions via the “Case Setup” menu. This menu provides a step-wise progression through specifying the type of simulation, continua, boundary conditions, motions, physics models, grid controls and output controls. In complete contrast to the dumbed-down simulation specifications available in the CAD-embedded tools discussed previously, case setup in CONVERGE Studio feels like it goes too far in the opposite direction. Serious expert knowledge is required to make judicious choices on many of the input steps during the process. I believe CONVERGE could benefit from simplification whereby some of the more technical or challenging parameter or model selections are hidden, defaulting to best practices and leaving expert controls only accessible through additional menu items.
Boundary condition specifications are typical with both Dirichlet and Neumann conditions available for inlet and outlet boundary types, as well as wall, symmetry, periodic and interface boundary types. For wall boundaries, the boundary can be stationary, translating, rotating, or determined via Fluid-Structure Interaction and Newton’s laws. A second option is specifying a moving boundary whereby the mesh will be recalculated, compliant with the boundary motion, at each time step in a transient simulation. With physical model selections and initial conditions specified, the final step in case setup is the mesh definition. A base mesh size (in 3 dimensions) is defined and must be consistent across regions. CONVERGE CFD will then utilize, at run time, a cut-cell Cartesian method to create a boundary-fitted mesh of mostly hexagonal mesh cells with arbitrary-sided polyhedrals near boundary surfaces.
Figure 6: Large Eddy Simulation With Adaptive Mesh Refinement (Courtesy Convergent Science)
Three additional mesh operations are also available: mesh scaling, mesh embedding, and the previously mentioned AMR. The mesh scaling operation does exactly what it sounds like- either scaling up or down the cell density of the base mesh. The embedding option allows you to specify surfaces or volumes on which to refine the base mesh and can be defined on a per region basis. The most interesting option is the AMR method in which the user specifies the criteria for refinement and the frequency at which refinements are made during the simulation. All meshing options, as well as the other simulation parameters specified in the case setup, can be adjusted during the simulation through editing of a text file containing the case setup. CONVERGE has recently provided the example case below showing the result of a Large Eddy Simulation (LES) using adaptive meshing. The reader should note the higher concentrations of mesh elements in regions with high gradients of the scalar being tracked.
A prism cell option for finer scale resolution in the normal direction to surfaces would be a welcome additional meshing option that is not currently available. (Note: Convergent Science has let us know that the forthcoming major release of CONVERGE Studio 3.0 will include this capability).
Before simulating, the case setup files are validated, and errors or warnings are issued if critical setup data is missing.
Simulations
From my testing, it is obvious that CONVERGE CFD is a thoroughly tested and capable CFD solver with a wealth of sophisticated user controls. It is fully parallelizable with excellent scaling behavior across both Windows and Linux platforms. The solvers themselves seem relatively quick and stable. I believe it is likely that CONVERGE CFD has lower levels of numerical dissipation than other leading codes, making it more adaptable to higher-accuracy methods such as DES and LES and perhaps more accurate on routine RANS calculations, although I haven’t rigorously tested that theory. Serial execution can be initiated from within CONVERGE Studio or through the command line while parallel execution is only accessible through the command line.
Restarting from previous results seems to work well, and data output, even 3D field data output at discrete time steps, seems to be efficient. The only thing slowing down the solver in the test cases I ran was the method of generating meshes. Both the AMR procedure and the boundary motion method require that meshes be recalculated at periodic time steps. Though the process may be optimized behind the scenes through morphing or localized remeshing, the re-meshing process for the moving boundary problem I tested required a significant amount of the overall run time (~50%). This leads to the solution time lagging behind a comparable simulation performed using a different solver that utilizes the moving mesh / interface method. It should be noted, though, that Convergent Science argues that such moving mesh methods add excessive artificial dissipation, making their method more accurate, and that the high percentage of run time used for remeshing would be significantly less for lower triangle counts as are typical in the prevalent engine applications.
Post-Processing
Post-processing is the biggest deficiency holding CONVERGE CFD back from becoming an industry-leading comprehensive tool. Since 2018, CONVERGE CFD has come bundled with a license for “Tecplot for CONVERGE” that allows the use of Tecplot 360, a popular post-processing tool. A CONVERGE CFD simulation is run, and results files are created during and/or at the conclusion of the simulation. If the solution is to be interrogated at various times for time-dependent analyses, a full results file at each of those times will be needed. The results files are collected in a single folder, and a utility known as “post-convert” is then used to transform those results into the format used by Tecplot 360 or by other common post-processors filetypes such as FieldView or Paraview. Those results files are then imported into Tecplot 360.
As part of our standard workflow here at Resolved Analytics, we are actively interrogating our simulations as the solution progresses. During this real-time interrogation, we are looking at mesh characteristics and how they relate to fluctuating solution variables in both space and time (as a measure of both quality of the simulation and simulation convergence); we are adjusting and monitoring the calculations of quantities of interest such as flow uniformity indices, heat transfer coefficients, and torque or power outputs; we are calibrating simulation inputs as needed to improve the accuracy of the simulation; and we are testing for sensitivity to the full range of inputs. In CONVERGE CFD, some of our typical checks and balances can be managed through intelligent design of continuously written text-based output files and using the Studio line plotting application without much additional overhead. Anything associated with 3D field data, though, requires the process of file conversion and Tecplot processing, which is a time-consuming intermediate that is not necessary with those software packages that are fully integrated with 3D post-processing capabilities. Our demand for this type of interactive interrogation has much to do with our high turnover and the variety of simulations we are performing, and it is quite possibly that a user with hundreds of similar models to run would not be as dependent on such interrogation as we are. At the same time, though, we are inclined to believe that all simulation engineers would benefit from such interrogation to some degree.
CONVERGE CFD Simulation of Mixing Tank Using the Moving Boundary Method (by Resolved Analytics CFD Consulting)
The post-processing workflow is especially limiting in cases where you want to record an animation of a time-developing flow-related quantity. Take the following mixing tank animation, for example. The simulation spanned a real time of 10 seconds, corresponding to 300 degrees of rotation of the mixing impellers. The animation required 330 output files to be written for the surface data and the field variable of interest (a scalar) at every 0.03 seconds. The writing of these files, at around 30MB each for a 250k cell count simulation, required an additional 20% overhead on simulation time. The “post_convert” utility required an additional few minutes to process these files into corresponding Tecplot files, which were 43MB each, for a total storage requirement of 24 GB. The process took me about 30 minutes after the completion of the simulation. The reader can draw the obvious conclusions on how intensive this type of workflow will be for problems with millions of computational cells, longer simulated times, and multiple quantities of interest. Contrast these requirements with a “standard” method of creating such animations in software packages with built-in post-processing, exporting an image file at the prescribed frequency and then tying these together into an animation requiring 1-2 MB per image (depending upon desired image quality) and no additional computing time or post-processing time.
Licensing and Cost
CONVERGE CFD offers the typical licensing arrangements, including node locked local as well as on-demand cloud usage and floating licenses Convergent Science is pretty tightlipped about their pricing, but public information suggests that a single annual license runs around $20,000 and additional parallel core tokens around $1,000 each. This pricing is in line with the leading comprehensive packages. The on-demand hourly license cost of $10/hr is slightly less than competitors’ on-demand prices. CONVERGE CFD is available on leading cloud computing hosts such as Rescale, R-Systems and TotalCAE.
Summary
CONVERGE CFD has a ton of potential and currently falls short in only one of our 5 criteria for being labeled a “comprehensive CFD software package”. The only box it doesn’t check is on our requirement for a single user interface/platform for pre-processing and interactive simulation and results visualization. Given that it excels in so many of the difficult technology areas, we believe it is only a matter of time before it makes the leap.
Example #3: Numeca OMNIS
Numeca was founded in the early 1990’s by Professor Charles Hirsch as an offshoot of The Fluid Mechanic Department of Vrije Universiteit Brussel. Interestingly enough, Professor Hirsch wrote my graduate school text books on CFD—Numerical Computation of Internal and External Flows: Volumes 1 & 2, and if you want to learn more about Numeca from him, you can listen to this interview done by Robin Knowles of Talking CFD. Numeca was founded at a time when several multi-purpose/general CFD tools were already available, but it differentiated itself by allowing users to focus on specific CFD applications rather than being forced to use one of the all-purpose software packages available at the time. Each specialized package called FINE (for Flow Integrated Environment) used a specialized CFD solver along with pre and post-processing tools wrapped inside a GUI and included varieties such as a structured solver FINE/Turbo (for internal turbomachinery apps), a specific solver FINE/Marine (dedicated to problems including free surface, mesh adaption and automatic refinement, and degrees of freedom), an unstructured solver FINE/Open (general industrial applications), and FINE/Acoustics, among others.
However, in late 2017, Numeca released a multi-purpose CFD package of its own called OMNIS, seeking to appeal to a wider range of users from tinkerers and designers to product and process engineers to Ph.D. level CFD gurus and superusers. OMNIS was created with the goal of providing the user a more streamlined approach to tackling a wider range of CFD problems ranging from quick-running, front-end analysis where accuracy may be less important than speed/computational time to highly complex, high-fidelity models that can take weeks of CPU-time spread across multiple cores in the cloud.
So, just what is OMNIS? Numeca touts it as an “environment:” a single GUI that allows for pre-processing and meshing, solving via any of the FINE solvers (now including a Lattice-Boltzmann solver), and post-processing (as well as co-processing which we’ll touch on a bit later). Let’s take a deeper look.
Basic Interface & Workflow
OMNIS Workflow Widget and Pie Control Panel
In general, the workflow for getting an analysis up and running within OMNIS is straightforward and intuitive, even for beginners without much training. The user interface features a file tree on the left, a properties window that pops up based on the file tree selection, and the main graphics window in the center. At the bottom-center of the graphics window, a very helpful “navigation” tool/ work-flow widget displays the current stage/view of the project as well as the previous and future steps that must be marched through in order to run a study. The navigation widget is shown below and includes each step in a nice sequential fashion - Geometry, Domain, Mesh, Simulation, and Results. Just above the navigation workflow, a pie control panel shows available features/options that can be useful. The options in the pie control panel change depending on the active workflow step.
OMNIS User Interface and Flow Visualization
As the analyst steps through each stage of the progression, the geometry, mesh, etc. can be set up as needed, and you can jump back a step or two if something needs adjusting or if a setting was forgotten without losing any settings. Below, I’ll touch on each step briefly.
Geometry
The first step is to import the geometry for the analysis. We used Parasolid format for our testing, but it should be noted that native CAD package compatibility is included for software such as SOLIDWORKS and CATIA. In addition to importing geometry, this step in the navigation also allows the user to create primitive geometry shapes as well, primarily for mesh refinement zones, which can also be imported in the same fashion as the primary geometry. Adjusting/modifying the imported geometry can also be performed here.
Domain
The next step is “Domain,” during which the imported geometry is split into the required boundaries and physics boundary conditions will be assigned. Nothing fancy here, but the general step-wise progression in this manner allows the user to be task-focused while not getting lost in the weeds of an analysis setup.
Mesh
OMNIS Mesh example with Wall Layer Refinement
Once the geometry and domain are set, next up is meshing. Built into OMNIS is the hexahedral-dominant HEXPRESS mesher. During our testing, the mesher felt robust and provided high quality elements as well as boundary layer refinement/inflation layers. The ability to refine via inserting a “refinement geometry” is very smooth and intuitive. Mesh analysis is also easy, as is the ability to adjust settings and remesh (remember, the user can go back to domain or geometry easily with a single mouse click without losing any settings). One feature that we particularly enjoyed was the mesh “preview,” which shows the surface mesh on the geometry in the real time as the user adjusts cell size settings in the properties panel. This allows the analyst to see visually what the final mesh may look like prior to running the more time-consuming meshing step. Note that no polyhedral mesh elements are supported.
The image below shows a refinement zone we successfully inserted within the center of a pipe. Both were created externally and imported as separate Parasolid files.
Simulation
Once your mesh is successfully created, its time to determine the simulation settings. Here, the fluid type and properties along with boundary conditions and solver settings, including stopping criteria, are set up. This step is also very intuitive, however, for us, the stopping criteria was a bit unique compared to other software packages out there. We will touch on this later. Once the simulation is ready to run, it can be launched from within the GUI with the click of a button, and then the “Results Analysis” is available for “co-processing”. This feature is helpful because the user can monitor any post-processing scenes of fluid contours, vectors, etc. while the simulation is solving. This obviously isn’t available in batch mode, but it is nice to have as an error-check feature during model setup. One downside to using OMINS for simulations is that for now, only a basic single-phase flow solver is included (other than Lattice-Boltzmann, which we have not tested). This means no passive scalar, porous media, multi-phase (Lagrangian or Eulerian), chemical reactions/combustion, moving mesh/moving boundary, and no conjugate heat transfer from fluid to solid zones. OMNIS is just a single-phase fluid flow Reynolds-Averaged Navier-Stokes solver. Transient and steady-state options are available, as well as both laminar and turbulent (K-Omega, K-Epsilon, Spalart-Allmaras, as well as several others). However, from what we are told, Numeca aims to bring all of this into the OMNIS environment eventually, building up this tool with additional physics.
Results Analysis
Once the simulation completes, the final step in the navigation panel work flow is Results Analysis. Here, the typical post-processing tools are available within the main GUI window, including making clip planes for contour/vector images, as well as line probes for data extraction. Creating “quantities” is a nice touch that allows the user to create custom values (at each cell) derived on solved continuum properties. One example available in Numeca’s user guide is to create a user vector field “momentum,” (the density times the velocity vector), which can then be plotted via a vector plot.
There are some additional features we would like to see here. First, we would like the ability to create user monitors and reports, such as minimum, maximum, or average of any of the fluid field properties (velocity, density, etc.) within the domain OR on a certain plane/axis/location. Next, we think the ability to export a scene image during the solve would be beneficial for making animations of a transient simulation. Finally, the built-in post-processing seems to be lacking some of the basics we have come to expect from other commercial products, such as the ability to display streamlines. Hopefully, more features will be added to the post processing in future versions.
Other Points
We found that both setting up a case and getting it running were very intuitive. However, we found it challenging to balance computational expense and accuracy, as methods for determining convergence of simulations was atypical compared to other software packages. Typically, convergence of a simulation is measured by the minimization of the global numerical errors in solving the system of algebraic equations representing the discretized version of the relevant partial differential equations. As a steady-state simulation progresses, these “residuals” track to lower and lower values and the “error” in the solution is reduced. Typically, residual values are tracked per “iteration” of the numerical solver and a stopping criterion can be set such that the code is run until residuals reach a certain target value (such as 1.0E-4 or so). Within OMNIS, though, such residuals were not handled as is typical.
First, residuals are not tracked via a normalized/averaged global error across all cells- they are tracked based on an order of magnitude basis in relation to the original solution. This means that instead of tracking towards a residual target of 1.0e-3 or 1.0e-4, the equivalent target is -3.0 or -4.0 corresponding to 3 or 4 orders of magnitude reduction in error from the initial iteration. To get down to this level for a simple laminar pipe flow case with default solver settings (3 multigrids, default CFL number and discretization schemes) took an extreme amount of time on a multiple core machine. One of the tutorials we attempted to run failed to hit the convergence criteria in over 4 hours on 16 cores.
The second thing we noticed is that these residuals are tracked every “cycle” and not “iteration”. To us, a cycle is a multigrid scheme term as within each iteration of a multigrid algorithm, the matrix is coarsened and relaxed for several layers in order to solve the finest grid more efficiently. Are the cycles here the same as iterations? Not sure. We did note that inputting the number of iterations as a stopping criteria does not necessarily end the simulation at that number of cycles. Since OMNIS is solving on (by default) 3 grids via a multigrid approach, perhaps the number of iterations input as a stopping criteria is meant to be for the final/finest grid only, and not the sum of all three grids.
The parallel processing seems to be working, however, the test cases we ran took significantly longer to reach convergence versus other comparable solvers. Perhaps we were trying to converge to much too low of a target. This could be due to the fact that the residual tolerance the user specifies applies to all of the multigrids. Maybe this speeds things up and perhaps some independent multigrid residual tuning should be added here as well. In any case, more light should be shed determining convergence through residual errors via user documentation in order to limit confusion.
We did not test any batch mode processes or cloud computing; however, the capability should be there according to the user documentation.
Licensing and Cost
We have not been able to obtain any pricing information for OMNIS yet and do not know if on-demand licensing is available. We will update this post as information becomes available.
Summary
Numeca OMNIS is a solid tool that allows a wide range of CFD users from novices to experts to efficiently setup and run analyses of single-phase fluid cases all within a single environment. Post processing seems a bit limited at this point, as well as advanced physics capabilities, such as moving mesh and multiphase. We’ve been told that these advancements should be ported over from the FINE product line with future OMNIS releases. We will definitely be keeping our eye on OMNIS as it develops. From what we’ve experienced so far, OMNIS holds a lot of promise, especially once Numeca finishes integrating the full set of capabilities from the FINE product line.
Part 3 Conclusions:
All three of the tools discussed above have the potential to be extremely valuable in the right context. COMSOL brings unique capabilities for combining custom physics with pre-packaged solution methods for fluid dynamics. It also provides strong multi-physics capabilities and decent workflow, pre-processing and post-processing capabilities. Its drawbacks are its computational expense (memory and speed) due to its reliance on finite element methods and its cost when combining multiple modules to achieve expanded multi-physics. Meanwhile, CONVERGE CFD possesses plenty of state-of-the-art tools to be used in simulating internal combustion engines and is quickly adding many capabilities for a wider range of applications. Its unique approach to adaptive meshing will be of interest to any practitioner wishing to produce high fidelity results on micro-scales where regions requiring mesh refinement are not known prior to meshing. Its biggest drawback is a clunky workflow due to limitations on pre-processing and the requirement for a 3rd party post-processor, while we are also concerned with the computational expense of remeshing at each time step on moving boundary problems. Last but not least, OMNIS is an exciting new project from NUMECA that promises to combine the excellent physics modeling capabilities of its diverse suite of software into an integrated workflow environment. While this original release is a bit rough around the edges with regards to the finer points and lacking any multi-physics capabilities, its workflow is smooth and pre- and post-processing are adequate. We will definitely be keeping an eye on its future development.
