Some weeks ago, we were discussing axisymmetric simulations (2D representation), and this week’s blog post will be a follow-up on that topic. We will take a look at rotational symmetry (which can also be in 3D representation) in Simcenter STAR-CCM+. For those who did not yet read the blog post about axisymmetric simulations, you find the post via this link: https://volupe.com/blog-volupe/axial-symmetry-in-simcenter-star-ccm/.
The previous blog post introduced the strategy and set-up of how to use a two-dimensional simplification for fully rotational symmetric simulations. This blog post will focus a bit more on how much time and computational demand you actually can save when using simplifications such as rotational symmetry, together with how you set up the symmetry in Simcenter STAR-CCM+.
How to set up the rotational symmetry
First, we need to go through how to actually set up of the rotational symmetry. Assuming that you have a domain which represents a slice of your full 360-model, see the picture below for a 90-degree model that was used in the previous blog post.
Using the surfaces that will become the periodic surfaces and create a periodic contact as in the picture below is the only required action. In this case the surfaces are the surfaces named y0 and z0 since they are located in these planes in the global coordinate system.
In the contacts you will now get a contact between the surfaces, as in the picture below. The rotational angle for transformation is calculated automatically.
Since you will assign your parts to a region the interface between these rotational periodic boundaries will appear automatically and the rotational angle will be set based on the contact, see picture below.
Rotational symmetry study – setup
When it comes to the setup of simulations in the study (both axisymmetric in 2D and rotational symmetry in 3D), all simulations are using polyhedral cells and both mesh settings and physical models are as similar as possible. The settings that were not identical were:
- Volume growth rate (or other default control bulk mesh settings) is not possible to set for axisymmetric simulations.
- Maximum tet-size (or other default control maximum bulk mesh settings) is not possible to set for axisymmetric simulations.
- The mesh operation is not able to execute in fully parallel aspect (meaning using several cores), but the concurrent mode is possible to use where one core per geometry part is allowed.
- In the axisymmetric simulation some sharp edges actually become less sharp, like at the tip of the hollow detail at the centerline in the geometry, which will provide better mesh quality.
The mesh discrepancy means that the mesh is not identical between the different simulations, and to be able to compare mesh-time all simulations are run in serial mode (one core). The simulations in 3D (not the axisymmetric simulation) will of course receive an increase in computational speed when running on several cores, and the scaling in time is approximately linear based on the number of cores used.
The geometries of the study are going from an axisymmetric version of the geometry (the one used in the previous blog post) to the full 360-model with the increments:
- Axisymmetric (0deg)
- 10deg-slice
- 22.5deg-slice
- 45deg-slice
- 90deg-slice
- 120deg-slice
- 180deg-slice
- 360deg-slice
In the section for results the slices are presented based on which rotational symmetry angle they are using.
Rotational symmetry study – results
The outcome of the study is presented in this section with results in graphs. Note that graphs visualizing time are in logarithmic scaling to provide a better view of the large increase in computational time needed in the simulations with higher rotational angle.
The number of cells increases almost linearly. The number of cells for the axisymmetric simulation was around 10% of the number for the 10-degree-slice. From 37’000 (axisymmetric) cells to 7.2 million cells (360-model).
In a logarithmic graph the mesh time (for serial meshing) increased from 7 seconds to 1825 seconds. Please note though, that in this case parallel meshing could be used to improve meshing speed.
The results in pressure drop differed at most 4% (for the axisymmetric model) compared to the full 360-model.
The CPU time per iteration increased in an exponential trend, where the axisymmetric simulation only needed 0.175 seconds per iteration, while the 10-degree-slice needed as much as 4 seconds.
The flow field for velocity magnitude was predicted with 0.28% over-shot for the axisymmetric model compared to the full 360-model. For the 10-degree-slice the accuracy of the results was similar, but instead under-shooting, with -0.23%. All results were in the same range.
In a logarithmic scaling you see that the total simulation time was significantly decreased (to 3 minutes) for the axisymmetric model while the 3D-models needed more time, up to 525 minutes for the full 360-model.
Summary of conclusions from study
The conclusions that can be stated based on this study are.
- The number of cells created (with best practice settings) for a simulation is growing rapidly and linearly with the increase of size of the geometry.
- The time to create a mesh in an axisymmetric simulation is small enough to not need parallel meshing mode.
- Simulation time increases rapidly and linearly with the number of cells.
- Axisymmetric settings will decrease both the number of cells and the run-time for your simulation, which will provide large speed-up.
- The results will be less accurate when using smaller and smaller slices of the geometry.
- The speed-up gained with smaller slices will most likely be worth the loss in accuracy of the results, especially for the axisymmetric (2D) simulations.
Note: just remember that rotational symmetry can only be used if both the geometry and flow field are symmetric. If either of these criteria are not fulfilled the assumption of symmetry will not hold and the results will not be physical.
Note 2: When working with rotational symmetric models, and comparing results between simulations, the ideal mesh strategy is to use directed mesh for trimmed hexahedral cells. Please read more about how to use this type of mesh in these two previous blog posts:
- https://volupe.com/blog-volupe/directed-mesher-using-existing-mesh-as-source-mesh-in-simcenter-star-ccm/
- https://volupe.com/blog-volupe/directed-meshing-in-simcenter-star-ccm/
We at Volupe hope that this blog post has been of great interest to see how much time and computational power you can save from using symmetry and periodicity in your simulations. If you have any questions, feel free to reach out to us at support@volupe.com.
Author
Christoffer Johansson, M.Sc.
support@volupe.com
+46764479945
