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.
This same geometry and case was already used in a 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.).
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#
Added in version 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 the mesh sliding interface entry
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 CGNS Knowledge Base for more details .
farField
<Boundaries>:
farField
<ZoneGridConnectivity>:
innerRotating
innerRotating
<Boundaries>:
blade
<ZoneGridConnectivity>:
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.
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 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:
{
"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 Web UI or the 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 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/m3
Alpha = -90 Ā°, 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 Ā° per time step, thus 600 physical time steps in total
Nondimensionalizing the above (see nondimensional input) and referencing the CFL and volumeZones guidelines, we get the following flow conditions and 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.
{
"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 Quick Start example, using either the Web UI or the Python API please launch a new case using the mesh you have uploaded above and the case configuration json file you have 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.
The forces also seem to have stabilized after running for 5 revolutions.
Congratulations. You have now run your first propeller using a sliding interface in Flow360.