CONVERGE FAQ
From CFD-Wiki
(→1. My simulation runs slowly. How can I identify the cause?) |
(→What are the benefits of using inlaid mesh in spray simulations, and what are the limitations?) |
||
(128 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
- | + | '''We hope you find the following FAQ helpful. For more information about many of the topics listed here, please review the CONVERGE documentation available on download.convergecfd.com (login required). In particular, the CONVERGE Manual, CONVERGE Studio Manual, Getting Started Guide, and training slides may be especially helpful. In addition, the example cases (each consisting of a surface geometry and input parameters) in CONVERGE Studio can provide a useful starting point for your own cases.''' | |
- | We hope you find the following | + | |
- | == | + | ==INSTALLING AND RUNNING CONVERGE== |
- | === | + | ===What are the hardware and software requirements for CONVERGE and CONVERGE Studio? How do I install CONVERGE or CONVERGE Studio?=== |
- | + | Please refer to the Getting Started Guide for hardware and software requirements, installation instructions, and other related information. | |
- | |||
- | |||
- | === | + | ===Should I enable hyper-threading for my CONVERGE simulation?=== |
- | CONVERGE | + | CONVERGE, like other software packages that are designed to run on a large number of cores, does not run as efficiently when hyper-threading is enabled. This is true even when the number of processes in a simulation does not exceed the number of physical cores on the machine. For best performance, disable hyper-threading before running a CONVERGE simulation. |
- | |||
- | |||
- | ===5. My turbomachinery simulation time-step is limited by dt_move. How can I make this simulation run faster?=== | + | ===On Linux, what does the File locking failed in ADIOI_Set_lock</code error message mean? On Windows, what does failed MPI_fopen() mean?=== |
+ | These error messages apply only to CONVERGE 2.4 or earlier versions. On a Linux machine, this error may be the result of MPI interacting with an NFS-mounted file system. To be able to use mpi_write_flag = 1 (available in CONVERGE 2.4 and earlier versions) on an NFS-mounted file system, use NFS version 3.0+ and ensure that the client machine is mounted to the file system with the noac (no attribute caching) option. | ||
+ | |||
+ | |||
+ | ===I see that CONVERGE offers various MPI implementations (MPICH2, HPMPI, OPEN MPI, PMPI). Which one should I use?=== | ||
+ | For version 2.4 and earlier, based on some internal testing of ICE cases, we have found that OpenMPI may be the fastest. However, OpenMPI is not always forward/backward compatible. Different major CONVERGE versions may require different OpenMPI installations. PMPI gives the best compatibility across different versions. Please note that results may vary due to different release versions of each MPI implementation. | ||
+ | |||
+ | For CONVERGE 3.0, the MPI packages are shipped with the installation package to reduce the likelihood of compatibility issues. If you have your own implementation of an MPI package, we recommend using that instead (refer to the Getting Started Guide for supported MPI versions). Otherwise, you can use any of the MPI packages shipped with the installation package. For better scalability on machines with a high-speed interconnect, we recommend using Intel MPI. | ||
+ | |||
+ | ===Can CONVERGE run on GPUs?=== | ||
+ | Currently the CONVERGE solver does not run on GPUs. Convergent Science engineers are actively working on porting portions of the solver to use GPUs. | ||
+ | |||
+ | |||
+ | |||
+ | ==COMPUTATIONAL SPEED, MESH AND LOAD BALANCING== | ||
+ | ===How does y+ AMR restriction work? Can I use this feature to ensure I have an acceptable mesh near the wall for the law-of-the-wall models?=== | ||
+ | CONVERGE has an option for y+ AMR restriction, which can restrict AMR cells close to the wall. You specify the target y+ and y+ ratio for this feature: | ||
+ | *y+ target: If the y+ value of a cell near the specified boundary is less than the specified target, then at that time-step CONVERGE will remove one level of refinement from that cell. CONVERGE does not remove more than one level of refinement in a single time-step even if the resulting y+ value is still less than the target. It is important to ensure that the target y+ value is based on the turbulence model in your simulation. | ||
+ | *y+ ratio: If the y+ value of a cell near the specified boundary is less than the product of the y+ target and the y+ ratio, then at that time-step CONVERGE will remove one level of refinement on all of the neighboring cells whose AMR level is equal to or greater than that of the original cell. CONVERGE does not remove more than one level of refinement in a single time-step even if the resulting y+ value is still less than the product of the y+ target and the y+ ratio. | ||
+ | |||
+ | You can use y+ AMR restriction to ensure that the mesh near the wall will be sufficient for a law-of-the-wall model. | ||
+ | |||
+ | ===What is the maximum allowed level of AMR?=== | ||
+ | While there has never been a strict limitation on the maximum number of AMR refinements (AMR level) in CONVERGE, load balancing has limited the practical number of AMR levels. CONVERGE 3.0 load balances by cell, not by parallel block, and load balancing no longer establishes this practical limit. You can apply as many levels of AMR or fixed embedding as are required to resolve the flow physics of interest, although extremely small cells will limit the maximum time-step. | ||
+ | |||
+ | |||
+ | ===How do the scalability improvements in CONVERGE 3.0 affect my simulations?=== | ||
+ | The key improvements for scalability in CONVERGE 3.0 are the ability to get good scaling with a low per-core cell count (fewer than 1,500 cells per core) and the ability to efficiently run one simulation on thousands of cores. These are substantial improvements over previous versions of CONVERGE, which does not scale effectively on fewer than tens of thousands of cells per core. | ||
+ | |||
+ | |||
+ | ===Can I run cases with hundreds of millions of cells in CONVERGE on my HPC?=== | ||
+ | CONVERGE 3.0 has substantial RAM reductions that now allow simulations of hundreds of millions of cells on typical HPC RAM configurations. Memory requirements are substantially reduced. RAM use has been reduced by a factor as much as 2.5 compared to previous versions of CONVERGE. | ||
+ | |||
+ | |||
+ | ===Can I import my native CAD files directly into CONVERGE?=== | ||
+ | Yes, CONVERGE 3.0 integrates the Spatial software package for direct import of most native CAD files. Previous versions of CONVERGE required a STL triangulation of the surface. The Spatial import offers a resolution setting (coarse, medium or fine) for the interpolation of the CAD geometry to a triangulated surface in CONVERGE. The previous STL workflow is still supported. | ||
+ | |||
+ | |||
+ | ===What is the best way to extract aero-volume from a CAD geometry?=== | ||
+ | The most direct approach is to use a CAD tool such as NX, Solidworks, or whatever was used to create the surface. You can import the STL file (or use Spatial to read in CAD file) into CONVERGE Studio and delete the solid surfaces (if conjugate heat transfer is not part of the simulation). A more sophisticated workflow is required when the geometry is complex and includes minute details such as nuts, bolts or holes that are not a part of the fluid/aero volume. | ||
+ | |||
+ | |||
+ | ===How would having inlaid cells in my domain affect the load balancing in CONVERGE 3.0?=== | ||
+ | Inlaid cells are treated the same as Cartesian cells when it comes to load balancing. This means that regardless of how fine the inlaid mesh is, the load balancing will be as efficient as it would without the inlaid cells. For reasons other than load balancing, a simulation with inlaid mesh can be slightly slower than the similar case without the inlaid mesh, but it is not related to the load balancing. On the other hand, the inlaid mesh case may be faster if the inlaid mesh feature allows for a lower cell count. | ||
+ | |||
+ | |||
+ | ===Does CONVERGE have cell-based load balancing?=== | ||
+ | CONVERGE 3.0 partitions the domain on a cell-by-cell basis. Previously, domain partitioning was done on blocks coarser than the largest cell in the domain. Note that these changes remove our longstanding recommendation that you limit the number of embed levels to ensure good load balancing. Now cell-based load balancing can balance the computational load more equally for a large number of cores. | ||
+ | |||
+ | |||
+ | ===Is there any difference between the way paired cells are shown in 3D post-processing of CONVERGE 3.0 and earlier simulation results?=== | ||
+ | In CONVERGE 3.0, paired cells are shown as merged, whereas previous versions showed paired cells separately. | ||
+ | |||
+ | |||
+ | ===Why do I get different cell counts for similar CONVERGE 2.4 and 3.0 simulations?=== | ||
+ | In CONVERGE 3.0, the paired cells are counted as one. In CONVERGE 2.4 and older, the paired cells were counted individually. You can set legacy_cell_count = 1 in hidden.in to make a direct cell count comparison with legacy versions. | ||
+ | |||
+ | |||
+ | ===Can CONVERGE automatically match the cell sizes on a Cartesian-inlaid mesh interface?=== | ||
+ | CONVERGE offers an inlaid mesh neighbor type of AMR. This AMR type refines the mesh on the Cartesian side based on the cell size discrepancy between neighboring cells on either side of the INTERFACE boundary separating the inlaid and the Cartesian mesh. | ||
+ | |||
+ | |||
+ | ===Can CONVERGE automatically improve the quality of the mesh in tight gaps?=== | ||
+ | CONVERGE offers a proximity-based type of AMR. This refines the mesh in tight gaps such as those in rotating machinery. | ||
+ | |||
+ | |||
+ | ===Are there any new types of AMR available in CONVERGE 3.0?=== | ||
+ | In addition to existing options such as temperature and velocity, there are four new options: | ||
+ | *Pressure | ||
+ | *Density | ||
+ | *Inlaid neighbors | ||
+ | *Proximity-based | ||
+ | In addition to these conventional sub-grid-scale AMR types, you can define AMR based on the value of a flow variable, e.g., void fraction in a VOF simulation. Value-based AMR is generally not self-limiting (e.g., subdividing a cell based on the void fraction may produce child cells with approximately the same void fraction), so we recommend that you apply it sparingly. | ||
+ | |||
+ | ===What is an inlaid mesh? What versions of CONVERGE support them?=== | ||
+ | In CONVERGE 2.4 and earlier, the entire domain is subdivided by the automatically generated Cartesian cut-cell mesh. CONVERGE 3.0 can also solve cells that are constructed and inlaid within the octree cells. These are referred to as inlaid cells. Inlaid cells have a prescribed shape, size, and orientation. They can be used, for example, for boundary layer meshes or spray-aligned conical meshes. This feature allows the import of any grid to be used in conjunction with the typical CONVERGE Cartesian grid. You can also construct inlaid meshes in CONVERGE Studio. Note that inlaid meshes do not currently support AMR or fixed embedding, and they cannot move or contact a moving boundary. | ||
+ | |||
+ | |||
+ | ===Is the inlaid mesh automatically created at the start of simulation or during pre-processing?=== | ||
+ | Inlaid meshes are created during pre-processing in CONVERGE Studio. The inlaid mesh is defined as part of the geometry, and it belongs to the surface file. | ||
+ | |||
+ | |||
+ | ===How do I set up an inlaid mesh with CONVERGE 3.0?=== | ||
+ | Most inlaid meshes are constructed in CONVERGE Studio. First, create the inlaid mesh with the help of Studio by going to Geometry > Inlaid mesh > Shaped mesh/Extrusion. Then, set up the correct boundary conditions for all surfaces belonging to the user-made mesh. | ||
+ | Additionally, CONVERGE 3.0 offers the capability to read in stationary meshes from other software packages in Plot3D format. | ||
+ | |||
+ | |||
+ | ===Can an inlaid mesh in CONVERGE 3.0 be attached to a moving boundary?=== | ||
+ | Inlaid meshes can be used in a simulation that has moving boundaries, but the inlaid mesh cannot be attached to a moving boundary or interacting with a moving boundary. | ||
+ | |||
+ | |||
+ | ===How can I find more information about inlaid mesh and boundary layer mesh feature?=== | ||
+ | More information can be found in CONVERGE 3.0 Manual (chapter 6). For additional assistance, please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)]. | ||
+ | |||
+ | |||
+ | ===My simulation runs slowly. How can I identify the cause?=== | ||
+ | A simulation might run slowly for a variety of reasons. First, look at the log file (or at time.out) to see what is limiting the time-step. If output_control > log_level = 3 in inputs.in, CONVERGE records in the log file and in time.out the time spent on each major routine (combustion, spray, load balancing, moving grids, etc.). These data can shed some light on the slowdown. Some common causes for a slow simulation are: too many parcels in a spray simulation, a large chemical mechanism in a combustion simulation, or a misconfigured cluster interconnect. CONVERGE 2.4 and earlier were susceptible to poor load balancing. CONVERGE 3.0 almost always load balances well. You can review cell_count_ranks.out to understand and determine how to improve the load balancing. | ||
+ | |||
+ | |||
+ | ===The time-step in my simulation is limited by max_cfl_u. How can I accelerate my simulation?=== | ||
+ | When the variable time-stepping algorithm is used, CONVERGE controls the time-step by the user-specified CFL numbers (among other limiting criteria). When the convective CFL number limits the time-step, it may be due to small cell sizes or high flow velocities. You can use a region- and temporal-based CFL number to increase the time-step when important events are not occurring. For example, set temporal_control > max_cfl_u = 1 in inputs.in during combustion and increase it during the exhaust phase. Refer to the SI8 engine PFI SAGE example case (in CONVERGE Studio, go to File > Load example case) to see a demonstration of this technique. Turning off embedding during less important times of the simulation (or in less important parts of the domain) may also help alleviate this restriction. | ||
+ | |||
+ | |||
+ | ===How can I speed up my multiple-cycle engine simulations?=== | ||
+ | CONVERGE features such as skip species, region- and temporal-based convective CFL number, and region- and temporal-based AMR can speed up multi-cycle engine simulations. The SI8 engine head CHT steady RANS example case includes these features. | ||
+ | |||
+ | |||
+ | ===My simulation slows down significantly when spray starts. What should I do?=== | ||
+ | A slowdown when the spray starts is expected, but there are some steps to take if you are concerned. First, check if the total number of injected parcels (num_parcels_per_nozzle) is set based on the recommended criterion for your grid size. Note that the specified number of parcels in spray.in is for a single nozzle, while the injected mass is for the entire injector. If you dramatically reduce the number of parcels, you should check how sensitive the predictions are relative to the injected number of parcels. If collision is turned on, verify that multiple nozzles do not reside in a single cell. | ||
+ | |||
+ | |||
+ | ===My turbomachinery simulation time-step is limited by dt_move. How can I make this simulation run faster?=== | ||
A time-step limited by dt_move is a typical bottleneck in high speed turbo-machinery simulations. This time-step limit was put in place primarily for stability reasons. There are two options to try to get around this bottleneck and speed up your simulation: increase the cell sizes at the moving boundaries or relax the dt_move constraint. Note that either of these workarounds can affect the solution accuracy and stability. | A time-step limited by dt_move is a typical bottleneck in high speed turbo-machinery simulations. This time-step limit was put in place primarily for stability reasons. There are two options to try to get around this bottleneck and speed up your simulation: increase the cell sizes at the moving boundaries or relax the dt_move constraint. Note that either of these workarounds can affect the solution accuracy and stability. | ||
The swept cell volume of any moving boundary is limited to a portion of cell in a single time-step. The default value in CONVERGE is 0.5 (i.e., in a single time-step, the moving boundary cannot sweep more that 50% of the smallest cut-cell volume). You can use values greater than 1.0, although higher values might affect solution stability or accuracy. To change this value in CONVERGE Studio 2.4+, go to Simulation Parameters > Simulation time parameters > Moving boundary time-step multiple. | The swept cell volume of any moving boundary is limited to a portion of cell in a single time-step. The default value in CONVERGE is 0.5 (i.e., in a single time-step, the moving boundary cannot sweep more that 50% of the smallest cut-cell volume). You can use values greater than 1.0, although higher values might affect solution stability or accuracy. To change this value in CONVERGE Studio 2.4+, go to Simulation Parameters > Simulation time parameters > Moving boundary time-step multiple. | ||
- | |||
- | |||
- | + | ===Will the triangle count in my CAD file affect my simulation’s runtime?=== | |
- | === | + | |
Yes, especially for cases with moving boundaries. CONVERGE generates the grid at each time-step, and there is a computational cost in trimming Cartesian fluid cells. If a geometry contains an unnecessarily high triangulation, we recommend coarsening the surface to reduce the number of triangles while retaining the surface features. CONVERGE Studio contains a coarsening tool. | Yes, especially for cases with moving boundaries. CONVERGE generates the grid at each time-step, and there is a computational cost in trimming Cartesian fluid cells. If a geometry contains an unnecessarily high triangulation, we recommend coarsening the surface to reduce the number of triangles while retaining the surface features. CONVERGE Studio contains a coarsening tool. | ||
- | Think of it this way: a rectangle can be defined by two triangles. Alternatively, a poor CAD algorithm can define a rectangle of the same area by 1 million small triangles. This huge triangle addition can slow down simulations. For typical engine geometries, keep the triangle count around 0.3 to 0.5 million. | + | Think of it this way: a rectangle can be defined by two triangles. Alternatively, a poor CAD algorithm can define a rectangle of the same area by 1 million small triangles. This huge triangle addition can slow down simulations. For typical engine geometries, keep the triangle count around 0.3 to 0.5 million. |
+ | |||
+ | |||
+ | By looking at cell_count_ranks.out, it is clear that the load balancing of my simulation is not optimal. How can I improve the load balancing? | ||
+ | CONVERGE 2.4 and earlier distribute blocks of cells rather than individual cells. A value of parallel_scale = -1 in inputs.in yields the highest number of blocks for domain decomposition. Try increasing parallel_scale (e.g., from -2 to -1). Also, larger embed scales in fixed embedding and AMR can make load balancing difficult, and thus reducing the embed scale and the base mesh size can allow you to achieve better load balancing while maintaining the same smallest cell size. Even though this approach will increase the total number of cells, the case may run faster due to better load balancing. Chapter 11 in the CONVERGE 2.4 Manual gives an example of how reducing the base mesh size can reduce the cell count on the highest-loaded rank. | ||
- | + | In CONVERGE 3.0, the load balancing is based on cells. This means that, regardless of embed levels set for fixed embeddings and AMR, the solver can almost perfectly distribute the cells between the cores. The solver will automatically redo the load balancing, when the ratio of max cell in a rank to average cells per rank exceeds the simulation_control > imbalance_factor in inputs.in. CONVERGE 3.0 rarely load balances poorly. | |
- | + | ||
- | === | + | ===What is the non-transport passive CHEM_STIFF?=== |
CONVERGE allows the use of stiffness-based load balancing for simulations that use the SAGE detailed chemistry solver (stiffness-based load balancing is required for SAGE simulations without adaptive zoning and optional for SAGE simulations with adaptive zoning). Any simulation that uses stiffness-based load balancing must contain the non-transport passive CHEM_STIFF in the species.in file. | CONVERGE allows the use of stiffness-based load balancing for simulations that use the SAGE detailed chemistry solver (stiffness-based load balancing is required for SAGE simulations without adaptive zoning and optional for SAGE simulations with adaptive zoning). Any simulation that uses stiffness-based load balancing must contain the non-transport passive CHEM_STIFF in the species.in file. | ||
- | |||
- | |||
- | === | + | ===My simulation spends quite a bit of time on load balancing. Why?=== |
- | + | For CONVERGE 2.4 and earlier, if a significant amount of time is spent on load balancing, it is likely due to a large number of parallel blocks (see metis_map.out). Reduce parallel_scale (e.g., from -1 to -2) in inputs.in and rerun the simulation. Check that the new load balance at the reduced parallel_scale is still adequate. | |
- | + | For CONVERGE 3.0, the load balancing is performed with the parallel ParMETIS algorithm, and it is cell based. This parallel load balance is much faster than legacy versions of CONVERGE. | |
- | + | ||
- | |||
- | |||
- | === | + | ===What is the optimum number of cells/processor for a typical ICE simulation?=== |
- | + | For CONVERGE 2.4 and earlier, having at least 50,000 cells/core has been observed to give good parallel speedup. | |
- | + | CONVERGE 3.0 offers much better scaling compared to CONVERGE 2.4 and earlier. Depending on the hardware (cluster and interconnect), you can efficiently run with many fewer cells per core (fewer than 1500). | |
- | + | ||
- | + | ||
- | |||
+ | ===How often does CONVERGE do load balancing?=== | ||
+ | In CONVERGE 2.4 and earlier, the load_cyc parameter in inputs.in controls the frequency of load balancing. In addition, CONVERGE load balances each time a fixed embedding changes (either refined or released) and at the start of a simulation (new simulation, mapping, or restart) a load balancing event is done. | ||
- | + | In CONVERGE 3.0, the solver will automatically redo the load balancing when the ratio of max cell in a rank to average cells per rank exceeds the simulation_control > imbalance_factor that you specify in inputs.in. | |
- | + | ==OUTPUTS AND POST PROCESSING== | |
+ | ===Is post-processing large cases more manageable in CONVERGE 3.0 than in previous versions?=== | ||
+ | CONVERGE 3.0 writes output files in HDF5 format, which is more efficient and robust when working with large parallel cases. Critically, Tecplot for CONVERGE can now read these files natively (for CONVERGE 3.0.8+), eliminating the time and storage constraints associated with running post_convert. This feature may be useful for simulations with larger geometries, such as gas turbines. | ||
- | |||
- | |||
- | + | ===How do I predict the ammonia uniformity index before SCR?=== | |
- | + | Ammonia uniformity is one of the major factors to look into during the SCR system design cycle. CONVERGE 3.0 makes it easier for you to configure the uniformity index by integrating it into CONVERGE Studio as a standard feature (go to Case Setup > Output/Post-Processing > Uniformity index). Once activated, you can specify the location, orientation, and region of the plane where the uniformity index is calculated. Cell variables such as velocity, temperature, YNH3 and XHNCO are available for the uniformity index calculation. | |
- | |||
- | |||
- | + | ===Where do I see residuals in CONVERGE?=== | |
- | This is a | + | CONVERGE does not use residuals to determine convergence. Instead, it uses a steady-state monitor approach where key variables are monitored and criteria are met when the case becomes steady. This is a more robust method of determining steady-state convergence than simply looking at how much better the simulation is than where it started (i.e., residuals). Further, CONVERGE’s variable time-step approach is fundamentally different than the fixed time-step approach of other codes. CONVERGE reaches convergence on all variables in each time-step. |
- | |||
- | |||
- | 8. The NOx emissions in emissions.out and species_mass.out are not identical. What is the difference between these quantities? | + | ===How can I know at what time a restart file has been written? And how do I know if the file has been written properly?=== |
+ | In CONVERGE 3.0, type the following command to obtain the time at which a restart file was written: | ||
+ | <br>h5dump -a TIME_STEP <restart file name> | ||
+ | |||
+ | If the above command does not work, the file may be corrupt. | ||
+ | |||
+ | In CONVERGE 2.3 and 2.4, the first line of the restart file includes the time. To obtain the first line of the restart file, type the following command: | ||
+ | |||
+ | head -1 <restart file name> | ||
+ | |||
+ | To check if the file has been written properly, type: | ||
+ | |||
+ | tail -1 <restart file name> | ||
+ | |||
+ | If the command returns ENDofRSTRT, then the file was written properly. Otherwise, the file may be corrupted. | ||
+ | |||
+ | ===Are CONVERGE 3.0 outputs written differently than previous versions?=== | ||
+ | CONVERGE 3.0 writes the post (post*.h5), restart (restart*.rst), and map (map*.h5) files in HDF5 format, which is an industry standard format with a proven track record in terms of performance and scalability. These files are binary but can be viewed and edited using standard HDF5 tools. | ||
+ | |||
+ | |||
+ | ===Can a map file from an older version of CONVERGE be used for newer versions?=== | ||
+ | The map files for CONVERGE 2.4 and older are interchangeable. The format of the map file for CONVERGE 3.0 has changed to HDF5. There is an internal converter in CONVERGE Studio 3.0 that converts the old map files to HDF5 format to be used for CONVERGE 3.0+ simulations. Note that the map files from CONVERGE 3.0 cannot be converted to the format for older versions. | ||
+ | |||
+ | |||
+ | ===What is slice-based post-processing?=== | ||
+ | Slice-based post-processing is a new feature in CONVERGE 3.0 that allows you to configure a plane on which CONVERGE will record the value of various quantities for post-processing. This useful feature is also available in CONVERGE 2.4 as a hidden feature. | ||
+ | |||
+ | |||
+ | ===Can Tecplot directly read CONVERGE post output files?=== | ||
+ | Yes. Tecplot can now natively read the CONVERGE *.h5 post files from CONVERGE 3.0.8+. | ||
+ | |||
+ | |||
+ | ===How can I see how long CONVERGE spends on different processes (e.g., spray, combustion, and load balancing)?=== | ||
+ | In CONVERGE Studio, go to Simulation Parameters > Run parameters > Misc and set the Screen print level to Verbose or More verbose. Upon running the case you will see the below output in the log file either after every iteration (more verbose screen output) or at the end of simulation (verbose screen output) : | ||
+ | |||
+ | Time for ncyc 41 = 3.89 seconds | ||
+ | |||
+ | load balance = 0.00 seconds (0.00%) | ||
+ | |||
+ | solving transport equations = 3.37 seconds (86.50%) | ||
+ | |||
+ | move surface and update grid = 0.01 seconds (0.16%) | ||
+ | |||
+ | Combustion = 0.00 seconds (0.00%) | ||
+ | |||
+ | spray = 0.06 seconds (1.60%) | ||
+ | |||
+ | writing output files = 0.27 seconds (6.89%) | ||
+ | <br> | ||
+ | |||
+ | ===I ran two simulations with identical settings except that one simulation was initialized via mapping. Why are the results from these two simulations not the same?=== | ||
+ | The mapping data file does not save grid information and thus CONVERGE does not map data into the same cells. Instead, in a simulation with mapping, CONVERGE initializes each cell with data from the nearest point in the mapping data file. This process may result in some data smearing (i.e., several cells in the new simulation may be initialized with data from the same point in the map file). In addition, the AMR resolution from the old grid is not carried over to the new simulation. These differences are the reasons that the results are not identical. | ||
+ | |||
+ | |||
+ | ===What CONVERGE quantity can be compared against measured mass flow rate data at the intake port?=== | ||
+ | CONVERGE writes mass flow at the valves to regions_flow.out. CONVERGE writes mass flow rates from the inflow and outflow boundaries to mass_avg_flow.out and area_avg_flow.out. | ||
+ | |||
+ | |||
+ | ===How can I check the status of my simulation?=== | ||
+ | Look at the time.out file, which is available in CONVERGE 2.3.10+. You will find the wall time per time-step, which tells you how much time is being spent at each time-step or cycle. This quantity can give you an idea if your simulation is slowing down. You can also see if there are any recoveries in the simulation and what is causing the recoveries. The time.out file also contains the time-step size, what is limiting the time-step, and the values of the CFL numbers at each time-step. | ||
+ | |||
+ | Additionally, there is a log file written with each CONVERGE simulation which contains a lot of information. Depending on the verbosity level specified in inputs.in (output_control > log_level) the amount of information in this file will vary. | ||
+ | |||
+ | |||
+ | ===The NOx emissions in emissions.out and species_mass.out are not identical. What is the difference between these quantities?=== | ||
The NOx emissions in emissions.out are from the extended Zel’dovich mechanism, which is hard-coded in CONVERGE. The calculated NO mass is multiplied by a factor of 1.533 to output NOx mass. This output is available even if you are not solving detailed chemistry. If you are using the SAGE detailed chemistry solver and if the chemical mechanism includes NOx species and reactions, then those species masses are recorded in species_mass.out. The NOx mass calculated using SAGE might not match exactly with that calculated using the extended Zel’dovich mechanism. In the passive NOx model, radicals [O] and [OH] can be assumed to be at equilibrium, while species NOx does not make such an assumption. This assumption in the passive NOx model is valid only at high temperatures (T > 2200 K). Quantities solved outside of this requirement might be responsible for the different NOx emissions data. | The NOx emissions in emissions.out are from the extended Zel’dovich mechanism, which is hard-coded in CONVERGE. The calculated NO mass is multiplied by a factor of 1.533 to output NOx mass. This output is available even if you are not solving detailed chemistry. If you are using the SAGE detailed chemistry solver and if the chemical mechanism includes NOx species and reactions, then those species masses are recorded in species_mass.out. The NOx mass calculated using SAGE might not match exactly with that calculated using the extended Zel’dovich mechanism. In the passive NOx model, radicals [O] and [OH] can be assumed to be at equilibrium, while species NOx does not make such an assumption. This assumption in the passive NOx model is valid only at high temperatures (T > 2200 K). Quantities solved outside of this requirement might be responsible for the different NOx emissions data. | ||
+ | |||
+ | In CONVERGE 2.4 and earlier, the NO emission reported in passive.out is not multiplied by the mass scaling factor (typically 1.533) to get NOx emissions. So, the NO emission reported in passive.out differs from the one reported in emissions.out. In CONVERGE 3.0, the values of NO emissions in passive.out are also multiplied by the mass scaling factor. Thus the emissions.out and passive.out values match in CONVERGE 3.0. | ||
+ | |||
+ | |||
+ | ===For 1DCHT cases, how can I view the surface temperature in a post-processor?=== | ||
+ | The bound_temp variable in post.in will give the surface temperature. | ||
+ | |||
+ | |||
+ | ===How can I obtain surface-averaged data on individual boundaries?=== | ||
+ | In CONVERGE Studio, go to Case Setup > Output/Post-Processing > Output files > Output generation and select Generate WALL boundary-averaged output. This option will generate a series of files named bound*-wall.out. | ||
+ | |||
+ | |||
+ | ===What is the difference between monitor points and super-cycle monitor points? === | ||
+ | Monitor points are locations in the domain at which CONVERGE collects data during the simulation. The general monitor point option (monitor_points.in or Case Setup > Output/Post-Processing > Monitor points) allows you to place points throughout the domain and to select from a variety of variables to be monitored at those locations. CONVERGE writes monitor point data at each time-step. | ||
+ | |||
+ | Super-cycle monitor points (supercycle.in or Case Setup > Physical Models > Super-cycle modeling) provide temperature data from specific locations within the solid domain. CONVERGE writes super-cycle monitor point data at each super-cycle. | ||
+ | |||
+ | |||
+ | ===How can I output the prescribed heat transfer coefficient to the post*.out files?=== | ||
+ | This option is not available in CONVERGE 2.3. In CONVERGE 2.4+, include bound_htc in post.in (Case Setup > Output/Post-Processing > Post variable selection). | ||
+ | |||
+ | ==COMBUSTION AND EMISSIONS== | ||
+ | ===How can I determine the type of flame I should expect (i.e., premixed or non-premixed) for my applications using CONVERGE?=== | ||
+ | CONVERGE provides a post-processing variable called flame_index in post.in. It is a dot product of the fuel mass fraction and oxidizer mass fraction. If flame_index = -1, then the flame is non-premixed. If flame_index = 1, then the flame is premixed. | ||
+ | |||
+ | |||
+ | ===What is the thickened flame model in CONVERGE 3.0 used for?=== | ||
+ | One of the challenges of obtaining accurate combustion simulations with laminar detailed chemistry (SAGE) and large eddy simulations (LES) is that the mesh should be refined sufficiently to resolve the flame thickness with at least a few cells. This can be a challenge for thin flames at high pressure. The thickened flame model (TFM) artificially thickens the flame by adding diffusivity and slowing the reaction rate. By increasing the diffusivity and reducing the reaction rate consistently, the flame speed is unchanged but the flame thickness is increased. TFM currently works with premixed or partially premixed gaseous fuels. | ||
+ | |||
+ | |||
+ | ===Is there a difference between the FGM table in 2.4 and 3.0? Where do I go in CONVERGE Studio 3.0 to set up and generate an FGM table?=== | ||
+ | In CONVERGE 3.0.8+, the FGM table in fgm_table.dat is four-dimensional (CMEAN, ZMEAN, ZVAR, enthalpy), while in earlier versions the table is two-dimensional (CMEAN and ZMEAN; with the other two dimensions created at runtime). In CONVERGE 3.0.8+, several species are required to be tabulated, while there is no analogous requirement in earlier versions of CONVERGE. For more information about the FGM table, please see the CONVERGE Manual. | ||
+ | |||
+ | For CONVERGE Studio 3.0, FGM table generation setup is activated in Chemistry > Chemistry Tools > Table Generation: FGM. Once you have activated FGM table generation, go to Chemistry > Chemistry Setup > FGM Table Generation > FGM table generation to configure the fgm.in file. The command for running FGM table generation is the same as in previous versions: /converge –f. | ||
+ | |||
+ | ===Can I still generate an older 2D FGM table in 3.0.8 or later?=== | ||
+ | The 2D FGM table has been deprecated and is no longer offered as a setup option in CONVERGE Studio. You can, however, manually edit the fgm.in file to create the older table. Add “_deprecate” after the keyword for fgm_flamelet type, for example | ||
+ | fgm_flamelet_type: 1D-DIFFUSION_deprecate | ||
+ | |||
+ | |||
+ | ===When using a 4D FGM table (in CONVERGE 3.0.8+) instead of a 2D FGM table (in CONVERGE 3.0.7 and earlier), what changes are needed in the case setup?=== | ||
+ | The setup for the 4D FGM table does not require a reaction mechanism file (e.g., mech.dat). The thermodynamic data file (e.g., therm.dat) is still needed. The post-processed gas phase species (listed in fgm.in or in the header of fgm_table.dat) must be listed under <gas> in species.in. The input files needed to generate the FGM table remains the same. CONVERGE 3.0.8+ automatically generates a 4D table. If you are starting from a case setup from CONVERGE 3.0.8 or older, remember to regenerate the FGM table in order to create a 4D FGM table. | ||
+ | |||
+ | ===When reducing a large mechanism typical of a gas turbine simulation, what physical parameters does CONVERGE maintain so that the reduced mechanism still emulates the original large mechanism?=== | ||
+ | With CONVERGE 3.0, in addition to ignition delay targets (simulated using 0D simulations), you can also ensure that the laminar flamespeed (simulated using 1D simulations) for the reduced mechanism is maintained within reasonable tolerances of the original mechanism. | ||
+ | |||
+ | |||
+ | ===The cells in my LES are not fine enough to resolve the laminar flame thickness. Is there a way to improve the results of my simulation?=== | ||
+ | In most large eddy simulations (LES) of premixed flames, the cells are not fine enough to resolve the laminar flame thickness. You can couple the SAGE detailed chemical kinetics solver with a dynamic thickened flame model to increase the flame thickness. | ||
+ | |||
+ | ===There is burning in the intake port in my G-Equation simulation. Why?=== | ||
+ | The G-Equation combustion model is active when the G_EQN passive is greater than or equal to zero. Thus, the entire simulation domain and the INFLOW and OUTFLOW masses must be set to a negative G value to avoid initializing flames from unintended locations. Refer to the SI8 engine premix G-Equation example case (in CONVERGE Studio, go to File > Load example case) for example settings. | ||
+ | |||
+ | Note that, in CONVERGE 2.3 and earlier, combustion is either on or off for the entire simulation. For CONVERGE 2.4+, however, combustion has user-specified start and end times. | ||
+ | |||
+ | |||
+ | ===There is burning in the intake port during the second cycle of my G-Equation simulation. The first cycle did not have this problem. Why is there burning in the second cycle?=== | ||
+ | Before the fresh unburned mixture enters the cylinder at the start of the second cycle, the entire simulation domain should be reinitialized with a negative value of G. To set up this option in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > G-Equation > Additional… > Initial G-value and select the Use file option. Refer to the SI8 engine premix G-Equation example case (in CONVERGE Studio, go to File > Load example case). | ||
+ | |||
+ | |||
+ | ===Should I use temperature AMR in a G-Equation combustion simulation?=== | ||
+ | In simulations with the SAGE detailed chemistry solver, temperature AMR is used to resolve the flame front so that the flame propagation speeds (and thus the fuel burn rates) are correct. However, in the G-Equation model, the flame speeds are determined from a flamespeed correlation and so we recommend NOT activating temperature AMR. This will reduce the total cell count and allow the simulation to run faster. Note that CONVERGE does not prohibit the use of temperature AMR in a G-Equation simulation. | ||
+ | |||
+ | |||
+ | ===What laminar and turbulent flamespeeds are used in SAGE?=== | ||
+ | Unlike many simplified combustion models, the SAGE detailed chemistry solver does not calculate laminar and turbulent flamespeeds directly. When using SAGE for calculating premixed combustion, the turbulent flamespeed is the result of the chemical reaction rates (from the mechanism file, e.g., mech.dat) and the enhanced mixing from the turbulence model. Even though a flamespeeds are not directly calculated, the resulting turbulent flamespeed from the chemistry and turbulence model is St=Sl*(Dt/D)^0.5 and Sl is proportional to (reaction rate*D)^0.5. Again, the laminar flamespeed, Sl, and turbulent flamespeed, St, is not explicitly calculated in the SAGE approach. | ||
+ | |||
+ | |||
+ | ===How can I have CONVERGE write out laminar and turbulent flamespeeds in my SAGE simulation?=== | ||
+ | You can use the flamespeed correlations in the G-Equation combustion model. When you set up your simulation in CONVERGE Studio, go to Case Setup > Output/Post-Processing > Post variable selection > Cells and select Laminar Flame Speed and Turbulent Flame Speed. You must also select the desired correlations in Case Setup > Physical Models > Combustion modeling. Note that these calculated flamespeeds are not used in the SAGE calculations and give only an approximation of the flamespeeds that result from the SAGE solver. | ||
+ | |||
+ | |||
+ | ===My high-EGR case does not burn well with the same chemical kinetics mechanism that gave me good predictions for no- or low-EGR cases. What should I do?=== | ||
+ | This is a limitation of the mechanism. It is likely that the mechanism was not validated against ignition delay and laminar flamespeed data under high-EGR conditions. If such data are available, CONVERGE 2.4+ contains a mechanism tuning tool (that sets up input files for genetic algorithm optimization) that can change the reaction rate coefficients to match the high-EGR data. See the CONVERGE manual for more details about this feature. | ||
+ | |||
+ | |||
+ | ===What parameters are available to increase or decrease the burn rates in a SAGE simulation?=== | ||
+ | We recommend reviewing the grid and boundary condition settings for accuracy before trying to tune the reaction rates. The Reaction multiplier option can be used to increase or decrease fuel burn rates (in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (SAGE) > SAGE Parameters). The turbulent Schmidt number can be reduced to enhance mixing and thereby increase burn rates or it can be increased to slow mixing and thereby reduce burn rates (go to Case Setup > Materials > Global transport parameters). | ||
+ | |||
+ | |||
+ | ===The lower heating value (LHV) of the fuel used in the experiments is different from the fuel surrogate used in the simulation. How can I correct this?=== | ||
+ | In CONVERGE 2.4+, you can specify LHVs for individual species. The data in the thermodynamic data file (e.g., therm.dat) will be adjusted to recover the user-specified LHV. To set up this option in CONVERGE Studio, go to Case Setup > Materials > Gas simulation and check Lower heating value. Open the accompanying dialog box to specify the species-specific LHVs. | ||
- | + | ===How can I calibrate the ignition delay in the Shell ignition model?=== | |
- | In CONVERGE | + | In CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (CTC/Shell) and adjust the Ignition delay constant (af04). Increasing this value will reduce the ignition delay. |
- | |||
- | |||
- | + | ===Can the RIF model be used to simulate premixed combustion in CONVERGE?=== | |
No. CONVERGE’s RIF model can be used only for non-premixed combustion. | No. CONVERGE’s RIF model can be used only for non-premixed combustion. | ||
- | + | ||
+ | ===Does the RIF model require an autoignition model in order to simulate diesel combustion?=== | ||
No. CONVERGE’s RIF model uses the provided chemical kinetics mechanism to capture ignition delay. | No. CONVERGE’s RIF model uses the provided chemical kinetics mechanism to capture ignition delay. | ||
- | + | ||
+ | ===Does CONVERGE use pre-compiled flamelet libraries (lookup tables) or does CONVERGE solve the kinetics in the mixture fraction space on the fly?=== | ||
For the FGM model, CONVERGE uses pre-compiled flamelet libraries. For the RIF model, CONVERGE solves the kinetics in the mixture fraction space on the fly. | For the FGM model, CONVERGE uses pre-compiled flamelet libraries. For the RIF model, CONVERGE solves the kinetics in the mixture fraction space on the fly. | ||
- | + | ||
+ | ===Does the RIF model in CONVERGE support unsteady and multiple flamelets?=== | ||
Yes. | Yes. | ||
- | + | ||
+ | ===Can I use the same mechanism for the SAGE detailed chemistry solver and the RIF model?=== | ||
Yes, but note that you cannot run both SAGE and RIF in a single simulation. | Yes, but note that you cannot run both SAGE and RIF in a single simulation. | ||
- | + | ||
+ | ===What advantage do the simplified combustion models have compared to the SAGE detailed chemistry solver?=== | ||
The simplified combustion models are generally faster than SAGE. | The simplified combustion models are generally faster than SAGE. | ||
- | + | ||
+ | ===Do the phenomenological, PM, and PSM soot models work with the RIF combustion model?=== | ||
Yes. | Yes. | ||
- | |||
- | |||
- | |||
- | |||
- | + | ===Which species and reactions are considered in the CTC model?=== | |
+ | The CTC model considers CO, H2, CO2, O2, H2O, N2, and the fuel. Chapter 13 of the CONVERGE Manual describes the reactions in the CTC model. | ||
+ | |||
+ | |||
+ | ===Which parameters should I change to calibrate the CTC model?=== | ||
+ | Increasing the Turbulence time-scale constant will decrease the rate of combustion. You can also adjust the Chemical time-scale constant. To change these parameters in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (CTC/Shell). | ||
+ | |||
+ | |||
+ | ===How can I avoid having my soot values oscillate close to EVO?=== | ||
You can tighten the passive tolerance. More generally, however, we recommend ending combustion before EVO. | You can tighten the passive tolerance. More generally, however, we recommend ending combustion before EVO. | ||
- | |||
- | |||
- | + | ===Can I predict engine knock using the G-Equation model?=== | |
- | + | Yes, you can predict engine knock via G-Equation as long as you are using a version of the G-Equation model that includes the SAGE detailed chemistry solver outside of the flame front (the G = 0 surface). In CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (G-Equation) > Models and select one of the options that includes SAGE outside of the flame front. | |
- | |||
- | |||
- | + | ===When using ECFM3Z, how can I generate my own TKI tables?=== | |
- | + | This can be done using the Table Generation: TKI option in CONVERGE Studio’s Chemistry module. Refer to the Constant_Pressure_Ignition_Delay_Table_Generation example case (in CONVERGE Studio’s Chemistry module, go to File > Load example case). | |
- | |||
- | |||
- | + | ===Can I use ECFM+TKI for knock simulations?=== | |
- | + | Yes, ECFM+TKI is available in CONVERGE 2.3+ and can be used to predict engine knock. | |
- | + | ||
- | + | ||
- | |||
- | |||
- | + | ===Can I use ECFM or ECFM3Z for GDI/PFI engines?=== | |
+ | Both models can be used for GDI/PFI engine simulations. However, we do recommend using ECFM instead of ECFM3Z if the mixing time is short or the grid resolution is not fine enough. Be sure to run your simulation on CONVERGE 2.3.20+. | ||
- | |||
- | |||
+ | ===How can I convert a map.out file from a SAGE simulation for use with an ECFM simulation?=== | ||
+ | Please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)] to obtain a script for this conversion. | ||
+ | ===How do I account for the fuel’s cetane number?=== | ||
+ | When using the SAGE detailed chemistry solver, you can use a fuel blend that has the same cetane number as the fuel used in the experiments. It is important to ensure that all of the surrogate fuel species are available in your chemical kinetics mechanism. | ||
+ | When using the CTC/Shell model for diesel combustion, one of the reaction rates in the shell model can be made a function of the cetane number via a user-defined function. For details, please see the following paper: | ||
+ | *Ayoub, N. and Reitz, R., "Multidimensional Modeling of Fuel Composition Effects on Combustion and Cold-Starting in Diesel Engines," SAE Technical Paper 952425, 1995, doi:10.4271/952425 | ||
+ | ===Can CONVERGE tune kinetic mechanisms to match ignition delay and laminar flamespeed data?=== | ||
+ | Yes. The mechanism tuning tool in CONVERGE 2.4+ can be used to optimize mechanisms to match ignition delay and laminar flamespeed data for multiple operating points. Please see the CONVERGE manual for more details. | ||
+ | ==CHEMISTRY TOOLS== | ||
+ | ===What can I do with CONVERGE’s chemistry tools?=== | ||
+ | The chemistry tools allow you to study reacting systems, manipulate mechanisms, and generate data tables needed for some simulations. | ||
+ | Examples: | ||
+ | *Blending surrogate fuels to match real fuel properties | ||
+ | *Reducing, tuning, and merging kinetic mechanisms to extend or alter their usage | ||
+ | *Calculating ignition delay (ID) and laminar flamespeed of combustible mixtures to examine flammability, compare different *fuel and oxidizer combinations, or evaluate kinetic mechanisms | ||
+ | *Creating laminar flamespeed tables for G-Equation and Extended Coherent Flamelet Model (ECFM) combustion models | ||
+ | *Creating ID tables for 3-Zone ECFM (ECFM3Z) combustion model | ||
- | === | + | ===Do I need a separate license to run CONVERGE’s chemistry tools?=== |
- | + | Running chemistry tools requires a valid CONVERGE license but it does not count as a license in use. | |
- | + | ||
- | |||
- | |||
- | + | ===Can I run 0D and 1D cases in parallel?=== | |
- | Yes | + | Yes, these cases can be distributed to run on different processors. However, a single case cannot be run on multiple processors. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | |||
- | |||
- | + | ===What can I calculate with 0D tools?=== | |
- | + | Zero-dimensional tools can be used to calculate the following quantities: | |
- | + | *Ignition delay or equilibrium conditions of a system | |
- | + | *Conditions in a homogeneous charge compression ignition (HCCI) engine | |
- | + | *Research octane number (RON) and motor octane number (MON) of a given fuel | |
- | + | *Ignition limits in flowing or well-mixed systems | |
- | + | *Ignition delay targets for mechanism tuning | |
- | + | *Speciation (calculated from flow reactor and shock tube equivalent simulations) | |
- | + | ||
- | + | ===What are some aspects of the 0D reactor modeled in CONVERGE?=== | |
- | + | Single cell calculations without CFD boundary conditions | |
+ | *Runs to a user-specified end time: Equilibrium, autoignition, specified time | ||
+ | *Mimics various processes | ||
+ | **For example, constant V, constant P and h | ||
+ | *Can account for mass flow rates | ||
+ | **Well-stirred reactor and plug flow reactor | ||
+ | *Can account for volume change | ||
+ | *Can account for wall heat transfer | ||
+ | [[File:control_volume.png]] | ||
- | + | ===Can the chemical equilibrium (CEQ) conditions be calculated via CONVERGE’s chemistry tools?=== | |
- | + | Yes, 0D chemistry tools can be used to quickly find the equilibrium conditions of a reacting system. CEQ can be found under two thermodynamic conditions: (1) constant enthalpy and constant pressure or (2) constant temperature and constant pressure. | |
- | |||
- | |||
- | + | ===What ignition delay (ID) definitions does CONVERGE use?=== | |
- | + | *Single ignition delay | |
+ | **The time (t) to raise the mixture temperature by 400 K | ||
+ | *Double ignition delay | ||
+ | **The first ignition delay (t1) is the time at which the first derivative of temperature with respect to time is at its maximum | ||
+ | **The second ignition delay (t) is the time to raise the mixture temperature by 400 K | ||
- | + | [[File:ignition_delay.png]] | |
- | + | ||
- | + | ===What does the 0D engine RON/MON estimator do?=== | |
- | + | The RON/MON estimator determines the octane numbers of a given fuel composition per ASTMD2699 and D2700 standards. | |
- | + | *For a given fuel, this tool finds the lowest compression ratio (critical compression ratio [CCR]) at which the mixture autoignites. | |
- | + | *This tool compares the CCR to the CCR values of primary reference fuels (PRF) to determine the octane rating. | |
- | + | ||
- | + | ||
- | + | ===Can I use chemistry tools to explore the flammability limits of a mixture?=== | |
- | + | Yes, you can use the 0D well-stirred reactor model to explore combustion and flammability limits in turbulent, well-mixed systems. | |
- | + | [[File:extiction.png]] | |
- | + | ===What quantities can I calculate with 1D tools?=== | |
- | + | You can use one-dimensional simulations to accomplish a variety of processes: | |
- | + | *Assess burning (laminar flamespeed) at certain mixture conditions | |
- | + | *Evaluate the performance of a reaction mechanism | |
+ | *Generate laminar flamespeed targets for mechanism tuning | ||
+ | *Develop laminar flamespeed tables necessary for some applications (TLF for ECFM, TLF for G-Equation, etc.) | ||
+ | *Complete laminar counterflow calculations, which determine the temperature and species between two inlet streams | ||
+ | ===Can I use chemistry tools to create laminar flamespeed tables?=== | ||
+ | Yes, the 1D solver can be used to create laminar flamespeed tables that can be used by many combustion models, including the G-Equation model, the Extended Coherent Flamelet Model (ECFM), the thickened flame model (TFM), and the Flamelet Generated Manifold (FGM) model. | ||
+ | |||
+ | The lookup table can store laminar flamespeeds as a function of unburned temperature, pressure, equivalence ratio, EGR fraction (constant by default or tracked as passives if spatial and/or temporal variation are needed, unburned fuel species (traced as passives). | ||
+ | |||
+ | CONVERGE Studio can generate input files that can be used to generate flamespeed tables. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | + | ===Can CONVERGE reduce kinetic mechanisms while conforming to ignition delay and laminar flamespeed targets?=== | |
- | + | Yes. With CONVERGE 3.0, the mechanism reduction tool can be used to reduce mechanisms while conforming to ignition delay and laminar flamespeed targets. In previous versions of CONVERGE only ignition delay targets can be used. | |
- | |||
- | |||
- | + | ===Can CONVERGE tune kinetic mechanisms to match ignition delay and laminar flamespeed data?=== | |
- | Yes. | + | Yes. The mechanism tuning tool can be used to optimize mechanisms to match ignition delay and laminar flamespeed data for multiple operating points. |
- | |||
- | |||
- | === | + | ===Can I use a chemistry tool to merge two chemical mechanisms?=== |
- | + | Yes. The mechanism merge tool can combine two reaction mechanisms to: | |
- | + | *Develop multi-component surrogate mechanisms, e.g., adding isooctane reactions to an n-heptane mechanism to develop a PRF mechanism | |
+ | *Add PAH or NOx chemistry to a fuel mechanism to add emissions prediction capability | ||
+ | *Add additional reaction pathways, e.g., adding more fuel reactions or additional pathways to secondary species to a skeletal mechanism | ||
- | + | It is important to validate the merged mechanism against available laminar flamespeed, species, and other data. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ===What is the surrogate blender?=== | |
- | + | CONVERGE Studio’s surrogate blender creates a multi-component fuel surrogate with specified physical properties. Since fuels consist of a mixture of several individual components, simulating a fuel as a single component can lead to errors. You can simulate fuels as multi-component surrogates whose properties (e.g., derived cetane number, molecular weight, H/C ratio) approximate those of the target fuel. | |
- | + | ==SPRAY== | |
- | + | ===What film splash models are available for aftertreatment simulations?=== | |
- | + | CONVERGE offers the O’Rourke, Kuhnke, and Bai-Gosman film splash models. For aftertreatment simulations, the Kuhnke model is commonly used. By altering model parameters like the rebound Weber number and non-dimensional critical wall temperature, you can alter model parameters to correlate the model to experimental results. The Wruck heat transfer model is also available to account for the Leidenfrost effect. | |
- | + | ||
- | |||
- | |||
- | + | ===To predict deposit formation, should I use the molten solid approach or detailed urea decomposition?=== | |
+ | In CONVERGE 2.4 and earlier, the molten solid approach was considerably less computationally expensive, and we recommended it for some aftertreatment applications. Because detailed decomposition of urea is as fast as molten solid decomposition in CONVERGE 3.0, we suggest using detailed decomposition and fixed flow to directly simulate the formation of species such as biuret, ammelide, and cyanuric acid (CYA). | ||
+ | |||
+ | |||
+ | ===Can CONVERGE write out important spray statistics such as SMD or mass flux from a Lagrangian spray simulation? === | ||
+ | |||
+ | CONVERGE 3.0 contains a built-in Phase Doppler Particle Analyzer (PDPA). CONVERGE will track particles passing through user-defined PDPA points and compute relevant statistics (Sauter mean diameter, velocity components, mass flux, etc.) for each PDPA monitor point. | ||
+ | |||
+ | ===I am simulating a symmetric multi-hole injector, but the spray penetration patterns from each nozzle are not identical. The spray plumes aligned with the grid seem to penetrate more than the non-aligned plumes. Why?=== | ||
+ | Depending on the flowfield, there are cases in which the spray plumes will not be identical even though the spray nozzles are symmetric. In other cases, where the spray is dominant and the plumes are expected to be similar, this phenomenon is caused by numerical viscosity associated with large computational cell sizes. A spray injected along the diagonal of a cubic cell is subjected to more numerical viscosity than a spray aligned with the edges of the cells. This effect diminishes as the cells are refined. For more information, please refer to the Convergent Science white paper on numerical viscosity. | ||
+ | |||
+ | In CONVERGE 3.0, you can specify a conical inlaid mesh along the axis of all nozzles. The inlaid mesh will minimize the uneven effects of numerical viscosity and produce more uniform plumes. Note that in some cases the non-uniformity of the flow will cause non-identical spray penetration for each of the plumes. This is a physical effect rather than a numerical one. | ||
+ | |||
+ | |||
+ | ===My spray simulation runs slowly due to significant wall film formation. Is there a way to increase the simulation speed?=== | ||
+ | CONVERGE 3.0 offers a parcel consolidation option in which parcels at boundary cells are combined to reduce simulation time. This option is appropriate for simulations that run slowly because they have so many parcels at the wall. | ||
+ | |||
+ | ===Can I run VOF one-way coupling on CONVERGE 3.0 with a VOF map file that was created with an older version of CONVERGE?=== | ||
+ | Yes, CONVERGE 3.0 can load a vof_spray.dat file that was written by an older version of CONVERGE as long as the Injector IDs and Nozzle IDs in the older files match the Injector Names and Nozzle Names in the 3.0 spray.in file. | ||
+ | |||
+ | ===What are the benefits of using inlaid mesh in spray simulations, and what are the limitations?=== | ||
+ | CONVERGE 3.0 simulations can include cells that are not part of the global Cartesian cut-cell mesh. These cells, which can be of arbitrary size, shape, and orientation, are referred to as inlaid cells. Inlaid cells can be used, for example, to create spray-aligned conical meshes or boundary layer meshes. A spray-aligned mesh will lower the numerical diffusion associated with mis-alignment of the Cartesian grid with the nozzle axis. The spray-aligned inlaid mesh is especially useful for multi-nozzle sprays and can preserve consistency across individual nozzles and predict a more accurate liquid and vapor penetration length. A boundary layer mesh can resolve the boundary layer structure with many fewer cells than a Cartesian cut-cell mesh would require. | ||
+ | |||
+ | Currently, AMR and moving boundaries are not permitted in inlaid cells. The inlaid mesh is defined as part of the geometry and it belongs to the surface file; therefore, the inlaid mesh cannot intersect with any other boundaries of the geometry. This also means that an inlaid mesh cannot be very close to moving boundaries that might intersect it. | ||
+ | |||
+ | ===Does CONVERGE provide any models for mimicking flash boiling sprays?=== | ||
+ | When modeling drop evaporation, CONVERGE 3.0 can apply a flash boiling model. CONVERGE can also reduce the drop size based on flash boiling. This feature can be activated in CONVERGE Studio via Case Setup > Spray modeling > Drop evaporation > Flash boiling. | ||
+ | |||
+ | ===Must I increase the number of spray parcels when I refine the grid?=== | ||
+ | Yes. If the cell size is reduced and the number of parcels stays constant, then the amount of liquid in a cell increases, which tends to artificially reduce the drag on the droplet. Each time the cell is refined one level (e.g., when amr_groups > amr_group > amr_* > embed_scale in amr.in changes from 2 to 3), you should increase the number of parcels injected by at least a factor of 4 (8 is even better but can get very computationally expensive for fine meshes). Please consult the following publication for more details: | ||
+ | *Senecal, P.K., Pomraning, E., Richards, K.J., and Som, S., “Grid-Convergent Spray Models for Internal Combustion Engine CFD Simulations,” Proceedings of the ASME 2012 Internal Combustion Engine Division Fall Technical Conference, ICEF2012-92043, Vancouver, BC, Canada, September 23-26, 2012. DOI:10.1115/ICEF2012-92043 | ||
+ | |||
+ | ===Which pressure should be used to calculate parcel velocities in the spray rate calculator?=== | ||
+ | In order to calculate the parcel velocities that come out of the nozzle hole, we recommend using the difference between the injector sack pressure and the back pressure (cylinder pressure). | ||
+ | |||
+ | |||
+ | ===In the Kelvin-Helmholtz model, is the shed mass constant applied only to parent parcels or is it applied to any droplets subjected to a breakup event?=== | ||
+ | The shed mass constant (in CONVERGE Studio, go to Case Setup > Physical Models > Spray modeling > Injectors > Models) is applied to all droplets in the domain that are undergoing KH breakup. | ||
+ | |||
+ | |||
+ | ===Does the Kelvin-Helmholtz model act only on parent parcels or does it also act on the first generation of child droplets (i.e., the droplets derived from the primary breakup)?=== | ||
The KH model acts on all drops. | The KH model acts on all drops. | ||
- | + | ||
+ | ===Is it correct to apply the Kelvin-Helmholtz model to the breakup of child droplets (i.e., not parent parcels), when the KH theory refers only to the disintegration of liquid jets (i.e., parent parcels)?=== | ||
The KH model assumes that the fastest growing surface wave is much smaller in magnitude than the surface on which it grows, and thus it does not matter if it grows on a liquid sheet, a ligament, or a spherical drop. | The KH model assumes that the fastest growing surface wave is much smaller in magnitude than the surface on which it grows, and thus it does not matter if it grows on a liquid sheet, a ligament, or a spherical drop. | ||
- | + | ||
+ | ===How are primary and secondary breakup simulated in the modified KH-RT model?=== | ||
Primary breakup is simulated via the KH model. For secondary breakup, the KH and RT models compete against one another. | Primary breakup is simulated via the KH model. For secondary breakup, the KH and RT models compete against one another. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | + | ===In the KH-RT model, which parameters can be adjusted to change the drop size?=== | |
- | CONVERGE | + | You can adjust several KH and RT parameters, but we recommend two of them as a starting point. In CONVERGE Studio, go to Case Setup > Physical Models > Spray modeling > Injectors. Click Edit to open the [Injector #] configuration dialog box. The parameters below are in that dialog box. |
+ | *RT model size constant (rt > size_const): Reduce this value to reduce the drop size. | ||
+ | *KH model breakup time constant (kh > time_const): Reduce this value to make drop breakup occur more quickly and to reduce the drop size. | ||
- | + | ===How are the blobs initialized when the injection drop distribution is based only on nozzle size and the discharge coefficient model uses a varying nozzle velocity coefficient?=== | |
- | + | CONVERGE dynamically calculates the velocity coefficient (Cv) based on the injection pressure at that time. CONVERGE then calculates the contraction coefficient (Ca) from Ca = Cd/Cv (Cd is user-specified). | |
- | ( | + | Once Ca has been calculated, CONVERGE calculates the effective diameter (deff) and effective area (Aeff) of the blob according to the following relationships: |
+ | <math>D_{blob}=d_{eff}=\sqrt{C_a}*d_0 </math> | ||
+ | |||
+ | |||
+ | <math>A_{eff}=C_a*A_0 </math> | ||
+ | |||
+ | In the equations above, <math>d_0 </math> and <math> A_0 </math> are the nominal diameter and nominal area of the blob. | ||
- | + | ===When should I use a spray-wall interaction model?=== | |
You should use a spray-wall interaction model whenever the spray impinges on a wall. | You should use a spray-wall interaction model whenever the spray impinges on a wall. | ||
- | + | ||
+ | ===Are there any guidelines on the meshing requirements for spray-wall interaction models?=== | ||
CONVERGE has no special meshing requirements for the spray-wall interaction models. You can use the typical grid recommendations. | CONVERGE has no special meshing requirements for the spray-wall interaction models. You can use the typical grid recommendations. | ||
- | |||
- | |||
- | |||
- | + | ===Can a single liquid parcel species evaporate into multiple gas-phase species?=== | |
- | Yes, this can be done using composites, which are composed of multiple base species. To set up composites in CONVERGE Studio, go to Materials > Composite species. | + | Yes, this can be done using composites, which are composed of multiple base species. To set up composites in CONVERGE Studio, go to Case Setup > Materials > Composite species. Please refer to the Engine sector diesel SAGE composite example case. |
- | + | ==AFTERTREATMENT AND UREA/SCR== | |
- | + | ===What new solver options are available in CONVERGE 3.0 for aftertreatment and gas turbine simulations?=== | |
- | + | CONVERGE 3.0 includes a pressure-based solver, which is a better option for steady-state gas turbine and aftertreatment simulations than the density-based solver. You can use either the PISO or SIMPLE algorithms in CONVERGE 3.0 for aftertreatment. | |
- | |||
- | |||
- | 3. | + | ===Can I run an SCR surface chemistry simulation in CONVERGE 3.0?=== |
- | CONVERGE | + | Yes. There are two ways to simulate SCR surface chemistry. CONVERGE 3.0 supports surface chemistry modeling, in which you can specify regions in which surface chemistry will be solved and configure washcoat properties. CONVERGE 3.0 can also couple with GT-SUITE to take advantage of the surface chemistry modeling capability of GT-POWER. |
- | |||
- | |||
- | + | ===How can I accelerate my aftertreatment simulation to predict deposit formation over the course of minutes?=== | |
- | + | For some continuous or pulsed spray simulations, the flow field may temporarily reach a pseudo steady-state. To reduce the total simulation time, CONVERGE 3.0 offers a fixed flow option that freezes the flow field while still solving the spray. When the flow field is frozen, the spray is one-way coupled to the flow (i.e., the spray reacts to the flow but the flow does not react to the spray). This approach greatly extends the time-step (CFL number) so that 30 to 60 seconds of simulation time can be achieved in a single day. | |
- | |||
- | + | ===I am looking at pressure drop and uniformity of my urea/SCR. Do I need to use fixed flow?=== | |
- | + | Prior to CONVERGE 3.0.15, fixed flow was reserved for filming and deposit simulations, which require a long time to fully develop. Fixed flow is not eligible for NH3/HNCO uniformity studies since species in the flow domain would be fixed when fixed flow is turned on. | |
- | + | However, in CONVERGE 3.0.15+, the species solver can be turned on when fixed flow is activated. This new feature allows uniformity studies to take full advantage of the fixed flow speedup. | |
+ | |||
+ | ===Can I use the steady solver for my urea/SCR simulation?=== | ||
+ | If your spray is steady, you can use the steady solver for aftertreatment simulations. If your spray is pulsed, however, you need to run a transient simulation with the high CFL transient default solver settings. These high CFL transient settings (via temporal_control > mult_dt_spray and temporal_control > max_cfl_u in inputs.in) can handle CFL values between 10 and 30. | ||
+ | |||
+ | ===What is the urea deposit risk UDF, and how does it compare to the urea detailed decomposition model?=== | ||
+ | The urea deposit risk user-defined function (UDF) is a highly empirical approach that considers the conditions of the film (e.g., temperature, film height, HNCO concentration in gas near film surface, etc.) that promote urea deposit formation. The urea deposit risk UDF requires calibration to experimental data to be predictive. In CONVERGE 3.0, the urea detailed decomposition is able to quantitatively predict deposit by-products mass and can run just as fast as the molten solid model. Thus we suggest using the urea detailed decomposition model. | ||
+ | |||
+ | |||
+ | ==VOLUME OF FLUID (VOF)== | ||
+ | ===Can CONVERGE apply its volume of fluid model for both compressible and incompressible fluids?=== | ||
+ | Yes. The VOF model in CONVERGE offers the Individual Species Solution (ISS) method and the Void Fraction Solution (VFS) method. The ISS, also known as compressible VOF, is good for compressible gases and compressible or incompressible liquids. The Void Fraction Solution method is good for incompressible gases and incompressible liquids. | ||
+ | |||
+ | |||
+ | ===In the VOF model, how does CONVERGE calculate the void fraction?=== | ||
+ | In the ISS method, i.e., compressible VOF, CONVERGE solves the individual species conservation equations and then calculates the void fraction from the cell mass fractions of liquid and vapor species. In the VFS method, or incompressible VOF, CONVERGE directly solves a transport equation for the void fraction. | ||
+ | |||
+ | |||
+ | ===Can CONVERGE predict the phase change of fluid due to flashing or cavitation?=== | ||
+ | Yes, the VOF model implements a homogeneous relaxation model (HRM) to predict the phase change of the fluid. | ||
+ | |||
+ | |||
+ | ===Can Adaptive Mesh Refinement be used in a VOF simulation to reduce computation time?=== | ||
+ | Yes. When performing a VOF simulation, it is important to invoke Adaptive Mesh Refinement (AMR) on both void fraction and velocity to accurately simulate the interface between the liquid and the vapor. VOF models typically require fine resolution and thus small time-steps. Using AMR to add resolution where necessary can reduce cell count and computational time. | ||
+ | |||
+ | |||
+ | ===Can CONVERGE accurately capture the location of the interface between the liquid and the gas?=== | ||
+ | The use of AMR allows CONVERGE to locate the interface, but the High-Resolution Interface Capturing (HRIC) and Piecewise Linear Interface Calculation (PLIC) schemes greatly enhance the sharpness of the interface. Use HRIC with compressible VOF and either HRIC or PLIC with incompressible VOF. | ||
+ | |||
+ | |||
+ | ===Can CONVERGE predict the atomization and evaporation of a liquid in a VOF simulation?=== | ||
+ | Predicting the atomization of the liquid in a VOF simulation requires (1) the Eulerian-Lagrangian Spray Atomization (ELSA) model, (2) the VOF one-way coupling approach, or (3) setting the grid size to be smaller than the size of the smallest droplets. The ELSA model automatically transitions Eulerian liquid to the Lagrangian parcel phase when the cell meets certain criteria. The VOF one-way coupling model initializes a Lagrangian parcel simulation using the data from a VOF simulation. In both cases, CONVERGE applies models for collision, drag, break-up, and evaporation to the Lagrangian parcels. | ||
+ | |||
+ | |||
+ | ==WALL HEAT TRANSFER== | ||
+ | ===If I am interested in filming and urea deposit formation, should I use conjugate heat transfer for wall modeling?=== | ||
+ | Yes. Conjugate heat transfer (CHT) is usually used for simulations with filming and Urea deposit formation. An accurate wall temperature prediction is crucial for filming simulations. Also, the Urea decomposition by-products formation is rather sensitive to the film temperature, which requires a high-fidelity wall temperature prediction. We recommend super-cycling in conjunction with the CHT model to allow the walls to reach thermal equilibrium faster. | ||
+ | |||
+ | |||
+ | ===How can I simulate thermal barrier coating using CONVERGE?=== | ||
+ | There are several ways to simulate thermal barrier coating (TBC) on a piston top. Here are a few options: | ||
+ | *A full 3D CHT simulation, where the TBC is simulated as well as the rest of the piston. In this type of simulation, the thickness of the coating needs to be resolved, which means that there needs to be a sufficient number of cells across the thickness of the coating. This type of simulation is very expensive because it requires many cells and small time-steps. | ||
+ | *A 3D CHT simulation plus contact resistance modeling, where the TBC is not simulated. In this type of simulation, the TBC is represented by a contact resistance on the surface of the piston and the rest of the piston is simulated. The contact resistance can be calculated based on the conductivity of the material used for the TBC and the thickness of the coating. The rest of the piston needs to be resolved. This type of simulation is more expensive than a gas-only internal combustion simulation but far less expensive than a full 3D CHT simulation. | ||
+ | *A 1D CHT boundary condition, where the piston is not resolved and the TBC is represented by a 1D CHT boundary condition on the piston surface. This type of simulation is generally as expensive as a gas-only internal combustion simulation. There is some loss of accuracy because the heat transfer using the 1D CHT boundary condition is assumed to be only in one direction. In addition, some information about the internal temperature of the piston needs to be provided, which is not always known. | ||
+ | |||
+ | ===Can CONVERGE seal surfaces on an INTERFACE?=== | ||
+ | At this time, CONVERGE does not allow sealing on an INTERFACE. | ||
+ | |||
+ | |||
+ | ===What interpolation method does CONVERGE use for spatial boundary condition profiles?=== | ||
+ | CONVERGE does not interpolate for spatial boundary condition profiles. Instead, CONVERGE obtains information from the nearest data point. | ||
+ | |||
+ | |||
+ | ===When I run a CHT case in CONVERGE 2.4, I see the following warning message: Problem with the number of regions in rank #. Is this a problem? === | ||
+ | This message is commonly seen in CHT simulations in CONVERGE 2.4. It does not indicate a problem. This message should not cause a crash or impact simulation results or runtime. | ||
+ | |||
+ | |||
+ | ===When I run a CHT case, my case crashes and I see the following error: The surface has a non-interface triangle that is only connected to a single interface triangle. What is the problem? === | ||
This error is often related to an incorrect INTERFACE assignment. An edge can be shared by two triangles only if both triangles are non-interface or if both triangles are interface. CONVERGE does not allow an edge to be shared by one interface triangle and one non-interface triangle. | This error is often related to an incorrect INTERFACE assignment. An edge can be shared by two triangles only if both triangles are non-interface or if both triangles are interface. CONVERGE does not allow an edge to be shared by one interface triangle and one non-interface triangle. | ||
- | + | ===When I run a CHT case, my case crashes and I see the following error: Neighboring triangles are associated with different streams. What is the problem?=== | |
This error is often associated with an INTERFACE boundary. For an INTERFACE boundary, the surface normal of all triangles in that boundary must point toward the same region and that region must be consistent with the information in the boundary definition file (in CONVERGE Studio, go to Boundary Conditions > Boundary to set up this region). You may see the error specified above if a single surface normal points in the wrong direction. | This error is often associated with an INTERFACE boundary. For an INTERFACE boundary, the surface normal of all triangles in that boundary must point toward the same region and that region must be consistent with the information in the boundary definition file (in CONVERGE Studio, go to Boundary Conditions > Boundary to set up this region). You may see the error specified above if a single surface normal points in the wrong direction. | ||
- | |||
- | |||
- | + | ===I am comparing heat transfer coefficients (HTCs) from CONVERGE with HTCs from other codes and they do not match. Why?=== | |
In CONVERGE, the HTC is a local value based on the near-wall cell temperature, not a free-stream temperature. This HTC differs from an HTC that is based on a user-specified reference temperature, and it also differs from an HTC that could be estimated from a Nusselt number correlation. Because HTC definitions vary from code to code and because CONVERGE uses local HTC values that depend on the near-wall mesh, we recommend instead comparing flux. | In CONVERGE, the HTC is a local value based on the near-wall cell temperature, not a free-stream temperature. This HTC differs from an HTC that is based on a user-specified reference temperature, and it also differs from an HTC that could be estimated from a Nusselt number correlation. Because HTC definitions vary from code to code and because CONVERGE uses local HTC values that depend on the near-wall mesh, we recommend instead comparing flux. | ||
- | |||
- | |||
- | + | ===Can we perform an all-in-one coolant/combustion/solid simulation?=== | |
- | CONVERGE allows super-cycling | + | Currently CONVERGE does not allow three phases in the same simulation and thus the coolant/combustion/solid combination is not allowed. This combination needs to be separated into two simulations (for example, a gas/solid CHT simulation and a liquid simulation). There is a Python script to automate the process of going back and forth between the two separated simulations. Please contact support@convergecfd.com if you need the script. |
+ | |||
+ | ===Can I use super-cycling for predicting a steady-state temperature field in a non-engine case? If so, how do I set supercycle_stage_num and supercycle_stage_interval?=== | ||
+ | CONVERGE allows super-cycling in non-engine cases. As long as the temperature of the solid part can be approximated as a steady state, you can use super-cycling to obtain a steady-state solid temperature distribution faster than in a typical transient simulation. | ||
+ | |||
+ | If the simulation has temporally periodic variation in its behavior (for example, as in an engine), supercycle_stage_num*supercycle_stage_interval must equal the cyclic period. For example, you may have a nozzle in a tunnel that is spraying water into the air flow for 1 minute in every 10 minutes. You can set supercycle_stage_num = 1 and supercycle_stage_interval = 10 minutes to obtain a steady-state temperature distribution in the solid tube wall through super-cycling. This configuration would average the heat transfer information for the full 10 minutes into one representative average and then perform the super-cycle calculation just once in every 10-minute period. Alternatively, you could set supercycle_stage_num = 5 and supercycle_stage_interval = 2. For this configuration, the average heat transfer information would be stored in 2-minute segments and CONVERGE would perform super-cycling 5 times in every 10-minute period. | ||
+ | If the entire simulation is steady-state (both the fluid dynamics and solid portions), then there is no reason to use more than one stage for averaging the heat transfer information. In this case, set supercycle_stage_num = 1, and then choose the supercycle_stage_interval to be the window size for calculating the average heat transfer information used in super-cycling. | ||
+ | |||
+ | ===What is the convection temperature boundary condition?=== | ||
+ | In CONVERGE, you can set a convection boundary condition for either a solid or a fluid WALL boundary. In either case, the convection boundary condition prescribes the convection between the wall and the environment (note that the environment is not included in the computations). | ||
+ | |||
+ | |||
+ | ==OPTIMIZATION== | ||
+ | ===How many simulations are typically required when optimizing an engine case in CONVERGE using the genetic algorithm utility CONGO?=== | ||
+ | We recommend 50-100 generations, which would be about 800 simulations, for an optimization including 5-10 parameters. | ||
+ | |||
+ | |||
+ | ===Is optimizing a mechanism using the mechtune capability similar to optimizing a CFD case?=== | ||
+ | Yes, a genetic algorithm with CONGO can be used for mechanism optimization. The mechtune capability in CONVERGE creates input files for CONGO. We recommend a minimum of 2000 generations for a mechanism tune case (~16,000 ignition delay/flamespeed simulations) | ||
+ | |||
+ | See the following paper for a demonstration of this capability: | ||
+ | *Mittal, A., Wijeyakulasuriya, S.D., Probst, D., Banerjee, S., Finney, C.E.A., Edwards, K.D., Willcox, M., and Naber, C., "Multi-Dimensional Computational Combustion of Highly Dilute, Premixed Spark-Ignited Opposed-Piston Gasoline Engine using Direct Chemistry with a New Primary Reference Fuel Mechanism," ASME 2017 Internal Combustion Engine Division Fall Technical Conference, ICEF2017-3618, Seattle, WA, United States, Oct 15–18, 2017. DOI: 10.1115/ICEF2017-3618 | ||
+ | |||
+ | ===Is it possible to optimize geometry features in CONVERGE?=== | ||
+ | Yes, this capability is a strength of CONVERGE. Because CONVERGE creates the mesh at runtime, modifying the geometry in optimization is straightforward. The surface file can be parameterized using CAD or a number of third-party geometry-modifying software packages. More information is available from the following resources: | ||
+ | |||
+ | *Pei, Y., Pal, P., Zhang, Y., Traver, M., Cleary, D., Futterer, C., Brenner, M., Probst, D., and Som, S., "CFD-Guided Combustion System Optimization of a Gasoline Range Fuel in a Heavy-Duty Compression Ignition Engine Using Automatic Piston Geometry Generation and a Supercomputer," SAE Paper 2019-01-0001. DOI: 10.4271/2019-01-0001 | ||
+ | *Automated Optimization Workflow for a Diesel Piston Bowl Using CAESES and CONVERGE CFD” webinar recording, available on the CAESES website. | ||
+ | |||
+ | ===How can machine learning be used to enhance optimization of CONVERGE cases?=== | ||
+ | Machine learning can be used to build an emulator for CFD using design of experiments data to characterize the design space. The machine learning emulator can then be used for optimization, sensitivity, and uncertainty quantification. Several journal papers have demonstrated this potential (including the two listed below). Please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)]. | ||
+ | |||
+ | *Moiz, A.A., Pal, P., Probst, D., Pei, Y., Zhang, Y., Som, S., and Kodavasal, J., “A Machine Learning-Genetic Algorithm (ML-GA) Approach for Rapid Optimization Using High-Performance Computing,” SAE Paper 2018-01-0190. DOI:10.4271/2018-01-0190 | ||
+ | *Probst, D.M., Senecal, P.K., Qian, P.Z., Xu, M.X., and Leyde, B.P., "Optimization and Uncertainty Analysis of a Diesel Engine Operating Point using CFD," Proceedings of the ASME 2016 Internal Combustion Engine Division Fall Technical Conference, ICEF2016-9345, Greenville, SC, United States, Oct 9–12, 2016. DOI: 10.1115/ICEF2016-9345 | ||
+ | |||
+ | ===Does CONVERGE / CONGO include machine learning capability for optimization?=== | ||
+ | No, machine learning capability is not included in CONVERGE or CONGO, but many third-party packages can be used. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==OTHER TOPICS== | ||
+ | ===How can I accelerate my CONVERGE 3.0 steady-state simulations? Will they be faster than steady-state simulations run in previous versions?=== | ||
+ | Some cases may be able to use larger pseudo-time-steps and achieve faster solutions by using the SIMPLE algorithm and pressure-based solver in CONVERGE 3.0. Another improvement is that in CONVERGE 3.0 you can have a split steady-state monitor approach: you can define looser criteria for auto-grid scaling and auto start of Adaptive Mesh Refinement than the final convergence criteria. For example, you can have convergence on NOx and CO only in your final convergence criteria so you don’t spend time during grid scaling waiting for those variables to reach steady values. CONVERGE 3.0 scales significantly better than previous versions, and these improvements will help accelerate your parallel steady-state simulations. | ||
+ | |||
+ | |||
+ | ===How can I accelerate my CONVERGE 2.4 steady-state simulations?=== | ||
+ | The steady-state solver in CONVERGE 2.4 is a density-based pseudo-time-stepping solver that can be used for solving a wide range of steady flow simulations (internal/external flows, combustion, sprays and films, CHT, MRF, surface chemistry, etc.). The solver allows the use of higher CFL numbers and also automated solver control for certain simulation parameters (CFL numbers, solver tolerances, and grid sizes). Both of these features help reduce the computation cost of your simulation. | ||
+ | |||
+ | Please consult the CONVERGE 2.4 Manual for recommended parameters for steady-state simulations. Remember that these values may require modification for some cases. Some general recommendations are given below. | ||
+ | |||
+ | We recommend initiating your steady simulation with a relatively coarse grid (grid_scale = -1 or -2 in inputs.in), so as to allow the initial transients to be rapidly flushed out of the domain. Time-based or automated grid scaling should be used, although care should be taken to ensure that the grid always remains adequately refined in regions in which the flow is complex. The maximum CFL number can be set to approximately 20 to 30 for non-reacting flows and approximately 10 to 15 for reacting flows. If the solver has excessive recoveries, you can reduce the maximum CFL number. If automated control is activated, the solver will perform this action on its own. Monitoring a few flow variables is useful for determining convergence in a steady simulation and can be used for automatically controlling grid scaling or solver settings. We recommend monitoring variables at OUTFLOW boundaries (temperature, mass flow rate, and species concentration), within the domain (maximum, minimum, and mean pressure and temperature; species concentration; and spray mass), or at monitor points (velocity, pressure, and temperature). The initial velocities and pressures and the corresponding INFLOW boundary conditions should be as consistent as possible. For instance, if the inflow velocity is 1 m/s, then the initial condition should be 1 m/s as well. | ||
+ | |||
+ | |||
+ | ===What solver option is recommended for pressure in steady-state simulations?=== | ||
+ | We recommend CONVERGE BiCGSTAB with the SOR preconditioner as the go-to pressure solver option in steady-state simulations. | ||
+ | |||
+ | |||
+ | ===What convective flux schemes are available in CONVERGE 3.0?=== | ||
+ | CONVERGE 3.0 includes three different varieties of the MUSCL scheme (Monotonic Upstream-Centered Scheme for Conservation Laws). The MUSCL_CVG option includes a 3D gradient-based slope limiter (the minmod method of Barth and Jespersen or the venkatak method of Venkatakrishnan). The MUSCL scheme can be very useful for supersonic flows and for obtaining second-order upwinding. | ||
+ | |||
+ | |||
+ | ===For LES simulations, how can I obtain second-order in time?=== | ||
+ | Setting Numerical_schemes > implicit_fraction = 0.5 in solver.in yields the Crank-Nicholson time-marching scheme, which is second-order in time for the momentum equation. Please be sure temporal_control > max_cfl_u in inputs.in is less than 1.0. | ||
+ | |||
+ | |||
+ | ===What are YAML-compliant input files?=== | ||
+ | CONVERGE 3.0 input files are YAML-compliant. YAML is a standardized plain-text format that offers more flexibility than the input file format of CONVERGE 2.4-. See the CONVERGE 3.0 Manual (Chapter 23 - Input and Data Files) for more details about YAML-compliant input files and for details about each input and data file. Because of the change in file format from CONVERGE 2.4 to CONVERGE 3.0, we strongly recommend using CONVERGE Studio 3.0 to set up new cases or to convert input files from previous versions. | ||
+ | |||
+ | |||
+ | ===How can I update the input files of a simulation from an older version of CONVERGE to a newer version?=== | ||
+ | We recommend using CONVERGE Studio to automatically convert input files from an older version of CONVERGE. Open CONVERGE Studio 3.0 and go to File > Import > Import input file(s). CONVERGE Studio will convert your files to version 3.0. You can then export these version 3.0 files in CONVERGE Studio and use them in a CONVERGE 3.0 simulation. | ||
+ | ===How does CONVERGE store the surface geometry file?=== | ||
+ | CONVERGE 3.0 stores the surface geometry on each compute node rather than on each core. Node-based storage reduces the memory requirement without affecting computational performance. This memory savings can be significant for geometries with a large triangle count and will be more significant in HPC systems with a larger number of cores per node. | ||
+ | |||
+ | ===Can the motion of boundaries be linked for the simplicity of the case setup?=== | ||
+ | Starting in CONVERGE 3.0 you can set up a moving WALL boundary and link to it the motion of other WALL boundaries. | ||
+ | |||
+ | |||
+ | ===In a periodic simulation, do the periodic matching directions have to be aligned with a coordinate axis? === | ||
+ | Starting in CONVERGE 3.0, the periodic matching directions do not need to be coordinate-aligned, periodic faces do not need to be planar, and a case can have multiple periodic matching directions. In CONVERGE 2.4, the rotational periodic boundaries were limited by z as the axis of rotation, xz as symmetry plane, and planar faces. Also, periodicity could be enforced in only two directions in translational periodic cases. | ||
+ | |||
+ | |||
+ | ===My therm.dat file contains multiple entries of the same species. Which entry does CONVERGE use?=== | ||
+ | CONVERGE uses the first entry and ignores any subsequent entries for that species. If you validate your therm.dat file in CONVERGE Studio before running a simulation, CONVERGE Studio will offer several ways to resolve duplicate entries. | ||
+ | |||
+ | |||
+ | ===Why don’t results from one version of CONVERGE always match results from an older version of CONVERGE?=== | ||
+ | Each version of CONVERGE contains enhancements and bug fixes, and these changes may affect simulation results. Please see the release notes (available on hub.convergecfd.com/downloads) for specific information about changes to each version of CONVERGE. If you have specific questions about why results may have changed or how to more closely match results from a previous version, please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)]. | ||
+ | |||
+ | |||
+ | ===My RANS simulation shows cycle-to-cycle variation. Is this variation to be expected?=== | ||
+ | Yes. A well-resolved unsteady RANS simulation does not necessarily eliminate all perturbations and thus can predict cyclic variations. An example of this phenomenon is GDI engines that show high cycle-to-cycle variation in measured cylinder pressure data. The following publications contain details on this topic. | ||
+ | *Jupudi, R., Finney, C., Primus, R., Wijeyakulasuriya, S., Klingbeil, A.E., Tamma, B., and Stoyanov, M.K., “Application of High Performance Computing for Simulating Cycle-to-Cycle Variation in Dual-Fuel Combustion Engines," SAE Paper 2016-01-0798, 2016. DOI:10.4271/2016-01-0798 | ||
+ | |||
+ | *Richards, K., Pomraning, E., Senecal, P.K., Scarcelli, R., and Wallner, T., “Cyclic Variation in Unsteady RANS Engine Simulations,” International Multidimensional Engine Modeling Users’ Group Meeting at the SAE Congress, Detroit, MI, United States, April 20, 2015. | ||
+ | |||
+ | *Richards, K., Probst, D., Pomraning, E., Senecal, P.K., and Scarcelli, R., “The Observation of Cyclic Variation in Engine Simulations When Using RANS Turbulence Modeling,” Proceedings of the ASME 2014 Internal Combustion Engine Division Fall Technical Conference, ICEF2014-5605, Columbus, IN, United States, October 19-22, 2014. | ||
+ | |||
+ | *Scarcelli, R., Matthias, N.S., and Wallner, T., “Numerical and Experimental Analysis of Ignition and Combustion Stability in EGR Dilute GDI Operation,” Proceedings of the ASME 2014 Internal Combustion Engine Division Fall Technical Conference, ICEF2014-5607, Columbus, IN, United States, October 19-22, 2014. | ||
+ | |||
+ | *Scarcelli, R., Richards, K., Pomraning, E., Senecal, P.K., Wallner, T., and Sevik, J., “Cycle-to-Cycle Variations in Multi-Cycle Engine RANS Simulations," SAE Paper 2016-01-0593, 2016. DOI:10.4271/2016-01-0593. | ||
+ | |||
+ | *Scarcelli, R., Sevik, J., Wallner, T., Richards, K., Pomraning, E., and Senecal, P.K., “Capturing Cyclic Variability in EGR Dilute SI Combustion Using Multi-cycle RANS,” Proceedings of the ASME 2015 Internal Combustion Engine Division Fall Technical Conference, ICEF2015-1045, Houston, TX, United States, November 9-11, 2015. | ||
+ | |||
+ | ===How do I obtain more repeatable answers from my RANS multi-cycle simulation?=== | ||
+ | By changing some numerical settings, you can force predictions to be more repeatable. Increasing numerical viscosity in the solution will dampen perturbations. Increasing cell sizes and using lower-order discretization schemes can increase the repeatability of a solution. It is important to note, however, that these changes may reduce accuracy. | ||
+ | |||
+ | |||
+ | ===Are closed-cycle simulations sufficient for modeling diesel engines?=== | ||
+ | It is important to simulate the induction in order to accurately characterize the velocity field. It is possible to run the intake simulation and map that solution at IVC for the closed-cycle simulation rather than assuming constant initial flow conditions. | ||
+ | |||
+ | |||
+ | ===How do I find Convergent Science’s recommended settings for different types of simulations?=== | ||
+ | Please refer to the example cases. In CONVERGE Studio, go to File > Load example case. These cases are also available at hub.convergecfd.com/downloads (login required). | ||
+ | |||
+ | |||
+ | ===Does Convergent Science recommend running an LES simulation at RANS grid settings?=== | ||
+ | No. An LES simulation will usually require smaller cell sizes. | ||
+ | |||
+ | |||
+ | ===What are some of the pre-processing requirements and recommendations for a four-stroke engine surface data file?=== | ||
+ | We recommend moving the piston to BDC (note that the piston must be at BDC if you are using a CONVERGE-calculated piston motion profile). | ||
+ | *The valves must be open and at minimum lift | ||
+ | *We recommend aligning the cylinder axis with the z axis. | ||
+ | *We recommend that the fire deck be at z = 0.0. | ||
+ | *Ensure sufficient resolution for the surface triangulation. | ||
+ | *We recommend using the Validate all button in CONVERGE Studio to check for errors. After you press this button, any issues will be listed in the Case Setup Issues log. | ||
+ | |||
+ | ===My case crashed due to a problem with sealing. What should I do?=== | ||
+ | Check the following items. | ||
+ | *The moving part and the seal-to part should not intersect during the entire process. | ||
+ | *The moving part and the seal-to part should be aligned in the moving direction and in the azimuthal direction. | ||
+ | *The gap between the moving part and the seal-to part should be smaller than the sealing tolerance by about one order of magnitude. | ||
+ | *The sealing tolerance should not be too large. (Typical sealing tolerances are 0.01 to 0.1 mm for an engine case.) | ||
+ | CONVERGE contains a sealing test utility (converge –l) that allows you to quickly identify errors in the sealing setup. For more information about this tool, please consult the CONVERGE Manual. | ||
+ | |||
+ | ===When do you recommend using the real gas equation of state?=== | ||
+ | We recommend the real gas equation of state for all simulations. | ||
+ | |||
+ | |||
+ | ===Can I use multiple boundary embeddings for the same boundary at different times?=== | ||
+ | CONVERGE does not allow multiple boundary embeddings for a single boundary. You can, however, accomplish the same effect by adding a box or cylinder embedding. | ||
+ | |||
+ | |||
+ | ===Can I set up monitor points that move with the piston or other moving boundaries in my simulation?=== | ||
+ | Yes. CONVERGE 2.4+ contains a monitor points option in which points assigned to a moving boundary will move with that boundary. To set up this feature in CONVERGE Studio, go to Output/Post-Processing > Monitor points. | ||
+ | |||
+ | |||
+ | ===How do I obtain the desired compression ratio?=== | ||
+ | CONVERGE Studio 2.4+ contains a compression ratio calculator (go to Applications > IC engine > Compression Ratio). You can also use this tool to move the piston to a location that yields the desired compression ratio. If you are using CONVERGE Studio 2.3 or earlier, please consult Chapter 19 of the CONVERGE 2.3 Manual for directions on calculating the compression ratio and moving the piston to the desired location. | ||
- | + | Please note that the CR calculation tool assumes that all the valves are closed at both TDC and BDC. If any of the valves are open at these times, the calculated CR will not match the experimental data. | |
- | + |
Latest revision as of 15:51, 10 August 2020
We hope you find the following FAQ helpful. For more information about many of the topics listed here, please review the CONVERGE documentation available on download.convergecfd.com (login required). In particular, the CONVERGE Manual, CONVERGE Studio Manual, Getting Started Guide, and training slides may be especially helpful. In addition, the example cases (each consisting of a surface geometry and input parameters) in CONVERGE Studio can provide a useful starting point for your own cases.
INSTALLING AND RUNNING CONVERGE
What are the hardware and software requirements for CONVERGE and CONVERGE Studio? How do I install CONVERGE or CONVERGE Studio?
Please refer to the Getting Started Guide for hardware and software requirements, installation instructions, and other related information.
Should I enable hyper-threading for my CONVERGE simulation?
CONVERGE, like other software packages that are designed to run on a large number of cores, does not run as efficiently when hyper-threading is enabled. This is true even when the number of processes in a simulation does not exceed the number of physical cores on the machine. For best performance, disable hyper-threading before running a CONVERGE simulation.
On Linux, what does the File locking failed in ADIOI_Set_lock</code error message mean? On Windows, what does failed MPI_fopen() mean?
These error messages apply only to CONVERGE 2.4 or earlier versions. On a Linux machine, this error may be the result of MPI interacting with an NFS-mounted file system. To be able to use mpi_write_flag = 1 (available in CONVERGE 2.4 and earlier versions) on an NFS-mounted file system, use NFS version 3.0+ and ensure that the client machine is mounted to the file system with the noac (no attribute caching) option.
I see that CONVERGE offers various MPI implementations (MPICH2, HPMPI, OPEN MPI, PMPI). Which one should I use?
For version 2.4 and earlier, based on some internal testing of ICE cases, we have found that OpenMPI may be the fastest. However, OpenMPI is not always forward/backward compatible. Different major CONVERGE versions may require different OpenMPI installations. PMPI gives the best compatibility across different versions. Please note that results may vary due to different release versions of each MPI implementation.
For CONVERGE 3.0, the MPI packages are shipped with the installation package to reduce the likelihood of compatibility issues. If you have your own implementation of an MPI package, we recommend using that instead (refer to the Getting Started Guide for supported MPI versions). Otherwise, you can use any of the MPI packages shipped with the installation package. For better scalability on machines with a high-speed interconnect, we recommend using Intel MPI.
Can CONVERGE run on GPUs?
Currently the CONVERGE solver does not run on GPUs. Convergent Science engineers are actively working on porting portions of the solver to use GPUs.
COMPUTATIONAL SPEED, MESH AND LOAD BALANCING
How does y+ AMR restriction work? Can I use this feature to ensure I have an acceptable mesh near the wall for the law-of-the-wall models?
CONVERGE has an option for y+ AMR restriction, which can restrict AMR cells close to the wall. You specify the target y+ and y+ ratio for this feature:
- y+ target: If the y+ value of a cell near the specified boundary is less than the specified target, then at that time-step CONVERGE will remove one level of refinement from that cell. CONVERGE does not remove more than one level of refinement in a single time-step even if the resulting y+ value is still less than the target. It is important to ensure that the target y+ value is based on the turbulence model in your simulation.
- y+ ratio: If the y+ value of a cell near the specified boundary is less than the product of the y+ target and the y+ ratio, then at that time-step CONVERGE will remove one level of refinement on all of the neighboring cells whose AMR level is equal to or greater than that of the original cell. CONVERGE does not remove more than one level of refinement in a single time-step even if the resulting y+ value is still less than the product of the y+ target and the y+ ratio.
You can use y+ AMR restriction to ensure that the mesh near the wall will be sufficient for a law-of-the-wall model.
What is the maximum allowed level of AMR?
While there has never been a strict limitation on the maximum number of AMR refinements (AMR level) in CONVERGE, load balancing has limited the practical number of AMR levels. CONVERGE 3.0 load balances by cell, not by parallel block, and load balancing no longer establishes this practical limit. You can apply as many levels of AMR or fixed embedding as are required to resolve the flow physics of interest, although extremely small cells will limit the maximum time-step.
How do the scalability improvements in CONVERGE 3.0 affect my simulations?
The key improvements for scalability in CONVERGE 3.0 are the ability to get good scaling with a low per-core cell count (fewer than 1,500 cells per core) and the ability to efficiently run one simulation on thousands of cores. These are substantial improvements over previous versions of CONVERGE, which does not scale effectively on fewer than tens of thousands of cells per core.
Can I run cases with hundreds of millions of cells in CONVERGE on my HPC?
CONVERGE 3.0 has substantial RAM reductions that now allow simulations of hundreds of millions of cells on typical HPC RAM configurations. Memory requirements are substantially reduced. RAM use has been reduced by a factor as much as 2.5 compared to previous versions of CONVERGE.
Can I import my native CAD files directly into CONVERGE?
Yes, CONVERGE 3.0 integrates the Spatial software package for direct import of most native CAD files. Previous versions of CONVERGE required a STL triangulation of the surface. The Spatial import offers a resolution setting (coarse, medium or fine) for the interpolation of the CAD geometry to a triangulated surface in CONVERGE. The previous STL workflow is still supported.
What is the best way to extract aero-volume from a CAD geometry?
The most direct approach is to use a CAD tool such as NX, Solidworks, or whatever was used to create the surface. You can import the STL file (or use Spatial to read in CAD file) into CONVERGE Studio and delete the solid surfaces (if conjugate heat transfer is not part of the simulation). A more sophisticated workflow is required when the geometry is complex and includes minute details such as nuts, bolts or holes that are not a part of the fluid/aero volume.
How would having inlaid cells in my domain affect the load balancing in CONVERGE 3.0?
Inlaid cells are treated the same as Cartesian cells when it comes to load balancing. This means that regardless of how fine the inlaid mesh is, the load balancing will be as efficient as it would without the inlaid cells. For reasons other than load balancing, a simulation with inlaid mesh can be slightly slower than the similar case without the inlaid mesh, but it is not related to the load balancing. On the other hand, the inlaid mesh case may be faster if the inlaid mesh feature allows for a lower cell count.
Does CONVERGE have cell-based load balancing?
CONVERGE 3.0 partitions the domain on a cell-by-cell basis. Previously, domain partitioning was done on blocks coarser than the largest cell in the domain. Note that these changes remove our longstanding recommendation that you limit the number of embed levels to ensure good load balancing. Now cell-based load balancing can balance the computational load more equally for a large number of cores.
Is there any difference between the way paired cells are shown in 3D post-processing of CONVERGE 3.0 and earlier simulation results?
In CONVERGE 3.0, paired cells are shown as merged, whereas previous versions showed paired cells separately.
Why do I get different cell counts for similar CONVERGE 2.4 and 3.0 simulations?
In CONVERGE 3.0, the paired cells are counted as one. In CONVERGE 2.4 and older, the paired cells were counted individually. You can set legacy_cell_count = 1 in hidden.in to make a direct cell count comparison with legacy versions.
Can CONVERGE automatically match the cell sizes on a Cartesian-inlaid mesh interface?
CONVERGE offers an inlaid mesh neighbor type of AMR. This AMR type refines the mesh on the Cartesian side based on the cell size discrepancy between neighboring cells on either side of the INTERFACE boundary separating the inlaid and the Cartesian mesh.
Can CONVERGE automatically improve the quality of the mesh in tight gaps?
CONVERGE offers a proximity-based type of AMR. This refines the mesh in tight gaps such as those in rotating machinery.
Are there any new types of AMR available in CONVERGE 3.0?
In addition to existing options such as temperature and velocity, there are four new options:
- Pressure
- Density
- Inlaid neighbors
- Proximity-based
In addition to these conventional sub-grid-scale AMR types, you can define AMR based on the value of a flow variable, e.g., void fraction in a VOF simulation. Value-based AMR is generally not self-limiting (e.g., subdividing a cell based on the void fraction may produce child cells with approximately the same void fraction), so we recommend that you apply it sparingly.
What is an inlaid mesh? What versions of CONVERGE support them?
In CONVERGE 2.4 and earlier, the entire domain is subdivided by the automatically generated Cartesian cut-cell mesh. CONVERGE 3.0 can also solve cells that are constructed and inlaid within the octree cells. These are referred to as inlaid cells. Inlaid cells have a prescribed shape, size, and orientation. They can be used, for example, for boundary layer meshes or spray-aligned conical meshes. This feature allows the import of any grid to be used in conjunction with the typical CONVERGE Cartesian grid. You can also construct inlaid meshes in CONVERGE Studio. Note that inlaid meshes do not currently support AMR or fixed embedding, and they cannot move or contact a moving boundary.
Is the inlaid mesh automatically created at the start of simulation or during pre-processing?
Inlaid meshes are created during pre-processing in CONVERGE Studio. The inlaid mesh is defined as part of the geometry, and it belongs to the surface file.
How do I set up an inlaid mesh with CONVERGE 3.0?
Most inlaid meshes are constructed in CONVERGE Studio. First, create the inlaid mesh with the help of Studio by going to Geometry > Inlaid mesh > Shaped mesh/Extrusion. Then, set up the correct boundary conditions for all surfaces belonging to the user-made mesh. Additionally, CONVERGE 3.0 offers the capability to read in stationary meshes from other software packages in Plot3D format.
Can an inlaid mesh in CONVERGE 3.0 be attached to a moving boundary?
Inlaid meshes can be used in a simulation that has moving boundaries, but the inlaid mesh cannot be attached to a moving boundary or interacting with a moving boundary.
How can I find more information about inlaid mesh and boundary layer mesh feature?
More information can be found in CONVERGE 3.0 Manual (chapter 6). For additional assistance, please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)].
My simulation runs slowly. How can I identify the cause?
A simulation might run slowly for a variety of reasons. First, look at the log file (or at time.out) to see what is limiting the time-step. If output_control > log_level = 3 in inputs.in, CONVERGE records in the log file and in time.out the time spent on each major routine (combustion, spray, load balancing, moving grids, etc.). These data can shed some light on the slowdown. Some common causes for a slow simulation are: too many parcels in a spray simulation, a large chemical mechanism in a combustion simulation, or a misconfigured cluster interconnect. CONVERGE 2.4 and earlier were susceptible to poor load balancing. CONVERGE 3.0 almost always load balances well. You can review cell_count_ranks.out to understand and determine how to improve the load balancing.
The time-step in my simulation is limited by max_cfl_u. How can I accelerate my simulation?
When the variable time-stepping algorithm is used, CONVERGE controls the time-step by the user-specified CFL numbers (among other limiting criteria). When the convective CFL number limits the time-step, it may be due to small cell sizes or high flow velocities. You can use a region- and temporal-based CFL number to increase the time-step when important events are not occurring. For example, set temporal_control > max_cfl_u = 1 in inputs.in during combustion and increase it during the exhaust phase. Refer to the SI8 engine PFI SAGE example case (in CONVERGE Studio, go to File > Load example case) to see a demonstration of this technique. Turning off embedding during less important times of the simulation (or in less important parts of the domain) may also help alleviate this restriction.
How can I speed up my multiple-cycle engine simulations?
CONVERGE features such as skip species, region- and temporal-based convective CFL number, and region- and temporal-based AMR can speed up multi-cycle engine simulations. The SI8 engine head CHT steady RANS example case includes these features.
My simulation slows down significantly when spray starts. What should I do?
A slowdown when the spray starts is expected, but there are some steps to take if you are concerned. First, check if the total number of injected parcels (num_parcels_per_nozzle) is set based on the recommended criterion for your grid size. Note that the specified number of parcels in spray.in is for a single nozzle, while the injected mass is for the entire injector. If you dramatically reduce the number of parcels, you should check how sensitive the predictions are relative to the injected number of parcels. If collision is turned on, verify that multiple nozzles do not reside in a single cell.
My turbomachinery simulation time-step is limited by dt_move. How can I make this simulation run faster?
A time-step limited by dt_move is a typical bottleneck in high speed turbo-machinery simulations. This time-step limit was put in place primarily for stability reasons. There are two options to try to get around this bottleneck and speed up your simulation: increase the cell sizes at the moving boundaries or relax the dt_move constraint. Note that either of these workarounds can affect the solution accuracy and stability.
The swept cell volume of any moving boundary is limited to a portion of cell in a single time-step. The default value in CONVERGE is 0.5 (i.e., in a single time-step, the moving boundary cannot sweep more that 50% of the smallest cut-cell volume). You can use values greater than 1.0, although higher values might affect solution stability or accuracy. To change this value in CONVERGE Studio 2.4+, go to Simulation Parameters > Simulation time parameters > Moving boundary time-step multiple.
Will the triangle count in my CAD file affect my simulation’s runtime?
Yes, especially for cases with moving boundaries. CONVERGE generates the grid at each time-step, and there is a computational cost in trimming Cartesian fluid cells. If a geometry contains an unnecessarily high triangulation, we recommend coarsening the surface to reduce the number of triangles while retaining the surface features. CONVERGE Studio contains a coarsening tool.
Think of it this way: a rectangle can be defined by two triangles. Alternatively, a poor CAD algorithm can define a rectangle of the same area by 1 million small triangles. This huge triangle addition can slow down simulations. For typical engine geometries, keep the triangle count around 0.3 to 0.5 million.
By looking at cell_count_ranks.out, it is clear that the load balancing of my simulation is not optimal. How can I improve the load balancing?
CONVERGE 2.4 and earlier distribute blocks of cells rather than individual cells. A value of parallel_scale = -1 in inputs.in yields the highest number of blocks for domain decomposition. Try increasing parallel_scale (e.g., from -2 to -1). Also, larger embed scales in fixed embedding and AMR can make load balancing difficult, and thus reducing the embed scale and the base mesh size can allow you to achieve better load balancing while maintaining the same smallest cell size. Even though this approach will increase the total number of cells, the case may run faster due to better load balancing. Chapter 11 in the CONVERGE 2.4 Manual gives an example of how reducing the base mesh size can reduce the cell count on the highest-loaded rank.
In CONVERGE 3.0, the load balancing is based on cells. This means that, regardless of embed levels set for fixed embeddings and AMR, the solver can almost perfectly distribute the cells between the cores. The solver will automatically redo the load balancing, when the ratio of max cell in a rank to average cells per rank exceeds the simulation_control > imbalance_factor in inputs.in. CONVERGE 3.0 rarely load balances poorly.
What is the non-transport passive CHEM_STIFF?
CONVERGE allows the use of stiffness-based load balancing for simulations that use the SAGE detailed chemistry solver (stiffness-based load balancing is required for SAGE simulations without adaptive zoning and optional for SAGE simulations with adaptive zoning). Any simulation that uses stiffness-based load balancing must contain the non-transport passive CHEM_STIFF in the species.in file.
My simulation spends quite a bit of time on load balancing. Why?
For CONVERGE 2.4 and earlier, if a significant amount of time is spent on load balancing, it is likely due to a large number of parallel blocks (see metis_map.out). Reduce parallel_scale (e.g., from -1 to -2) in inputs.in and rerun the simulation. Check that the new load balance at the reduced parallel_scale is still adequate.
For CONVERGE 3.0, the load balancing is performed with the parallel ParMETIS algorithm, and it is cell based. This parallel load balance is much faster than legacy versions of CONVERGE.
What is the optimum number of cells/processor for a typical ICE simulation?
For CONVERGE 2.4 and earlier, having at least 50,000 cells/core has been observed to give good parallel speedup.
CONVERGE 3.0 offers much better scaling compared to CONVERGE 2.4 and earlier. Depending on the hardware (cluster and interconnect), you can efficiently run with many fewer cells per core (fewer than 1500).
How often does CONVERGE do load balancing?
In CONVERGE 2.4 and earlier, the load_cyc parameter in inputs.in controls the frequency of load balancing. In addition, CONVERGE load balances each time a fixed embedding changes (either refined or released) and at the start of a simulation (new simulation, mapping, or restart) a load balancing event is done.
In CONVERGE 3.0, the solver will automatically redo the load balancing when the ratio of max cell in a rank to average cells per rank exceeds the simulation_control > imbalance_factor that you specify in inputs.in.
OUTPUTS AND POST PROCESSING
Is post-processing large cases more manageable in CONVERGE 3.0 than in previous versions?
CONVERGE 3.0 writes output files in HDF5 format, which is more efficient and robust when working with large parallel cases. Critically, Tecplot for CONVERGE can now read these files natively (for CONVERGE 3.0.8+), eliminating the time and storage constraints associated with running post_convert. This feature may be useful for simulations with larger geometries, such as gas turbines.
How do I predict the ammonia uniformity index before SCR?
Ammonia uniformity is one of the major factors to look into during the SCR system design cycle. CONVERGE 3.0 makes it easier for you to configure the uniformity index by integrating it into CONVERGE Studio as a standard feature (go to Case Setup > Output/Post-Processing > Uniformity index). Once activated, you can specify the location, orientation, and region of the plane where the uniformity index is calculated. Cell variables such as velocity, temperature, YNH3 and XHNCO are available for the uniformity index calculation.
Where do I see residuals in CONVERGE?
CONVERGE does not use residuals to determine convergence. Instead, it uses a steady-state monitor approach where key variables are monitored and criteria are met when the case becomes steady. This is a more robust method of determining steady-state convergence than simply looking at how much better the simulation is than where it started (i.e., residuals). Further, CONVERGE’s variable time-step approach is fundamentally different than the fixed time-step approach of other codes. CONVERGE reaches convergence on all variables in each time-step.
How can I know at what time a restart file has been written? And how do I know if the file has been written properly?
In CONVERGE 3.0, type the following command to obtain the time at which a restart file was written:
h5dump -a TIME_STEP <restart file name>
If the above command does not work, the file may be corrupt.
In CONVERGE 2.3 and 2.4, the first line of the restart file includes the time. To obtain the first line of the restart file, type the following command:
head -1 <restart file name>
To check if the file has been written properly, type:
tail -1 <restart file name>
If the command returns ENDofRSTRT, then the file was written properly. Otherwise, the file may be corrupted.
Are CONVERGE 3.0 outputs written differently than previous versions?
CONVERGE 3.0 writes the post (post*.h5), restart (restart*.rst), and map (map*.h5) files in HDF5 format, which is an industry standard format with a proven track record in terms of performance and scalability. These files are binary but can be viewed and edited using standard HDF5 tools.
Can a map file from an older version of CONVERGE be used for newer versions?
The map files for CONVERGE 2.4 and older are interchangeable. The format of the map file for CONVERGE 3.0 has changed to HDF5. There is an internal converter in CONVERGE Studio 3.0 that converts the old map files to HDF5 format to be used for CONVERGE 3.0+ simulations. Note that the map files from CONVERGE 3.0 cannot be converted to the format for older versions.
What is slice-based post-processing?
Slice-based post-processing is a new feature in CONVERGE 3.0 that allows you to configure a plane on which CONVERGE will record the value of various quantities for post-processing. This useful feature is also available in CONVERGE 2.4 as a hidden feature.
Can Tecplot directly read CONVERGE post output files?
Yes. Tecplot can now natively read the CONVERGE *.h5 post files from CONVERGE 3.0.8+.
How can I see how long CONVERGE spends on different processes (e.g., spray, combustion, and load balancing)?
In CONVERGE Studio, go to Simulation Parameters > Run parameters > Misc and set the Screen print level to Verbose or More verbose. Upon running the case you will see the below output in the log file either after every iteration (more verbose screen output) or at the end of simulation (verbose screen output) :
Time for ncyc 41 = 3.89 seconds
load balance = 0.00 seconds (0.00%)
solving transport equations = 3.37 seconds (86.50%)
move surface and update grid = 0.01 seconds (0.16%)
Combustion = 0.00 seconds (0.00%)
spray = 0.06 seconds (1.60%)
writing output files = 0.27 seconds (6.89%)
I ran two simulations with identical settings except that one simulation was initialized via mapping. Why are the results from these two simulations not the same?
The mapping data file does not save grid information and thus CONVERGE does not map data into the same cells. Instead, in a simulation with mapping, CONVERGE initializes each cell with data from the nearest point in the mapping data file. This process may result in some data smearing (i.e., several cells in the new simulation may be initialized with data from the same point in the map file). In addition, the AMR resolution from the old grid is not carried over to the new simulation. These differences are the reasons that the results are not identical.
What CONVERGE quantity can be compared against measured mass flow rate data at the intake port?
CONVERGE writes mass flow at the valves to regions_flow.out. CONVERGE writes mass flow rates from the inflow and outflow boundaries to mass_avg_flow.out and area_avg_flow.out.
How can I check the status of my simulation?
Look at the time.out file, which is available in CONVERGE 2.3.10+. You will find the wall time per time-step, which tells you how much time is being spent at each time-step or cycle. This quantity can give you an idea if your simulation is slowing down. You can also see if there are any recoveries in the simulation and what is causing the recoveries. The time.out file also contains the time-step size, what is limiting the time-step, and the values of the CFL numbers at each time-step.
Additionally, there is a log file written with each CONVERGE simulation which contains a lot of information. Depending on the verbosity level specified in inputs.in (output_control > log_level) the amount of information in this file will vary.
The NOx emissions in emissions.out and species_mass.out are not identical. What is the difference between these quantities?
The NOx emissions in emissions.out are from the extended Zel’dovich mechanism, which is hard-coded in CONVERGE. The calculated NO mass is multiplied by a factor of 1.533 to output NOx mass. This output is available even if you are not solving detailed chemistry. If you are using the SAGE detailed chemistry solver and if the chemical mechanism includes NOx species and reactions, then those species masses are recorded in species_mass.out. The NOx mass calculated using SAGE might not match exactly with that calculated using the extended Zel’dovich mechanism. In the passive NOx model, radicals [O] and [OH] can be assumed to be at equilibrium, while species NOx does not make such an assumption. This assumption in the passive NOx model is valid only at high temperatures (T > 2200 K). Quantities solved outside of this requirement might be responsible for the different NOx emissions data.
In CONVERGE 2.4 and earlier, the NO emission reported in passive.out is not multiplied by the mass scaling factor (typically 1.533) to get NOx emissions. So, the NO emission reported in passive.out differs from the one reported in emissions.out. In CONVERGE 3.0, the values of NO emissions in passive.out are also multiplied by the mass scaling factor. Thus the emissions.out and passive.out values match in CONVERGE 3.0.
For 1DCHT cases, how can I view the surface temperature in a post-processor?
The bound_temp variable in post.in will give the surface temperature.
How can I obtain surface-averaged data on individual boundaries?
In CONVERGE Studio, go to Case Setup > Output/Post-Processing > Output files > Output generation and select Generate WALL boundary-averaged output. This option will generate a series of files named bound*-wall.out.
What is the difference between monitor points and super-cycle monitor points?
Monitor points are locations in the domain at which CONVERGE collects data during the simulation. The general monitor point option (monitor_points.in or Case Setup > Output/Post-Processing > Monitor points) allows you to place points throughout the domain and to select from a variety of variables to be monitored at those locations. CONVERGE writes monitor point data at each time-step.
Super-cycle monitor points (supercycle.in or Case Setup > Physical Models > Super-cycle modeling) provide temperature data from specific locations within the solid domain. CONVERGE writes super-cycle monitor point data at each super-cycle.
How can I output the prescribed heat transfer coefficient to the post*.out files?
This option is not available in CONVERGE 2.3. In CONVERGE 2.4+, include bound_htc in post.in (Case Setup > Output/Post-Processing > Post variable selection).
COMBUSTION AND EMISSIONS
How can I determine the type of flame I should expect (i.e., premixed or non-premixed) for my applications using CONVERGE?
CONVERGE provides a post-processing variable called flame_index in post.in. It is a dot product of the fuel mass fraction and oxidizer mass fraction. If flame_index = -1, then the flame is non-premixed. If flame_index = 1, then the flame is premixed.
What is the thickened flame model in CONVERGE 3.0 used for?
One of the challenges of obtaining accurate combustion simulations with laminar detailed chemistry (SAGE) and large eddy simulations (LES) is that the mesh should be refined sufficiently to resolve the flame thickness with at least a few cells. This can be a challenge for thin flames at high pressure. The thickened flame model (TFM) artificially thickens the flame by adding diffusivity and slowing the reaction rate. By increasing the diffusivity and reducing the reaction rate consistently, the flame speed is unchanged but the flame thickness is increased. TFM currently works with premixed or partially premixed gaseous fuels.
Is there a difference between the FGM table in 2.4 and 3.0? Where do I go in CONVERGE Studio 3.0 to set up and generate an FGM table?
In CONVERGE 3.0.8+, the FGM table in fgm_table.dat is four-dimensional (CMEAN, ZMEAN, ZVAR, enthalpy), while in earlier versions the table is two-dimensional (CMEAN and ZMEAN; with the other two dimensions created at runtime). In CONVERGE 3.0.8+, several species are required to be tabulated, while there is no analogous requirement in earlier versions of CONVERGE. For more information about the FGM table, please see the CONVERGE Manual.
For CONVERGE Studio 3.0, FGM table generation setup is activated in Chemistry > Chemistry Tools > Table Generation: FGM. Once you have activated FGM table generation, go to Chemistry > Chemistry Setup > FGM Table Generation > FGM table generation to configure the fgm.in file. The command for running FGM table generation is the same as in previous versions: /converge –f.
Can I still generate an older 2D FGM table in 3.0.8 or later?
The 2D FGM table has been deprecated and is no longer offered as a setup option in CONVERGE Studio. You can, however, manually edit the fgm.in file to create the older table. Add “_deprecate” after the keyword for fgm_flamelet type, for example fgm_flamelet_type: 1D-DIFFUSION_deprecate
When using a 4D FGM table (in CONVERGE 3.0.8+) instead of a 2D FGM table (in CONVERGE 3.0.7 and earlier), what changes are needed in the case setup?
The setup for the 4D FGM table does not require a reaction mechanism file (e.g., mech.dat). The thermodynamic data file (e.g., therm.dat) is still needed. The post-processed gas phase species (listed in fgm.in or in the header of fgm_table.dat) must be listed under <gas> in species.in. The input files needed to generate the FGM table remains the same. CONVERGE 3.0.8+ automatically generates a 4D table. If you are starting from a case setup from CONVERGE 3.0.8 or older, remember to regenerate the FGM table in order to create a 4D FGM table.
When reducing a large mechanism typical of a gas turbine simulation, what physical parameters does CONVERGE maintain so that the reduced mechanism still emulates the original large mechanism?
With CONVERGE 3.0, in addition to ignition delay targets (simulated using 0D simulations), you can also ensure that the laminar flamespeed (simulated using 1D simulations) for the reduced mechanism is maintained within reasonable tolerances of the original mechanism.
The cells in my LES are not fine enough to resolve the laminar flame thickness. Is there a way to improve the results of my simulation?
In most large eddy simulations (LES) of premixed flames, the cells are not fine enough to resolve the laminar flame thickness. You can couple the SAGE detailed chemical kinetics solver with a dynamic thickened flame model to increase the flame thickness.
There is burning in the intake port in my G-Equation simulation. Why?
The G-Equation combustion model is active when the G_EQN passive is greater than or equal to zero. Thus, the entire simulation domain and the INFLOW and OUTFLOW masses must be set to a negative G value to avoid initializing flames from unintended locations. Refer to the SI8 engine premix G-Equation example case (in CONVERGE Studio, go to File > Load example case) for example settings.
Note that, in CONVERGE 2.3 and earlier, combustion is either on or off for the entire simulation. For CONVERGE 2.4+, however, combustion has user-specified start and end times.
There is burning in the intake port during the second cycle of my G-Equation simulation. The first cycle did not have this problem. Why is there burning in the second cycle?
Before the fresh unburned mixture enters the cylinder at the start of the second cycle, the entire simulation domain should be reinitialized with a negative value of G. To set up this option in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > G-Equation > Additional… > Initial G-value and select the Use file option. Refer to the SI8 engine premix G-Equation example case (in CONVERGE Studio, go to File > Load example case).
Should I use temperature AMR in a G-Equation combustion simulation?
In simulations with the SAGE detailed chemistry solver, temperature AMR is used to resolve the flame front so that the flame propagation speeds (and thus the fuel burn rates) are correct. However, in the G-Equation model, the flame speeds are determined from a flamespeed correlation and so we recommend NOT activating temperature AMR. This will reduce the total cell count and allow the simulation to run faster. Note that CONVERGE does not prohibit the use of temperature AMR in a G-Equation simulation.
What laminar and turbulent flamespeeds are used in SAGE?
Unlike many simplified combustion models, the SAGE detailed chemistry solver does not calculate laminar and turbulent flamespeeds directly. When using SAGE for calculating premixed combustion, the turbulent flamespeed is the result of the chemical reaction rates (from the mechanism file, e.g., mech.dat) and the enhanced mixing from the turbulence model. Even though a flamespeeds are not directly calculated, the resulting turbulent flamespeed from the chemistry and turbulence model is St=Sl*(Dt/D)^0.5 and Sl is proportional to (reaction rate*D)^0.5. Again, the laminar flamespeed, Sl, and turbulent flamespeed, St, is not explicitly calculated in the SAGE approach.
How can I have CONVERGE write out laminar and turbulent flamespeeds in my SAGE simulation?
You can use the flamespeed correlations in the G-Equation combustion model. When you set up your simulation in CONVERGE Studio, go to Case Setup > Output/Post-Processing > Post variable selection > Cells and select Laminar Flame Speed and Turbulent Flame Speed. You must also select the desired correlations in Case Setup > Physical Models > Combustion modeling. Note that these calculated flamespeeds are not used in the SAGE calculations and give only an approximation of the flamespeeds that result from the SAGE solver.
My high-EGR case does not burn well with the same chemical kinetics mechanism that gave me good predictions for no- or low-EGR cases. What should I do?
This is a limitation of the mechanism. It is likely that the mechanism was not validated against ignition delay and laminar flamespeed data under high-EGR conditions. If such data are available, CONVERGE 2.4+ contains a mechanism tuning tool (that sets up input files for genetic algorithm optimization) that can change the reaction rate coefficients to match the high-EGR data. See the CONVERGE manual for more details about this feature.
What parameters are available to increase or decrease the burn rates in a SAGE simulation?
We recommend reviewing the grid and boundary condition settings for accuracy before trying to tune the reaction rates. The Reaction multiplier option can be used to increase or decrease fuel burn rates (in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (SAGE) > SAGE Parameters). The turbulent Schmidt number can be reduced to enhance mixing and thereby increase burn rates or it can be increased to slow mixing and thereby reduce burn rates (go to Case Setup > Materials > Global transport parameters).
The lower heating value (LHV) of the fuel used in the experiments is different from the fuel surrogate used in the simulation. How can I correct this?
In CONVERGE 2.4+, you can specify LHVs for individual species. The data in the thermodynamic data file (e.g., therm.dat) will be adjusted to recover the user-specified LHV. To set up this option in CONVERGE Studio, go to Case Setup > Materials > Gas simulation and check Lower heating value. Open the accompanying dialog box to specify the species-specific LHVs.
How can I calibrate the ignition delay in the Shell ignition model?
In CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (CTC/Shell) and adjust the Ignition delay constant (af04). Increasing this value will reduce the ignition delay.
Can the RIF model be used to simulate premixed combustion in CONVERGE?
No. CONVERGE’s RIF model can be used only for non-premixed combustion.
Does the RIF model require an autoignition model in order to simulate diesel combustion?
No. CONVERGE’s RIF model uses the provided chemical kinetics mechanism to capture ignition delay.
Does CONVERGE use pre-compiled flamelet libraries (lookup tables) or does CONVERGE solve the kinetics in the mixture fraction space on the fly?
For the FGM model, CONVERGE uses pre-compiled flamelet libraries. For the RIF model, CONVERGE solves the kinetics in the mixture fraction space on the fly.
Does the RIF model in CONVERGE support unsteady and multiple flamelets?
Yes.
Can I use the same mechanism for the SAGE detailed chemistry solver and the RIF model?
Yes, but note that you cannot run both SAGE and RIF in a single simulation.
What advantage do the simplified combustion models have compared to the SAGE detailed chemistry solver?
The simplified combustion models are generally faster than SAGE.
Do the phenomenological, PM, and PSM soot models work with the RIF combustion model?
Yes.
Which species and reactions are considered in the CTC model?
The CTC model considers CO, H2, CO2, O2, H2O, N2, and the fuel. Chapter 13 of the CONVERGE Manual describes the reactions in the CTC model.
Which parameters should I change to calibrate the CTC model?
Increasing the Turbulence time-scale constant will decrease the rate of combustion. You can also adjust the Chemical time-scale constant. To change these parameters in CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (CTC/Shell).
How can I avoid having my soot values oscillate close to EVO?
You can tighten the passive tolerance. More generally, however, we recommend ending combustion before EVO.
Can I predict engine knock using the G-Equation model?
Yes, you can predict engine knock via G-Equation as long as you are using a version of the G-Equation model that includes the SAGE detailed chemistry solver outside of the flame front (the G = 0 surface). In CONVERGE Studio, go to Case Setup > Physical Models > Combustion modeling > Models (G-Equation) > Models and select one of the options that includes SAGE outside of the flame front.
When using ECFM3Z, how can I generate my own TKI tables?
This can be done using the Table Generation: TKI option in CONVERGE Studio’s Chemistry module. Refer to the Constant_Pressure_Ignition_Delay_Table_Generation example case (in CONVERGE Studio’s Chemistry module, go to File > Load example case).
Can I use ECFM+TKI for knock simulations?
Yes, ECFM+TKI is available in CONVERGE 2.3+ and can be used to predict engine knock.
Can I use ECFM or ECFM3Z for GDI/PFI engines?
Both models can be used for GDI/PFI engine simulations. However, we do recommend using ECFM instead of ECFM3Z if the mixing time is short or the grid resolution is not fine enough. Be sure to run your simulation on CONVERGE 2.3.20+.
How can I convert a map.out file from a SAGE simulation for use with an ECFM simulation?
Please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)] to obtain a script for this conversion.
How do I account for the fuel’s cetane number?
When using the SAGE detailed chemistry solver, you can use a fuel blend that has the same cetane number as the fuel used in the experiments. It is important to ensure that all of the surrogate fuel species are available in your chemical kinetics mechanism.
When using the CTC/Shell model for diesel combustion, one of the reaction rates in the shell model can be made a function of the cetane number via a user-defined function. For details, please see the following paper:
- Ayoub, N. and Reitz, R., "Multidimensional Modeling of Fuel Composition Effects on Combustion and Cold-Starting in Diesel Engines," SAE Technical Paper 952425, 1995, doi:10.4271/952425
Can CONVERGE tune kinetic mechanisms to match ignition delay and laminar flamespeed data?
Yes. The mechanism tuning tool in CONVERGE 2.4+ can be used to optimize mechanisms to match ignition delay and laminar flamespeed data for multiple operating points. Please see the CONVERGE manual for more details.
CHEMISTRY TOOLS
What can I do with CONVERGE’s chemistry tools?
The chemistry tools allow you to study reacting systems, manipulate mechanisms, and generate data tables needed for some simulations. Examples:
- Blending surrogate fuels to match real fuel properties
- Reducing, tuning, and merging kinetic mechanisms to extend or alter their usage
- Calculating ignition delay (ID) and laminar flamespeed of combustible mixtures to examine flammability, compare different *fuel and oxidizer combinations, or evaluate kinetic mechanisms
- Creating laminar flamespeed tables for G-Equation and Extended Coherent Flamelet Model (ECFM) combustion models
- Creating ID tables for 3-Zone ECFM (ECFM3Z) combustion model
Do I need a separate license to run CONVERGE’s chemistry tools?
Running chemistry tools requires a valid CONVERGE license but it does not count as a license in use.
Can I run 0D and 1D cases in parallel?
Yes, these cases can be distributed to run on different processors. However, a single case cannot be run on multiple processors.
What can I calculate with 0D tools?
Zero-dimensional tools can be used to calculate the following quantities:
- Ignition delay or equilibrium conditions of a system
- Conditions in a homogeneous charge compression ignition (HCCI) engine
- Research octane number (RON) and motor octane number (MON) of a given fuel
- Ignition limits in flowing or well-mixed systems
- Ignition delay targets for mechanism tuning
- Speciation (calculated from flow reactor and shock tube equivalent simulations)
What are some aspects of the 0D reactor modeled in CONVERGE?
Single cell calculations without CFD boundary conditions
- Runs to a user-specified end time: Equilibrium, autoignition, specified time
- Mimics various processes
- For example, constant V, constant P and h
- Can account for mass flow rates
- Well-stirred reactor and plug flow reactor
- Can account for volume change
- Can account for wall heat transfer
Can the chemical equilibrium (CEQ) conditions be calculated via CONVERGE’s chemistry tools?
Yes, 0D chemistry tools can be used to quickly find the equilibrium conditions of a reacting system. CEQ can be found under two thermodynamic conditions: (1) constant enthalpy and constant pressure or (2) constant temperature and constant pressure.
What ignition delay (ID) definitions does CONVERGE use?
- Single ignition delay
- The time (t) to raise the mixture temperature by 400 K
- Double ignition delay
- The first ignition delay (t1) is the time at which the first derivative of temperature with respect to time is at its maximum
- The second ignition delay (t) is the time to raise the mixture temperature by 400 K
What does the 0D engine RON/MON estimator do?
The RON/MON estimator determines the octane numbers of a given fuel composition per ASTMD2699 and D2700 standards.
- For a given fuel, this tool finds the lowest compression ratio (critical compression ratio [CCR]) at which the mixture autoignites.
- This tool compares the CCR to the CCR values of primary reference fuels (PRF) to determine the octane rating.
Can I use chemistry tools to explore the flammability limits of a mixture?
Yes, you can use the 0D well-stirred reactor model to explore combustion and flammability limits in turbulent, well-mixed systems.
What quantities can I calculate with 1D tools?
You can use one-dimensional simulations to accomplish a variety of processes:
- Assess burning (laminar flamespeed) at certain mixture conditions
- Evaluate the performance of a reaction mechanism
- Generate laminar flamespeed targets for mechanism tuning
- Develop laminar flamespeed tables necessary for some applications (TLF for ECFM, TLF for G-Equation, etc.)
- Complete laminar counterflow calculations, which determine the temperature and species between two inlet streams
Can I use chemistry tools to create laminar flamespeed tables?
Yes, the 1D solver can be used to create laminar flamespeed tables that can be used by many combustion models, including the G-Equation model, the Extended Coherent Flamelet Model (ECFM), the thickened flame model (TFM), and the Flamelet Generated Manifold (FGM) model.
The lookup table can store laminar flamespeeds as a function of unburned temperature, pressure, equivalence ratio, EGR fraction (constant by default or tracked as passives if spatial and/or temporal variation are needed, unburned fuel species (traced as passives).
CONVERGE Studio can generate input files that can be used to generate flamespeed tables.
Can CONVERGE reduce kinetic mechanisms while conforming to ignition delay and laminar flamespeed targets?
Yes. With CONVERGE 3.0, the mechanism reduction tool can be used to reduce mechanisms while conforming to ignition delay and laminar flamespeed targets. In previous versions of CONVERGE only ignition delay targets can be used.
Can CONVERGE tune kinetic mechanisms to match ignition delay and laminar flamespeed data?
Yes. The mechanism tuning tool can be used to optimize mechanisms to match ignition delay and laminar flamespeed data for multiple operating points.
Can I use a chemistry tool to merge two chemical mechanisms?
Yes. The mechanism merge tool can combine two reaction mechanisms to:
- Develop multi-component surrogate mechanisms, e.g., adding isooctane reactions to an n-heptane mechanism to develop a PRF mechanism
- Add PAH or NOx chemistry to a fuel mechanism to add emissions prediction capability
- Add additional reaction pathways, e.g., adding more fuel reactions or additional pathways to secondary species to a skeletal mechanism
It is important to validate the merged mechanism against available laminar flamespeed, species, and other data.
What is the surrogate blender?
CONVERGE Studio’s surrogate blender creates a multi-component fuel surrogate with specified physical properties. Since fuels consist of a mixture of several individual components, simulating a fuel as a single component can lead to errors. You can simulate fuels as multi-component surrogates whose properties (e.g., derived cetane number, molecular weight, H/C ratio) approximate those of the target fuel.
SPRAY
What film splash models are available for aftertreatment simulations?
CONVERGE offers the O’Rourke, Kuhnke, and Bai-Gosman film splash models. For aftertreatment simulations, the Kuhnke model is commonly used. By altering model parameters like the rebound Weber number and non-dimensional critical wall temperature, you can alter model parameters to correlate the model to experimental results. The Wruck heat transfer model is also available to account for the Leidenfrost effect.
To predict deposit formation, should I use the molten solid approach or detailed urea decomposition?
In CONVERGE 2.4 and earlier, the molten solid approach was considerably less computationally expensive, and we recommended it for some aftertreatment applications. Because detailed decomposition of urea is as fast as molten solid decomposition in CONVERGE 3.0, we suggest using detailed decomposition and fixed flow to directly simulate the formation of species such as biuret, ammelide, and cyanuric acid (CYA).
Can CONVERGE write out important spray statistics such as SMD or mass flux from a Lagrangian spray simulation?
CONVERGE 3.0 contains a built-in Phase Doppler Particle Analyzer (PDPA). CONVERGE will track particles passing through user-defined PDPA points and compute relevant statistics (Sauter mean diameter, velocity components, mass flux, etc.) for each PDPA monitor point.
I am simulating a symmetric multi-hole injector, but the spray penetration patterns from each nozzle are not identical. The spray plumes aligned with the grid seem to penetrate more than the non-aligned plumes. Why?
Depending on the flowfield, there are cases in which the spray plumes will not be identical even though the spray nozzles are symmetric. In other cases, where the spray is dominant and the plumes are expected to be similar, this phenomenon is caused by numerical viscosity associated with large computational cell sizes. A spray injected along the diagonal of a cubic cell is subjected to more numerical viscosity than a spray aligned with the edges of the cells. This effect diminishes as the cells are refined. For more information, please refer to the Convergent Science white paper on numerical viscosity.
In CONVERGE 3.0, you can specify a conical inlaid mesh along the axis of all nozzles. The inlaid mesh will minimize the uneven effects of numerical viscosity and produce more uniform plumes. Note that in some cases the non-uniformity of the flow will cause non-identical spray penetration for each of the plumes. This is a physical effect rather than a numerical one.
My spray simulation runs slowly due to significant wall film formation. Is there a way to increase the simulation speed?
CONVERGE 3.0 offers a parcel consolidation option in which parcels at boundary cells are combined to reduce simulation time. This option is appropriate for simulations that run slowly because they have so many parcels at the wall.
Can I run VOF one-way coupling on CONVERGE 3.0 with a VOF map file that was created with an older version of CONVERGE?
Yes, CONVERGE 3.0 can load a vof_spray.dat file that was written by an older version of CONVERGE as long as the Injector IDs and Nozzle IDs in the older files match the Injector Names and Nozzle Names in the 3.0 spray.in file.
What are the benefits of using inlaid mesh in spray simulations, and what are the limitations?
CONVERGE 3.0 simulations can include cells that are not part of the global Cartesian cut-cell mesh. These cells, which can be of arbitrary size, shape, and orientation, are referred to as inlaid cells. Inlaid cells can be used, for example, to create spray-aligned conical meshes or boundary layer meshes. A spray-aligned mesh will lower the numerical diffusion associated with mis-alignment of the Cartesian grid with the nozzle axis. The spray-aligned inlaid mesh is especially useful for multi-nozzle sprays and can preserve consistency across individual nozzles and predict a more accurate liquid and vapor penetration length. A boundary layer mesh can resolve the boundary layer structure with many fewer cells than a Cartesian cut-cell mesh would require.
Currently, AMR and moving boundaries are not permitted in inlaid cells. The inlaid mesh is defined as part of the geometry and it belongs to the surface file; therefore, the inlaid mesh cannot intersect with any other boundaries of the geometry. This also means that an inlaid mesh cannot be very close to moving boundaries that might intersect it.
Does CONVERGE provide any models for mimicking flash boiling sprays?
When modeling drop evaporation, CONVERGE 3.0 can apply a flash boiling model. CONVERGE can also reduce the drop size based on flash boiling. This feature can be activated in CONVERGE Studio via Case Setup > Spray modeling > Drop evaporation > Flash boiling.
Must I increase the number of spray parcels when I refine the grid?
Yes. If the cell size is reduced and the number of parcels stays constant, then the amount of liquid in a cell increases, which tends to artificially reduce the drag on the droplet. Each time the cell is refined one level (e.g., when amr_groups > amr_group > amr_* > embed_scale in amr.in changes from 2 to 3), you should increase the number of parcels injected by at least a factor of 4 (8 is even better but can get very computationally expensive for fine meshes). Please consult the following publication for more details:
- Senecal, P.K., Pomraning, E., Richards, K.J., and Som, S., “Grid-Convergent Spray Models for Internal Combustion Engine CFD Simulations,” Proceedings of the ASME 2012 Internal Combustion Engine Division Fall Technical Conference, ICEF2012-92043, Vancouver, BC, Canada, September 23-26, 2012. DOI:10.1115/ICEF2012-92043
Which pressure should be used to calculate parcel velocities in the spray rate calculator?
In order to calculate the parcel velocities that come out of the nozzle hole, we recommend using the difference between the injector sack pressure and the back pressure (cylinder pressure).
In the Kelvin-Helmholtz model, is the shed mass constant applied only to parent parcels or is it applied to any droplets subjected to a breakup event?
The shed mass constant (in CONVERGE Studio, go to Case Setup > Physical Models > Spray modeling > Injectors > Models) is applied to all droplets in the domain that are undergoing KH breakup.
Does the Kelvin-Helmholtz model act only on parent parcels or does it also act on the first generation of child droplets (i.e., the droplets derived from the primary breakup)?
The KH model acts on all drops.
Is it correct to apply the Kelvin-Helmholtz model to the breakup of child droplets (i.e., not parent parcels), when the KH theory refers only to the disintegration of liquid jets (i.e., parent parcels)?
The KH model assumes that the fastest growing surface wave is much smaller in magnitude than the surface on which it grows, and thus it does not matter if it grows on a liquid sheet, a ligament, or a spherical drop.
How are primary and secondary breakup simulated in the modified KH-RT model?
Primary breakup is simulated via the KH model. For secondary breakup, the KH and RT models compete against one another.
In the KH-RT model, which parameters can be adjusted to change the drop size?
You can adjust several KH and RT parameters, but we recommend two of them as a starting point. In CONVERGE Studio, go to Case Setup > Physical Models > Spray modeling > Injectors. Click Edit to open the [Injector #] configuration dialog box. The parameters below are in that dialog box.
- RT model size constant (rt > size_const): Reduce this value to reduce the drop size.
- KH model breakup time constant (kh > time_const): Reduce this value to make drop breakup occur more quickly and to reduce the drop size.
How are the blobs initialized when the injection drop distribution is based only on nozzle size and the discharge coefficient model uses a varying nozzle velocity coefficient?
CONVERGE dynamically calculates the velocity coefficient (Cv) based on the injection pressure at that time. CONVERGE then calculates the contraction coefficient (Ca) from Ca = Cd/Cv (Cd is user-specified).
Once Ca has been calculated, CONVERGE calculates the effective diameter (deff) and effective area (Aeff) of the blob according to the following relationships:
In the equations above, and are the nominal diameter and nominal area of the blob.
When should I use a spray-wall interaction model?
You should use a spray-wall interaction model whenever the spray impinges on a wall.
Are there any guidelines on the meshing requirements for spray-wall interaction models?
CONVERGE has no special meshing requirements for the spray-wall interaction models. You can use the typical grid recommendations.
Can a single liquid parcel species evaporate into multiple gas-phase species?
Yes, this can be done using composites, which are composed of multiple base species. To set up composites in CONVERGE Studio, go to Case Setup > Materials > Composite species. Please refer to the Engine sector diesel SAGE composite example case.
AFTERTREATMENT AND UREA/SCR
What new solver options are available in CONVERGE 3.0 for aftertreatment and gas turbine simulations?
CONVERGE 3.0 includes a pressure-based solver, which is a better option for steady-state gas turbine and aftertreatment simulations than the density-based solver. You can use either the PISO or SIMPLE algorithms in CONVERGE 3.0 for aftertreatment.
Can I run an SCR surface chemistry simulation in CONVERGE 3.0?
Yes. There are two ways to simulate SCR surface chemistry. CONVERGE 3.0 supports surface chemistry modeling, in which you can specify regions in which surface chemistry will be solved and configure washcoat properties. CONVERGE 3.0 can also couple with GT-SUITE to take advantage of the surface chemistry modeling capability of GT-POWER.
How can I accelerate my aftertreatment simulation to predict deposit formation over the course of minutes?
For some continuous or pulsed spray simulations, the flow field may temporarily reach a pseudo steady-state. To reduce the total simulation time, CONVERGE 3.0 offers a fixed flow option that freezes the flow field while still solving the spray. When the flow field is frozen, the spray is one-way coupled to the flow (i.e., the spray reacts to the flow but the flow does not react to the spray). This approach greatly extends the time-step (CFL number) so that 30 to 60 seconds of simulation time can be achieved in a single day.
I am looking at pressure drop and uniformity of my urea/SCR. Do I need to use fixed flow?
Prior to CONVERGE 3.0.15, fixed flow was reserved for filming and deposit simulations, which require a long time to fully develop. Fixed flow is not eligible for NH3/HNCO uniformity studies since species in the flow domain would be fixed when fixed flow is turned on.
However, in CONVERGE 3.0.15+, the species solver can be turned on when fixed flow is activated. This new feature allows uniformity studies to take full advantage of the fixed flow speedup.
Can I use the steady solver for my urea/SCR simulation?
If your spray is steady, you can use the steady solver for aftertreatment simulations. If your spray is pulsed, however, you need to run a transient simulation with the high CFL transient default solver settings. These high CFL transient settings (via temporal_control > mult_dt_spray and temporal_control > max_cfl_u in inputs.in) can handle CFL values between 10 and 30.
What is the urea deposit risk UDF, and how does it compare to the urea detailed decomposition model?
The urea deposit risk user-defined function (UDF) is a highly empirical approach that considers the conditions of the film (e.g., temperature, film height, HNCO concentration in gas near film surface, etc.) that promote urea deposit formation. The urea deposit risk UDF requires calibration to experimental data to be predictive. In CONVERGE 3.0, the urea detailed decomposition is able to quantitatively predict deposit by-products mass and can run just as fast as the molten solid model. Thus we suggest using the urea detailed decomposition model.
VOLUME OF FLUID (VOF)
Can CONVERGE apply its volume of fluid model for both compressible and incompressible fluids?
Yes. The VOF model in CONVERGE offers the Individual Species Solution (ISS) method and the Void Fraction Solution (VFS) method. The ISS, also known as compressible VOF, is good for compressible gases and compressible or incompressible liquids. The Void Fraction Solution method is good for incompressible gases and incompressible liquids.
In the VOF model, how does CONVERGE calculate the void fraction?
In the ISS method, i.e., compressible VOF, CONVERGE solves the individual species conservation equations and then calculates the void fraction from the cell mass fractions of liquid and vapor species. In the VFS method, or incompressible VOF, CONVERGE directly solves a transport equation for the void fraction.
Can CONVERGE predict the phase change of fluid due to flashing or cavitation?
Yes, the VOF model implements a homogeneous relaxation model (HRM) to predict the phase change of the fluid.
Can Adaptive Mesh Refinement be used in a VOF simulation to reduce computation time?
Yes. When performing a VOF simulation, it is important to invoke Adaptive Mesh Refinement (AMR) on both void fraction and velocity to accurately simulate the interface between the liquid and the vapor. VOF models typically require fine resolution and thus small time-steps. Using AMR to add resolution where necessary can reduce cell count and computational time.
Can CONVERGE accurately capture the location of the interface between the liquid and the gas?
The use of AMR allows CONVERGE to locate the interface, but the High-Resolution Interface Capturing (HRIC) and Piecewise Linear Interface Calculation (PLIC) schemes greatly enhance the sharpness of the interface. Use HRIC with compressible VOF and either HRIC or PLIC with incompressible VOF.
Can CONVERGE predict the atomization and evaporation of a liquid in a VOF simulation?
Predicting the atomization of the liquid in a VOF simulation requires (1) the Eulerian-Lagrangian Spray Atomization (ELSA) model, (2) the VOF one-way coupling approach, or (3) setting the grid size to be smaller than the size of the smallest droplets. The ELSA model automatically transitions Eulerian liquid to the Lagrangian parcel phase when the cell meets certain criteria. The VOF one-way coupling model initializes a Lagrangian parcel simulation using the data from a VOF simulation. In both cases, CONVERGE applies models for collision, drag, break-up, and evaporation to the Lagrangian parcels.
WALL HEAT TRANSFER
If I am interested in filming and urea deposit formation, should I use conjugate heat transfer for wall modeling?
Yes. Conjugate heat transfer (CHT) is usually used for simulations with filming and Urea deposit formation. An accurate wall temperature prediction is crucial for filming simulations. Also, the Urea decomposition by-products formation is rather sensitive to the film temperature, which requires a high-fidelity wall temperature prediction. We recommend super-cycling in conjunction with the CHT model to allow the walls to reach thermal equilibrium faster.
How can I simulate thermal barrier coating using CONVERGE?
There are several ways to simulate thermal barrier coating (TBC) on a piston top. Here are a few options:
- A full 3D CHT simulation, where the TBC is simulated as well as the rest of the piston. In this type of simulation, the thickness of the coating needs to be resolved, which means that there needs to be a sufficient number of cells across the thickness of the coating. This type of simulation is very expensive because it requires many cells and small time-steps.
- A 3D CHT simulation plus contact resistance modeling, where the TBC is not simulated. In this type of simulation, the TBC is represented by a contact resistance on the surface of the piston and the rest of the piston is simulated. The contact resistance can be calculated based on the conductivity of the material used for the TBC and the thickness of the coating. The rest of the piston needs to be resolved. This type of simulation is more expensive than a gas-only internal combustion simulation but far less expensive than a full 3D CHT simulation.
- A 1D CHT boundary condition, where the piston is not resolved and the TBC is represented by a 1D CHT boundary condition on the piston surface. This type of simulation is generally as expensive as a gas-only internal combustion simulation. There is some loss of accuracy because the heat transfer using the 1D CHT boundary condition is assumed to be only in one direction. In addition, some information about the internal temperature of the piston needs to be provided, which is not always known.
Can CONVERGE seal surfaces on an INTERFACE?
At this time, CONVERGE does not allow sealing on an INTERFACE.
What interpolation method does CONVERGE use for spatial boundary condition profiles?
CONVERGE does not interpolate for spatial boundary condition profiles. Instead, CONVERGE obtains information from the nearest data point.
When I run a CHT case in CONVERGE 2.4, I see the following warning message: Problem with the number of regions in rank #. Is this a problem?
This message is commonly seen in CHT simulations in CONVERGE 2.4. It does not indicate a problem. This message should not cause a crash or impact simulation results or runtime.
When I run a CHT case, my case crashes and I see the following error: The surface has a non-interface triangle that is only connected to a single interface triangle. What is the problem?
This error is often related to an incorrect INTERFACE assignment. An edge can be shared by two triangles only if both triangles are non-interface or if both triangles are interface. CONVERGE does not allow an edge to be shared by one interface triangle and one non-interface triangle.
When I run a CHT case, my case crashes and I see the following error: Neighboring triangles are associated with different streams. What is the problem?
This error is often associated with an INTERFACE boundary. For an INTERFACE boundary, the surface normal of all triangles in that boundary must point toward the same region and that region must be consistent with the information in the boundary definition file (in CONVERGE Studio, go to Boundary Conditions > Boundary to set up this region). You may see the error specified above if a single surface normal points in the wrong direction.
I am comparing heat transfer coefficients (HTCs) from CONVERGE with HTCs from other codes and they do not match. Why?
In CONVERGE, the HTC is a local value based on the near-wall cell temperature, not a free-stream temperature. This HTC differs from an HTC that is based on a user-specified reference temperature, and it also differs from an HTC that could be estimated from a Nusselt number correlation. Because HTC definitions vary from code to code and because CONVERGE uses local HTC values that depend on the near-wall mesh, we recommend instead comparing flux.
Can we perform an all-in-one coolant/combustion/solid simulation?
Currently CONVERGE does not allow three phases in the same simulation and thus the coolant/combustion/solid combination is not allowed. This combination needs to be separated into two simulations (for example, a gas/solid CHT simulation and a liquid simulation). There is a Python script to automate the process of going back and forth between the two separated simulations. Please contact support@convergecfd.com if you need the script.
Can I use super-cycling for predicting a steady-state temperature field in a non-engine case? If so, how do I set supercycle_stage_num and supercycle_stage_interval?
CONVERGE allows super-cycling in non-engine cases. As long as the temperature of the solid part can be approximated as a steady state, you can use super-cycling to obtain a steady-state solid temperature distribution faster than in a typical transient simulation.
If the simulation has temporally periodic variation in its behavior (for example, as in an engine), supercycle_stage_num*supercycle_stage_interval must equal the cyclic period. For example, you may have a nozzle in a tunnel that is spraying water into the air flow for 1 minute in every 10 minutes. You can set supercycle_stage_num = 1 and supercycle_stage_interval = 10 minutes to obtain a steady-state temperature distribution in the solid tube wall through super-cycling. This configuration would average the heat transfer information for the full 10 minutes into one representative average and then perform the super-cycle calculation just once in every 10-minute period. Alternatively, you could set supercycle_stage_num = 5 and supercycle_stage_interval = 2. For this configuration, the average heat transfer information would be stored in 2-minute segments and CONVERGE would perform super-cycling 5 times in every 10-minute period. If the entire simulation is steady-state (both the fluid dynamics and solid portions), then there is no reason to use more than one stage for averaging the heat transfer information. In this case, set supercycle_stage_num = 1, and then choose the supercycle_stage_interval to be the window size for calculating the average heat transfer information used in super-cycling.
What is the convection temperature boundary condition?
In CONVERGE, you can set a convection boundary condition for either a solid or a fluid WALL boundary. In either case, the convection boundary condition prescribes the convection between the wall and the environment (note that the environment is not included in the computations).
OPTIMIZATION
How many simulations are typically required when optimizing an engine case in CONVERGE using the genetic algorithm utility CONGO?
We recommend 50-100 generations, which would be about 800 simulations, for an optimization including 5-10 parameters.
Is optimizing a mechanism using the mechtune capability similar to optimizing a CFD case?
Yes, a genetic algorithm with CONGO can be used for mechanism optimization. The mechtune capability in CONVERGE creates input files for CONGO. We recommend a minimum of 2000 generations for a mechanism tune case (~16,000 ignition delay/flamespeed simulations)
See the following paper for a demonstration of this capability:
- Mittal, A., Wijeyakulasuriya, S.D., Probst, D., Banerjee, S., Finney, C.E.A., Edwards, K.D., Willcox, M., and Naber, C., "Multi-Dimensional Computational Combustion of Highly Dilute, Premixed Spark-Ignited Opposed-Piston Gasoline Engine using Direct Chemistry with a New Primary Reference Fuel Mechanism," ASME 2017 Internal Combustion Engine Division Fall Technical Conference, ICEF2017-3618, Seattle, WA, United States, Oct 15–18, 2017. DOI: 10.1115/ICEF2017-3618
Is it possible to optimize geometry features in CONVERGE?
Yes, this capability is a strength of CONVERGE. Because CONVERGE creates the mesh at runtime, modifying the geometry in optimization is straightforward. The surface file can be parameterized using CAD or a number of third-party geometry-modifying software packages. More information is available from the following resources:
- Pei, Y., Pal, P., Zhang, Y., Traver, M., Cleary, D., Futterer, C., Brenner, M., Probst, D., and Som, S., "CFD-Guided Combustion System Optimization of a Gasoline Range Fuel in a Heavy-Duty Compression Ignition Engine Using Automatic Piston Geometry Generation and a Supercomputer," SAE Paper 2019-01-0001. DOI: 10.4271/2019-01-0001
- Automated Optimization Workflow for a Diesel Piston Bowl Using CAESES and CONVERGE CFD” webinar recording, available on the CAESES website.
How can machine learning be used to enhance optimization of CONVERGE cases?
Machine learning can be used to build an emulator for CFD using design of experiments data to characterize the design space. The machine learning emulator can then be used for optimization, sensitivity, and uncertainty quantification. Several journal papers have demonstrated this potential (including the two listed below). Please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)].
- Moiz, A.A., Pal, P., Probst, D., Pei, Y., Zhang, Y., Som, S., and Kodavasal, J., “A Machine Learning-Genetic Algorithm (ML-GA) Approach for Rapid Optimization Using High-Performance Computing,” SAE Paper 2018-01-0190. DOI:10.4271/2018-01-0190
- Probst, D.M., Senecal, P.K., Qian, P.Z., Xu, M.X., and Leyde, B.P., "Optimization and Uncertainty Analysis of a Diesel Engine Operating Point using CFD," Proceedings of the ASME 2016 Internal Combustion Engine Division Fall Technical Conference, ICEF2016-9345, Greenville, SC, United States, Oct 9–12, 2016. DOI: 10.1115/ICEF2016-9345
Does CONVERGE / CONGO include machine learning capability for optimization?
No, machine learning capability is not included in CONVERGE or CONGO, but many third-party packages can be used.
OTHER TOPICS
How can I accelerate my CONVERGE 3.0 steady-state simulations? Will they be faster than steady-state simulations run in previous versions?
Some cases may be able to use larger pseudo-time-steps and achieve faster solutions by using the SIMPLE algorithm and pressure-based solver in CONVERGE 3.0. Another improvement is that in CONVERGE 3.0 you can have a split steady-state monitor approach: you can define looser criteria for auto-grid scaling and auto start of Adaptive Mesh Refinement than the final convergence criteria. For example, you can have convergence on NOx and CO only in your final convergence criteria so you don’t spend time during grid scaling waiting for those variables to reach steady values. CONVERGE 3.0 scales significantly better than previous versions, and these improvements will help accelerate your parallel steady-state simulations.
How can I accelerate my CONVERGE 2.4 steady-state simulations?
The steady-state solver in CONVERGE 2.4 is a density-based pseudo-time-stepping solver that can be used for solving a wide range of steady flow simulations (internal/external flows, combustion, sprays and films, CHT, MRF, surface chemistry, etc.). The solver allows the use of higher CFL numbers and also automated solver control for certain simulation parameters (CFL numbers, solver tolerances, and grid sizes). Both of these features help reduce the computation cost of your simulation.
Please consult the CONVERGE 2.4 Manual for recommended parameters for steady-state simulations. Remember that these values may require modification for some cases. Some general recommendations are given below.
We recommend initiating your steady simulation with a relatively coarse grid (grid_scale = -1 or -2 in inputs.in), so as to allow the initial transients to be rapidly flushed out of the domain. Time-based or automated grid scaling should be used, although care should be taken to ensure that the grid always remains adequately refined in regions in which the flow is complex. The maximum CFL number can be set to approximately 20 to 30 for non-reacting flows and approximately 10 to 15 for reacting flows. If the solver has excessive recoveries, you can reduce the maximum CFL number. If automated control is activated, the solver will perform this action on its own. Monitoring a few flow variables is useful for determining convergence in a steady simulation and can be used for automatically controlling grid scaling or solver settings. We recommend monitoring variables at OUTFLOW boundaries (temperature, mass flow rate, and species concentration), within the domain (maximum, minimum, and mean pressure and temperature; species concentration; and spray mass), or at monitor points (velocity, pressure, and temperature). The initial velocities and pressures and the corresponding INFLOW boundary conditions should be as consistent as possible. For instance, if the inflow velocity is 1 m/s, then the initial condition should be 1 m/s as well.
What solver option is recommended for pressure in steady-state simulations?
We recommend CONVERGE BiCGSTAB with the SOR preconditioner as the go-to pressure solver option in steady-state simulations.
What convective flux schemes are available in CONVERGE 3.0?
CONVERGE 3.0 includes three different varieties of the MUSCL scheme (Monotonic Upstream-Centered Scheme for Conservation Laws). The MUSCL_CVG option includes a 3D gradient-based slope limiter (the minmod method of Barth and Jespersen or the venkatak method of Venkatakrishnan). The MUSCL scheme can be very useful for supersonic flows and for obtaining second-order upwinding.
For LES simulations, how can I obtain second-order in time?
Setting Numerical_schemes > implicit_fraction = 0.5 in solver.in yields the Crank-Nicholson time-marching scheme, which is second-order in time for the momentum equation. Please be sure temporal_control > max_cfl_u in inputs.in is less than 1.0.
What are YAML-compliant input files?
CONVERGE 3.0 input files are YAML-compliant. YAML is a standardized plain-text format that offers more flexibility than the input file format of CONVERGE 2.4-. See the CONVERGE 3.0 Manual (Chapter 23 - Input and Data Files) for more details about YAML-compliant input files and for details about each input and data file. Because of the change in file format from CONVERGE 2.4 to CONVERGE 3.0, we strongly recommend using CONVERGE Studio 3.0 to set up new cases or to convert input files from previous versions.
How can I update the input files of a simulation from an older version of CONVERGE to a newer version?
We recommend using CONVERGE Studio to automatically convert input files from an older version of CONVERGE. Open CONVERGE Studio 3.0 and go to File > Import > Import input file(s). CONVERGE Studio will convert your files to version 3.0. You can then export these version 3.0 files in CONVERGE Studio and use them in a CONVERGE 3.0 simulation.
How does CONVERGE store the surface geometry file?
CONVERGE 3.0 stores the surface geometry on each compute node rather than on each core. Node-based storage reduces the memory requirement without affecting computational performance. This memory savings can be significant for geometries with a large triangle count and will be more significant in HPC systems with a larger number of cores per node.
Can the motion of boundaries be linked for the simplicity of the case setup?
Starting in CONVERGE 3.0 you can set up a moving WALL boundary and link to it the motion of other WALL boundaries.
In a periodic simulation, do the periodic matching directions have to be aligned with a coordinate axis?
Starting in CONVERGE 3.0, the periodic matching directions do not need to be coordinate-aligned, periodic faces do not need to be planar, and a case can have multiple periodic matching directions. In CONVERGE 2.4, the rotational periodic boundaries were limited by z as the axis of rotation, xz as symmetry plane, and planar faces. Also, periodicity could be enforced in only two directions in translational periodic cases.
My therm.dat file contains multiple entries of the same species. Which entry does CONVERGE use?
CONVERGE uses the first entry and ignores any subsequent entries for that species. If you validate your therm.dat file in CONVERGE Studio before running a simulation, CONVERGE Studio will offer several ways to resolve duplicate entries.
Why don’t results from one version of CONVERGE always match results from an older version of CONVERGE?
Each version of CONVERGE contains enhancements and bug fixes, and these changes may affect simulation results. Please see the release notes (available on hub.convergecfd.com/downloads) for specific information about changes to each version of CONVERGE. If you have specific questions about why results may have changed or how to more closely match results from a previous version, please contact the Convergent Science Applications team [support@convergecfd.com (US), supportEU@convergecfd.com (EU), or support.in@convergecfd.com (India)].
My RANS simulation shows cycle-to-cycle variation. Is this variation to be expected?
Yes. A well-resolved unsteady RANS simulation does not necessarily eliminate all perturbations and thus can predict cyclic variations. An example of this phenomenon is GDI engines that show high cycle-to-cycle variation in measured cylinder pressure data. The following publications contain details on this topic.
- Jupudi, R., Finney, C., Primus, R., Wijeyakulasuriya, S., Klingbeil, A.E., Tamma, B., and Stoyanov, M.K., “Application of High Performance Computing for Simulating Cycle-to-Cycle Variation in Dual-Fuel Combustion Engines," SAE Paper 2016-01-0798, 2016. DOI:10.4271/2016-01-0798
- Richards, K., Pomraning, E., Senecal, P.K., Scarcelli, R., and Wallner, T., “Cyclic Variation in Unsteady RANS Engine Simulations,” International Multidimensional Engine Modeling Users’ Group Meeting at the SAE Congress, Detroit, MI, United States, April 20, 2015.
- Richards, K., Probst, D., Pomraning, E., Senecal, P.K., and Scarcelli, R., “The Observation of Cyclic Variation in Engine Simulations When Using RANS Turbulence Modeling,” Proceedings of the ASME 2014 Internal Combustion Engine Division Fall Technical Conference, ICEF2014-5605, Columbus, IN, United States, October 19-22, 2014.
- Scarcelli, R., Matthias, N.S., and Wallner, T., “Numerical and Experimental Analysis of Ignition and Combustion Stability in EGR Dilute GDI Operation,” Proceedings of the ASME 2014 Internal Combustion Engine Division Fall Technical Conference, ICEF2014-5607, Columbus, IN, United States, October 19-22, 2014.
- Scarcelli, R., Richards, K., Pomraning, E., Senecal, P.K., Wallner, T., and Sevik, J., “Cycle-to-Cycle Variations in Multi-Cycle Engine RANS Simulations," SAE Paper 2016-01-0593, 2016. DOI:10.4271/2016-01-0593.
- Scarcelli, R., Sevik, J., Wallner, T., Richards, K., Pomraning, E., and Senecal, P.K., “Capturing Cyclic Variability in EGR Dilute SI Combustion Using Multi-cycle RANS,” Proceedings of the ASME 2015 Internal Combustion Engine Division Fall Technical Conference, ICEF2015-1045, Houston, TX, United States, November 9-11, 2015.
How do I obtain more repeatable answers from my RANS multi-cycle simulation?
By changing some numerical settings, you can force predictions to be more repeatable. Increasing numerical viscosity in the solution will dampen perturbations. Increasing cell sizes and using lower-order discretization schemes can increase the repeatability of a solution. It is important to note, however, that these changes may reduce accuracy.
Are closed-cycle simulations sufficient for modeling diesel engines?
It is important to simulate the induction in order to accurately characterize the velocity field. It is possible to run the intake simulation and map that solution at IVC for the closed-cycle simulation rather than assuming constant initial flow conditions.
How do I find Convergent Science’s recommended settings for different types of simulations?
Please refer to the example cases. In CONVERGE Studio, go to File > Load example case. These cases are also available at hub.convergecfd.com/downloads (login required).
Does Convergent Science recommend running an LES simulation at RANS grid settings?
No. An LES simulation will usually require smaller cell sizes.
What are some of the pre-processing requirements and recommendations for a four-stroke engine surface data file?
We recommend moving the piston to BDC (note that the piston must be at BDC if you are using a CONVERGE-calculated piston motion profile).
- The valves must be open and at minimum lift
- We recommend aligning the cylinder axis with the z axis.
- We recommend that the fire deck be at z = 0.0.
- Ensure sufficient resolution for the surface triangulation.
- We recommend using the Validate all button in CONVERGE Studio to check for errors. After you press this button, any issues will be listed in the Case Setup Issues log.
My case crashed due to a problem with sealing. What should I do?
Check the following items.
- The moving part and the seal-to part should not intersect during the entire process.
- The moving part and the seal-to part should be aligned in the moving direction and in the azimuthal direction.
- The gap between the moving part and the seal-to part should be smaller than the sealing tolerance by about one order of magnitude.
- The sealing tolerance should not be too large. (Typical sealing tolerances are 0.01 to 0.1 mm for an engine case.)
CONVERGE contains a sealing test utility (converge –l) that allows you to quickly identify errors in the sealing setup. For more information about this tool, please consult the CONVERGE Manual.
When do you recommend using the real gas equation of state?
We recommend the real gas equation of state for all simulations.
Can I use multiple boundary embeddings for the same boundary at different times?
CONVERGE does not allow multiple boundary embeddings for a single boundary. You can, however, accomplish the same effect by adding a box or cylinder embedding.
Can I set up monitor points that move with the piston or other moving boundaries in my simulation?
Yes. CONVERGE 2.4+ contains a monitor points option in which points assigned to a moving boundary will move with that boundary. To set up this feature in CONVERGE Studio, go to Output/Post-Processing > Monitor points.
How do I obtain the desired compression ratio?
CONVERGE Studio 2.4+ contains a compression ratio calculator (go to Applications > IC engine > Compression Ratio). You can also use this tool to move the piston to a location that yields the desired compression ratio. If you are using CONVERGE Studio 2.3 or earlier, please consult Chapter 19 of the CONVERGE 2.3 Manual for directions on calculating the compression ratio and moving the piston to the desired location.
Please note that the CR calculation tool assumes that all the valves are closed at both TDC and BDC. If any of the valves are open at these times, the calculated CR will not match the experimental data.