.. _sliding_interface: .. |deg| unicode:: U+000B0 .. DEGREE SIGN Time-accurate RANS CFD on a propeller using a sliding interface: the XV-15 rotor geometry ========================================================================================== The `XV-15 tiltotor aircraft `__ is a commonly used test bed for propeller validation work. As you can see from the following papers, we have done extensive validation work on this geometry. We will now use it to show you how to analyze a propeller-type geometry using a sliding mesh interface. * :ref:`Rotor5: Rotor analysis under 5 hours using ultra-fast and high-fidelity CFD simulation and automatic meshing` * :ref:`Assessment of Detached Eddy Simulation and Sliding Mesh Interface in Predicting Tiltrotor Performance in Helicopter and Airplane Modes` This same geometry and case was already used in a :ref:`Quick Start ` example. Here we will go more in depth into how to get a sliding interface case setup. Rotational and stationary volumes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to run a rotating geometry we need to set up a mesh with two blocks, an inner “rotational volume” and an outer “stationary volume”. The interface between those two volumes needs to be a solid of revolution (i.e., sphere, cylinder, etc.). .. figure:: Figures/rotInterfaceView.png :width: 600px :align: center :alt: Inner block enclosing the XV-15 3-bladed prop Inner block enclosing the XV-15 3-bladed prop .. figure:: Figures/farfieldView.png :width: 600px :align: center :alt: Farfield volume enclosing inner block Farfield volume enclosing inner block .. _nestedInterfaces: .. figure:: Figures/fig4.png :width: 600px :align: center :alt: Body-fitted cylinder blocks inside a larger nearfield domain Body-fitted cylinder blocks inside a larger nearfield domain Please note that it is possible, just like in the figure above, to set up nested sliding interfaces to simulate, for example, a rotating propeller with blades that pitch as they rotate (i.e., a helicopter\'s cyclical). We could also put many rotating blocks inside the stationary farfield block to simulate multiple rotors. Sliding interface requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. versionadded:: release-23.3.2.0 Starting from release 23.3.2.0 of flow360, sliding interfaces no longer need to be constructed with concentric rings. Instead, they can be made of any unstructured mesh that includes triangular and/or quadrilateral elements. Please see :ref:`the mesh sliding interface entry ` .. figure:: Figures/arbitrarily_unstructured_sliding_interface.png :width: 600px :align: center :alt: Arbitrarily unstructured sliding interface mesh. (Half of the interface is made transluscent to show the enclosed blades) Arbitrarily unstructured sliding interface mesh. (Half of the interface is made transluscent to show the enclosed blades) XV-15 setup ~~~~~~~~~~~ The rotor has a 150” (inches) radius and the blades have a chord of roughly 11”. For simplicity's sake we will use the SI system and convert these to 3.81 m radius and 0.279 m chord. A complete `CGNS mesh is available here `__ along with its associated `Mesh.json file `__. .. attention:: The mesh file must be in the CGNS format if it contains multiple volume zones. The **XV15_Hover_ascent_coarse_v2.cgns** mesh contains the following blocks and associated boundaries and zone grid connectivities. See :ref:`CGNS Knowledge Base ` for more details . .. code-block:: python farField : farField : innerRotating innerRotating : blade : farField This shows us that we have two volume mesh zones (*farField* and *innerRotating*). Inside *innerRotating* we have the *blade* NoSlipWall boundary. Associated with the *farField* zone is the *farField* boundary. Each zone also has information about zone grid connectivity, which tells Flow360 that *innerRotating* and *farField* volume zones are adjacent to each other. .. _defMeshJsonxv15: Defining a Mesh.json file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Mesh.json file contains the information the mesh preprocessor needs in order to perform its job. We need to give it information as to which boundaries are :code:`noSlipWalls`. You do NOT need to give it any additional information for the *farField* boundary. This will be done inside the case configuration file. Here, the volume mesh configuration file looks like: .. code-block:: javascript { "boundaries" : { "noSlipWalls" : ["innerRotating/blade"] } } Uploading your mesh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With the mesh file and its associated mesh configuration json file. You can upload the mesh either by using the :ref:`Web UI ` or the :ref:`Python API `. Defining a case configuration file. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Once your mesh has been uploaded, the last step before launching a run is to create a case configuration file with all the information needed by Flow360 to run your case. Here a sample case configuration json file is provided (`Click to download `__). For this case, our Flow360 input json files have 10 sections: - "geometry" - "volumeOutput" - "surfaceOutput" - "sliceOutput" - "navierStokesSolver" - "turbulenceModelSolver" - "freestream" - "boundaries" - "volumeZones" - "timeStepping" Most of those categories are self evident and won’t be discussed here, reference the :ref:`Solver Configuration ` documentation page for further details. Case input conditions ~~~~~~~~~~~~~~~~~~~~~~ For our case we have the following operating conditions: - Airspeed = 5 m/s - Rotation rate = 600 RPM - Speed of sound = 340.2 m/s - Density = 1.225 kg/m\ :sup:`3` - Alpha = -90 |deg|, air coming down from above (i.e., an ascent case) Other key considerations: - The reference Mach value is arbitrarily set to the tip Mach number for the blades - For simulation, we will do 5 revolutions at 3 |deg| per time step, thus 600 physical time steps in total Nondimensionalizing the above (see :ref:`nondimensional input`) and referencing the :ref:`CFL ` and :ref:`volumeZones ` guidelines, we get the following flow conditions and :code:`timeStepping` values in our simulation: .. note:: The volume zones, existing in the mesh but omitted in the case configuration, are treated as stationary fluid zones in Flow360. .. _XV15_tutorial_case_config: .. code-block:: javascript { "freestream" : { "muRef" : 4.29279e-08, "Mach" : 1.46972e-02, "MachRef" : 0.70, "Temperature" : 288.15, "alphaAngle" : -90.0, "betaAngle" : 0.0 }, "boundaries" : { "farField/farField" : { "type" : "Freestream" }, "innerRotating/blade" : { "type" : "NoSlipWall" } }, "timeStepping" : { "timeStepSize" : 2.83500e-01, "physicalSteps" : 600, "maxPseudoSteps" : 35, "CFL" : { "type":"adaptive" } }, "volumeZones":{ "innerRotating":{ "referenceFrame":{ "axisOfRotation" : [0,0,-1], "centerOfRotation" : [0,0,0], "omegaRadians" : 1.84691e-01 } } } } Case running ~~~~~~~~~~~~~~~~~~~~~~ As mentioned in the :ref:`Quick Start ` example, using either the :ref:`Web UI ` or the :ref:`Python API ` please launch a new case using the mesh you have uploaded :ref:`above ` and the case configuration json file you have :ref:`just downloaded `. The simulation takes about 3.5 to 4 minutes to run 5 revolutions. For a time accurate case to be considered well converged we like to have at least 2 orders of magnitude in the residuals within each time step. .. figure:: Figures/residuals_convergence.png :width: 600px :align: center :alt: convergence of residuals Convergence plot showing more then 2 orders of magnitude decrease in the residuals for each time step. The forces also seem to have stabilized after running for 5 revolutions. .. figure:: Figures/force_convergence.png :width: 600px :align: center :alt: convergence of forces Force history plot showing good stabilization of the forces. Congratulations. You have now run your first propeller using a sliding interface in Flow360.