5. Analysis
5.1. Flow Solver Namelist Input
Questions about any of the following can be emailed to FUN3D Support.
To run the FUN3D solver, you will need to pre-process your
grid using the included Party utility.
Once you have successfully run your grid through Party, running the flow
solver is simply a matter of setting up the input namelist file,
fun3d.nml, which is described in detail below.
Note that as of release 10.5.0, this namelist file replaces the old input
deck, ginput.faces. If you have an old ginput.faces file, there is a
translator called ginput_translator
in the utils/Namelist_new directory that reads ginput.faces
and writes out a corresponding file fun3d.nml (as well as a more
descriptive file fun3d.long.nml if preferred, which must be renamed
to be fun3d.nml before using).
If a ginput.faces file does not exist, then ginput_translator
will create a fun3d.nml file with default values in it.
IMPORTANT NOTE: as new namelists and parameters are added to the
fun3d.nml file, these will generally not be output by the
translator program. In other words, ginput_translator gives only
all defaults for namelist parameters
associated with the original ginput.faces deck, but it will
not keep up with subsequently-added parameters. As users get used to the
new namelist method and ginput.faces fades into history, the need for the
translator program will go away.
In the new namelist input, the perfect gas and generic gas input parameters
have been combined to a greater degree than was done in the old
ginput.faces input deck.
However, it should be noted that the earliest versions of this new namelist
mostly do no more than mimic the ginput.faces file capabilities. Thus, in many
instances certain parameters work only for generic cases or only for
ideal-gas cases. As time passes, it is hoped to merge the capabilities
better, and remove many of these restrictions and special cases.
Thus, it is likely that changes may occur in fun3d.nml as it is
worked and revised. The reason for having the input_version parameter
in namelist &version_number (in the file) is to help keep track of any
significant changes that take place.
It is also possible that the naming convention and/or
usage of fun3d.nml may change at some point in the future.
Any such changes will be documented.
Please report any problems, inconsistencies, issues, etc. with the new
fun3d.nml input to FUN3D Support.
Documentation for the old ginput.faces can still be found in
Ginput.faces Type Input.
Running with the old ginput.faces can be recovered by hardwiring
the parameter namelist_ginput = .false. in routine io.f90.
If you set this, then FUN3D will look for and read ginput.faces
like it used to, instead of using the new fun3d.nml file.
A typical namelist file (with lots of comments) is shown here:
! This file contains namelists used for specifying inputs to
! FUN3D. For this version, the following namelists apply (if a
! namelist is not present, its variables take on their default
! values):
! version_number
! project
! governing_equations
! reference_physical_properties
! force_moment_integ_properties
! inviscid_flux_method
! molecular_viscous_models
! turbulent_diffusion_models
! nonlinear_solver_parameters
! linear_solver_parameters
! code_run_control
! special_parameters
!
&version_number
input_version = 2.2
! version number of namelist file
! (ginput.faces: N/A)
! DEFAULT varies
namelist_verbosity = "off"
! current options: on, off, suppress_all
! (ginput.faces: N/A)
! DEFAULT=off
/
&project
project_rootname = "default_project"
! DEFAULT=default_project
! (ginput.faces: PROJECT_NAME)
case_title = "fun3d_case_name"
! DEFAULT=fun3d_case_name
! (ginput.faces: CASE TITLE)
part_pathname = " "
! (ginput.faces: N/A)
! DEFAULT=" " (blank)
/
&governing_equations
eqn_type = "cal_perf_compress"
! current options: cal_perf_compress,
! cal_perf_incompress, generic
! (ginput.faces: INCOMP)
! DEFAULT=cal_perf_compress
artificial_compress = 15.0
! artificial compressibility factor, only
! used when solver = cal_perf_incompress
! (ginput.faces: XMACH when INCOMP=1)
! DEFAULT=15.0
viscous_terms = "turbulent"
! current options: inviscid, laminar,
! turbulent (ginput.faces: IVISC)
! DEFAULT=turbulent
chemical_kinetics = "finite-rate"
! current options: frozen, finite-rate
! (ginput.faces: CHEM_FLAG)
! does nothing for cal_perf paths
! DEFAULT=finite-rate
thermal_energy_model = "non-equilib"
! current options: frozen, non-equilib
! (ginput.faces: THERM_FLAG)
! does nothing for cal_perf paths
! DEFAULT=non-equilib
/
&reference_physical_properties
gridlength_conversion = 1.0
! if using NONDIMENSIONAL INPUT, the
! scaled_grid_unit = grid_unit and
! gridlength_conversion should be set= 1.0;
! if using DIMENSIONAL INPUT, the
! scaled_grid_unit is in meters and
! gridlength_conversion should be set to
! meters per grid unit
! (ginput.faces: LEN_REF for generic)
! DEFAULT=1.0
!
!-------------------------------------------------------------
! User must choose either NONDIMENSIONAL or DIMENSIONAL input:
! (one set is read and one is ignored depending on
! dim_input_type), Note, however, that temperature is always
! input as a dimensional number
!-------------------------------------------------------------
dim_input_type = "nondimensional"
! options: nondimensional, dimensional-SI
! (ginput.faces: N/A)
! DEFAULT=nondimensional
temperature_units = "Kelvin"
! options: Kelvin, Rankine
! (ginput.faces: N/A)
! DEFAULT=Kelvin
!-------------------------------------------------------------
! NONDIMENSIONAL INPUT:
! (generic : do not use)
! (cal_perf_compress : specify mach_number,
! reynolds_number)
! (cal_perf_incompress: specify reynolds_number only)
!-------------------------------------------------------------
mach_number = 0.2
! (ginput.faces: XMACH)
! only used if
! dim_input_type=nondimensional
! currently does nothing for generic path
! DEFAULT=0.2
reynolds_number = 1000000.0
! based on reference length of 1 grid_unit
! (ginput.faces: RE)
! only used if
! dim_input_type=nondimensional
! currently does nothing for generic path
! DEFAULT=1.e6
!-------------------------------------------------------------
! DIMENSIONAL INPUT:
! (generic : specify velocity and density)
! (cal_perf_compress : do not use)
! (cal_perf_incompress: do not use)
!-------------------------------------------------------------
velocity = 30.0
! in m/s (ginput.faces: V_INF for generic)
! only used if
! dim_input_type=dimensional-SI
! currently does nothing for cal_perf paths
! DEFAULT=30.0
density = 0.1
! in kg/m^3
! (ginput.faces: RHO_INF for generic)
! only used if
! dim_input_type=dimensional-SI
! currently does nothing for cal_perf paths
! DEFAULT=0.1
!-------------------------------------------------------------
!
temperature = 273.0
! in temperature_units
! (ginput.faces: TREF in Rankine for
! cal_perf paths, T_INF in Kelvin for
! generic)
! DEFAULT=273.0
temperature_walldefault = 0.0
! in temperature_units;
! must be specified for generic
! (ginput.faces: T_WALL for generic);
! currently does nothing for cal_perf paths
! DEFAULT=0.0
angle_of_attack = 0.0
! in degrees (ginput.faces: ALPHA)
! DEFAULT=0.0
angle_of_yaw = 0.0
! in degrees (ginput.faces: YAW)
! DEFAULT=0.0
/
&force_moment_integ_properties
! see notes for gridlength_conversion
area_reference = 1.0
! area used to nondimensionalize forces and
! moments, in scaled_grid_units^2
! (ginput.faces: SREF)
! DEFAULT=1.0
x_moment_length = 1.0
! length used to nondimensionalize moments
! about x, in scaled_grid_units
! (ginput.faces: CREF)
! DEFAULT=1.0
y_moment_length = 1.0
! length used to nondimensionalize moments
! about y, in scaled_grid_units
! (ginput.faces: BREF)
! DEFAULT=1.0
x_moment_center = 0.0
! in scaled_grid_units (ginput.faces: XMC)
! DEFAULT=0.0
y_moment_center = 0.0
! in scaled_grid_units (ginput.faces: YMC)
! DEFAULT=0.0
z_moment_center = 0.0
! in scaled_grid_units (ginput.faces: ZMC)
! DEFAULT=0.0
/
&inviscid_flux_method
flux_limiter = "none"
! current options: none, barth, venkat,
! minmod, vanleer, vanalbada, smooth
! (ginput.faces: IFLIM)
! DEFAULT=none
first_order_iterations = 0
! number of iterations or sub-iterations
! run 1st order (ginput.faces: NITFO)
! DEFAULT=0
flux_construction = "roe"
! current options: vanleer, roe, hllc,
! aufs, central_diss, ldfss, stvd,
! stvd_modified; only roe allowed for
! cal_perf_incompress (ginput.faces: IHANE)
! DEFAULT=roe
rhs_u_eigenvalue_coef = 0.0
! (ginput.faces: EIG0 for generic)
! currently does nothing for cal_perf paths
! DEFAULT=0.0
lhs_u_eigenvalue_coef = 0.0
! (ginput.faces: EIG0_IMP for generic)
! currently does nothing for cal_perf paths
! DEFAULT=0.0
/
&molecular_viscous_models
prandtlnumber_molecular = 0.72
! (ginput.faces: PRANDTL)
! currently does nothing for generic path
! DEFAULT=0.72
/
&turbulent_diffusion_models
turb_model = "sa"
! current options: sa, des, menter-bsl,
! menter-sst, wilcox-kw98, abid-ke
! (ginput.faces: IVISC or TURB_MODEL_TYPE)
! DEFAULT=sa
turb_intensity = 2.0E-003
! Tu = sqrt(2k/(3uinf^2)), k=turb K.E.
! (ginput.faces: TURB_INT_INF for generic)
! currently does nothing for cal_perf paths
! DEFAULT=0.002
turb_viscosity_ratio = 0.210438
! mu_t/mu_molecular
! (ginput.faces: TURB_VIS_RATIO_INF
! for generic)
! currently does nothing for cal_perf paths
! DEFAULT=0.210438
re_stress_model = "linear"
! current options: linear or nonlinear
! (ginput.faces: REYNOLDS_STRESS_MODEL for
! generic)
! currently does nothing for cal_perf paths
! DEFAULT=linear
turb_compress_model = "off"
! current options: on, off
! (ginput.faces: TURB_COMP_MODEL for
! generic)
! currently does nothing for cal_perf paths
! DEFAULT=off
turb_conductivity_model = "off"
! current options: on, off
! (ginput.faces: TURB_COND_MODEL for
! generic)
! currently does nothing for cal_perf paths
! DEFAULT=off
prandtlnumber_turbulent = 0.9
! (ginput.faces: PRANDTL_TURB for generic)
! currently does nothing for cal_perf paths
! DEFAULT=0.9
schmidtnumber_turbulent = 1.0
! not used by cal_perf paths
! (ginput.faces: SCHMIDT_TURB for generic)
! currently does nothing for cal_perf paths
! DEFAULT=1.0
/
&nonlinear_solver_parameters
time_accuracy = "steady"
! current options: steady, 1storder,
! 2ndorder, 2ndorderOPT, 3rdorder,
! 4thorderMEBDF4, 4thorderESDIRK4
! (ginput.faces: ITIME)
! DEFAULT=steady
time_step_nondim = 0.0
! only used if time_accuracy is NOT steady;
! for cal_perf_compress path, dt is
! nondimensionalized via: dt*a_ref/L,
! where L = unit 1 of grid; for generic
! and cal_perf_incompress, dt is
! nondimensionalized via: dt*u_ref/L
! (ginput.faces: DT)
! DEFAULT=0.0
pseudo_time_stepping = "on"
! current options: on, off
! (ginput.faces: PSEUDO_DT)
! DEFAULT=on
subiterations = 0
! only used if time_accuracy is NOT steady
! (ginput.faces: SUBITERS)
! DEFAULT=0
schedule_number = 2
! number of CFL ramping schedules to input
! (ginput.faces: N/A)
! minimum value = 1, maximum value = 10
! currently MUST = 2
! DEFAULT=2
schedule_iteration = 1 50
! iteration numbers (input schedule_number
! of these) for CFL ramping schedule
! (ginput.faces: IRAMP equivalent to use of
! schedule_number=2, schedule_iteration=
! 1,IRAMP)
! schedule_iteration(1) MUST = 1
! DEFAULT=1,50
schedule_cfl = 200.0 200.0
! CFL numbers (input schedule_number of
! these) for CFL ramping schedule
! (ginput.faces: CFL1, CFL2 equivalent to
! use of schedule_number=2, schedule_cfl=
! CFL1,CFL2)
! DEFAULT=200.0,200.0
schedule_cflturb = 50.0 50.0
! turb CFL numbers (input schedule_number
! these) for CFL ramping schedule
! (ginput.faces: CFLTURB1, CFLTURB2
! equivalent to use of schedule_number=2,
! schedule_cfl=CFLTURB1, CFLTURB2)
! currently does nothing for generic path
! DEFAULT=50.0,50.0
invis_relax_factor = 2.0
! not used by cal_perf paths
! (ginput.faces: RF_INV for generic)
! DEFAULT=2.0
visc_relax_factor = 1.0
! not used by cal_perf paths
! (ginput.faces: RF_VIS for generic)
! DEFAULT=1.0
/
&linear_solver_parameters
meanflow_sweeps = 15
! number of Gauss-Seidel sub-iterations for
! the linear problem at each time step
! (ginput.faces: NSWEEP)
! DEFAULT=15
turbulence_sweeps = 10
! same, for turbulence; not used by generic
! path (ginput.faces: NCYCT)
! DEFAULT=10
line_implicit = "off"
! current options: on, off
! (ginput.faces: NSWEEP negative)
! DEFAULT=off
/
&code_run_control
steps = 500
! number of time steps or multigrid cycles
! to run the code (ginput.faces: NCYC)
! DEFAULT=500
stopping_tolerance = 1.0E-015
! absolute value of the RMS residual at
! which the solver will terminate early
! (ginput.faces: RMSTOL)
! DEFAULT=1.e-15
restart_write_freq = 250
! frequency of restart write based on time
! steps or multigrid cycles
! (ginput.faces: ITERWRT)
! DEFAULT=250
restart_read = "on"
! current options: off, on,
! on_nohistorykept
! (ginput.faces: IREST)
! DEFAULT=on
jacobian_eval_freq = 10
! frequency of jacobian evaluation based on
! time steps or multigrid cycles
! (ginput.faces: JUPDATE)
! DEFAULT=10
/
&special_parameters
large_angle_fix = "off"
! fix to neglect viscous fluxes in cells
! containing angles equal to 178 degrees or
! more; current options: on, off
! (ginput.faces: IVGRD)
! DEFAULT=off
/
The comments given above describe the default for each parameter, and also
give the corresponding entry from the old ginput.faces file.
The comments in the file are not necessary. With this type of input file,
leaving out or mispelling any namelist (the category parameter defined with an
ampersand “&” preceding its name) will result in default values
being used for all of the parameters within that namelist. Leaving out any
parameter within a namelist results in the default value for that parameter being used.
Mispelling or misusing any particular parameter will typically cause FUN3D to issue an
error and stop.
Note that the above namelist file contains many input variables, but in general it is not necessary to list them all. One can instead rely on the fact that most of the defaults are often desired, and only those variables that are different from the defaults need to be given. The following might be an example of a typical namelist file for a calorically-perfect FUN3D run:
&version_number
input_version = 2.2
/
&project
project_rootname = "my_project"
/
&reference_physical_properties
mach_number = 0.84
reynolds_number = 6200000.0
temperature = 252.5
angle_of_attack = 13.7
/
&force_moment_integ_properties
area_reference = 500.2
x_moment_length = 16.444
y_moment_length = 2.2
x_moment_center = 0.25
/
&inviscid_flux_method
flux_limiter = "smooth"
/
&turbulent_diffusion_models
turb_model = "menter-sst"
/
&nonlinear_solver_parameters
schedule_iteration = 1 150
schedule_cfl = 25.0 200.0
schedule_cflturb = 10.0 50.0
/
&code_run_control
steps = 2000
restart_read = "off"
/
Each of the namelists is described below. The defaults for each paramater can be found in the first sample file above.
Namelist &version_number
input_version |
The version number of the namelist file. |
|---|---|
namelist_verbosity |
Determines how namelist information from fun3d.nml is
written to the screen output. When on, the file fun3d.nml is echoed to the screen
output along with a list of all namelist parameters (including defaults).
When off, only the file fun3d.nml is echoed. When
suppress_all, all writing of fun3d.nml information to screen output is
suppressed. Quotes are needed around the character string. |
Namelist &project
project_rootname |
The project name for the grid. For example, all grid part files and solution files have this rootname as part of their filename. Quotes are needed around the character string. |
|---|---|
case_title |
User-defined title for the case. Quotes are needed around the character string. |
part_pathname |
Either absolute path or relative path from the current working directory to the location of the grid (part) files. Quotes are needed around the character string. |
Namelist &governing_equations
eqn_type |
Equation type being solved, for example cal_perf_compress for
calorically perfect compressible, cal_perf_incompress for
calorically perfect incompressible, generic for generic gas.
Quotes are needed around the character string. |
|---|---|
artificial_compress |
Artificial compressibility factor (beta), only used when
eqn_type = cal_perf_incompress. |
viscous_terms |
Describes viscous term usage, for example inviscid for no viscous
term (Euler), laminar for Navier-Stokes with no turbulence model,
turbulent for Navier-Stokes with turbulence model.
Quotes are needed around the character string. |
chemical_kinetics |
Describes the chemical kinetics, only used when
eqn_type = generic, for example frozen for chemically frozen flow,
finite-rate for finite-rate chemically-reacting flow.
Quotes are needed around the character string. |
thermal_energy_model |
Describes the thermal energy model, only used when
eqn_type = generic, for example frozen for frozen thermal
energy treatment, non-equilib for non-equilibrium thermal energy.
Quotes are needed around the character string. |
Namelist &reference_physical_properties
gridlength_conversion |
Conversion factor to scale the grid by. For dim_input_type =
nondimensional, this should be set to 1.0, because the grid is
already in nondimensional grid units. For dimensional-type input,
this should be set to meters per grid unit. |
|---|---|
dim_input_type |
Type of input, for example nondimensional or dimensional-SI.
The user’s choice here determines whether Mach number and Reynolds
number are input (for nondimensional), or dimensional velocity and
density are input (for dimensional).
Note, however, that temperature is always input as a dimensional
quantity. Quotes are needed around the character string. |
temperature_units |
Units for temperature, for example Kelvin or Rankine. Quotes are needed
around the character string. |
mach_number |
Reference Mach number, velocity/speed-of-sound.
Only used if dim_input_type = nondimensional. |
reynolds_number |
Reference Reynolds number, per unit 1 of the grid.
For example, If your Reynolds number is based on the MAC(Mean Aerodynamic
Chord), and the grid is constructed so that the MAC is one,
then the appropriate value for this is the full freestream Reynolds number.
If the grid is constructed so that the MAC is in inches,
then this must be set to the Reynolds number divided
by the MAC in inches.
Only used if dim_input_type = nondimensional. |
velocity |
Reference velocity, in m/s, only used if dim_input_type =
dimensional-SI. |
density |
Reference density, in kg/m3^, only used if dim_input_type =
dimensional-SI. |
temperature |
Reference temperature, in units of temperature_units. |
temperature_walldefault |
Wall temperature, currently only used for eqn_type =
generic. |
angle_of_attack |
Freestream angle of attack in degrees. |
angle_of_yaw |
Freestream angle of yaw (side-slip) in degrees. |
Namelist &force_moment_integ_properties
area_reference |
Reference area used for non-dimensionalization
of forces and moments, in scaled_grid_units2. |
|---|---|
x_moment_length |
Reference length used to nondimensionalize moments
about x, in scaled_grid_units. |
y_moment_length |
Reference length used to nondimensionalize moments
about y, in scaled_grid_units. |
x_moment_center |
X-coordinate location of moment center,
in scaled_grid_units. |
y_moment_center |
Y-coordinate location of moment center,
in scaled_grid_units. |
z_moment_center |
Z-coordinate location of moment center,
in scaled_grid_units. |
Namelist &inviscid_flux_method
flux_limiter |
Flux limiter used, for example none for no limiter,
barth for Barth limiter, venkat for Venkatakrishnan limiter,
minmod for min-mod limiter, vanleer for van Leer limiter,
vanalbada for van Albada limiter, smooth for smooth
limiter. When using a limiter, the command line
option --freeze_limiter xx may also be of use. This option
freezes the value of the limiter throughout the flow field
after xx number of timesteps. This can be useful in
improving convergence that typically stalls or “rings” when
using a limiter. Note the reconstruction is evaluated at
each time step with the current “frozen” value of the limiter,
however if the reconstruction fails due to the extrapolation
to the cell face, the limiter is allowed to be recomputed at
these selected points. Finally, when restarting a solution that
has used a frozen limiter, if you wish to continue freezing the
limiter for the restart, you must specify --freeze_limiter 0.
Quotes are needed around the character string. |
|---|---|
first_order_iterations |
Number of first-order iterations prior to employing second
order spatial accuracy. Note: for time accurate
cases (time_accuracy not steady), this
is the number of first-order accurate sub-iterations to run
for each time step. |
flux_construction |
Method for constructing the flux, for example
vanleer for van Leer flux vector splitting,
roe for Roe flux difference splitting,
hllc for HLLC, aufs for AUFS, central_diss for
central differencing with scalar dissipation,
ldfss for LDFSS, stvd for STVD,
stvd_modified for modified STVD.
Roe’s scheme is suggested, but you may find that others
converge better for some cases.
For incompressible flow, the only valid option is roe.
Jacobians are van Leer by default.
Other Jacobians can be selected with --roe_jac, --hllc_jac,
--aufs_jac, or --cd_jac command line options.
Quotes are needed around the character string. |
rhs_u_eigenvalue_coef |
Eigenvalue coefficient for RHS, currently only used for
eqn_type = generic. See notes in the Hypersonics
section. |
lhs_u_eigenvalue_coef |
Eigenvalue coefficient for LHS, currently only used for
eqn_type = generic. See notes in the Hypersonics
section. |
Namelist molecular_viscous_models
prandtlnumber_molecular |
Molecular Prandtl number. |
|---|
Namelist &turbulent_diffusion_models
turb_model |
Name of turbulence model, for example sa for
Spalart-Allmaras one-equation model, des for Detached-Eddy
Simulation (DES) used in conjunction with the Spalart-Allmaras
model, menter-bsl for Menter BSL two-equation k-omega model,
menter-sst for Menter SST two-equation k-omega model,
wilcox-kw98 for Wilcox two-equation k-omega model (1998
version), abid-ke for Abid two-equation k-epsilon model.
Quotes are needed around the character string. |
|---|---|
turb_intensity |
Freestream turbulence intensity, Tu = sqrt(2k/(3 uinf2^)),
where k is the turbulent kinetic energy, currently only used for
eqn_type = generic. |
turb_viscosity_ratio |
Freestream ratio of turbulent viscosity to molecular
viscosity, currently only used for
eqn_type = generic. |
re_stress_model |
Defines whether linear or nonlinear stresses are employed in
the turbulence model, currently only used for
eqn_type = generic. Quotes are needed around the
character string. |
turb_compress_model |
Defines whether a turbulence compressibility model is
employed (on or off), currently only used for
eqn_type = generic. Quotes are needed around the
character string. |
turb_conductivity_model |
Defines whether a turbulence conductivity model is
employed (on or off), currently only used for
eqn_type = generic. Quotes are needed around the
character string. |
prandtlnumber_turbulent |
Turbulent Prandtl number, currently only used for
eqn_type = generic. |
schmidtnumber_turbulent |
Turbulent Schmidt number, currently only used for
eqn_type = generic. |
Namelist &nonlinear_solver_parameters
time_accuracy |
Defines the temporal scheme, for example steady for steady
state (non-time-accurate) runs, 1storder for time-accurate
first order backward differencing, 2ndorder for time-accurate
second order backward differencing, 2ndorderOPT for
optimized second order backward differencing (scheme is
inbetween second-order and third-order accurate
in time “BDF2opt”), 3rdorder for time-accurate
third order, 4thorderMEBDF4 for time-accurate fourth order
of type MEBDF4, 4thorderESDIRK4 for time-accurate fourth order
of type ESDIRK4. Quotes are needed around the
character string. |
|---|---|
time_step_nondim |
Physical time step, used only for time_accuracy not steady.
The nondimensionalization of this parameter depends on eqn_type:
for cal_perf_compress it is “dt a_ref/L”, where a_ref is the reference
speed of sound and L is unit 1 of the
grid; for cal_perf_incompress or generic it is “dt u_ref/L”,
where u_ref is the reference velocity. |
pseudo_time_stepping |
Defines whether pseudo-time stepping is used (on or off).
When used, the value of the time term (or the pseudo-time term for
time-accurate runs)
varies spatially according to a local “CFL constraint”.
This is the default method for time_accuracy = steady, and it
is also generally used for time-accurate runs as well (because
its use typically allows larger physical time steps
to be taken than might otherwise be possible).
When running time-accurately and ramping
the CFL of the pseudo time term, the final CFL
will be obtained only if subiterations >= the number of iterations
over which the CFL number is ramped. By the end of a
convergent subiteration process for time-accurate runs, the pseudo time
term drops out, giving the correct temporal discretization.
Quotes are needed around the character string. |
subiterations |
Number of subiterations applied to solve the implicit time
integration, only used for time_accuracy not steady. |
schedule_number |
Number of CFL ramping schedules to input (for changing the CFL number during a run), currently must be = 2. |
schedule_iteration |
Iteration numbers at which desired CFL numbers are defined (input
schedule_number of these). The parameter schedule_iteration (1) must = 1, because
it defines the starting CFL number at iteration number 1.
The actual CFL number is determined by a linear ramp from
schedule_cfl (1) at iteration schedule_iteration (1) to
schedule_cfl (2) at iteration schedule_iteration (2). |
schedule_cfl |
CFL numbers (input schedule_number of these). The parameter schedule_cfl (1)
is the CFL number desired at schedule_iteration (1), and
schedule_cfl (2) is the CFL number desired at schedule_iteration (2),
etc. For example, if you wish to start the run at a CFL number of
10 and ramp up to a CFL number of 200 at iteration number 50, then
schedule_iteration (1)=1, schedule_iteration (2)=50,
schedule_cfl (1)=10, schedule_cfl (2)=200. |
schedule_cflturb |
CFL numbers for turbulence equations (input schedule_number of
these). Not used for eqn_type = generic. |
invis_relax_factor |
Relaxation factor for inviscid terms, used only for eqn_type =
generic. See notes in the Hypersonics
section. |
visc_relax_factor |
Relaxation factor for viscous terms, used only for eqn_type =
generic. See notes in the Hypersonics
section. |
Namelist &linear_solver_parameters
meanflow_sweeps |
Number of Gauss-Seidel sub-iterations for the linear problem at each time step. |
|---|---|
turbulence_sweeps |
Number of Gauss-Seidel sub-iterations for
the turbulence model equations linear problem at each time step.
Not used for eqn_type = generic. |
line_implicit |
Defines whether implicit line sweeps are employed (on or off).
If used, it is suggested
to have previously invoked the command line option --partition_lines when
preprocessing with party. This will minimize the number of implicit lines
which may be cut by the partitioning. Quotes are needed around the character
string. |
Namelist &code_run_control
steps |
Number of time steps or multigrid cycles to run the code. |
|---|---|
stopping_tolerance |
Absolute value of the RMS (root mean square) residual at which the solver will terminate early. |
restart_write_freq |
Frequency of restart write based on time steps or multigrid
cycles. The solution and convergence history will be written
to disk every restart_write_freq time steps. |
restart_read |
Defines restart usage, for example off for no reading of old
restart files (i.e., run from scratch, with the flow
initialized as freestream), on for continuation run
from a restart file (flow is initialized by using
the previous solution information, and the convergence
history will be concatenated with the prior solution history),
on_nohistorykept for continuation run but
disregarding the previous history of residuals, forces, moments,
etc. Quotes are needed around the character string. |
jacobian_eval_freq |
Frequency of jacobian evaluation based on time steps or
multigrid cycles. After the first 10 iterations, Jacobians are updated
every jacobian_eval_freq iterations. |
Namelist &special_parameters
large_angle_fix |
Fix to neglect viscous fluxes in cells containing angles
equal to 178 degrees or more (on or off).
This flag is seldom required. However, you may encounter cases
on meshes with poor cell quality where the computation
will suddenly give NaNs during the solution process.
This is due to unusually large angles in the grid causing
gradients in the viscous fluxes to blow up.
(Watch for bad angles reported by the preprocessor.)
Quotes are needed around the character string. |
|---|
Differences from Earlier FUN3D.NML Namelist Versions
input_version = 2.2 – changed pseudo_time_stepping default from off to
on. (It should always be on when time_accuracy = steady.)
5.2. Running the Flow Solver
You can expect the solver to use approximately 300 words of memory per grid point. For example, a grid with one million mesh points (about 6 million tetrahedra) would require approximately 2.4 gigabytes of memory using 8-byte words. This amount will increase slightly with the number of processors (i.e., partitions), as there is an increasing amount of boundary data to be exchanged. Different solution algorithms will also affect the amount of memory required. For example, the full Jacobians required for a tightly-coupled solution of the turbulence model will increase the memory requirement significantly.
When you are ready to run an analysis, and you have set up the file
fun3d.nml (or ginput.faces for release 10.4.1 or before)
as described above, enter the following at the
command prompt:
nodet_seq
To run the MPI version of the solver on 16 processors, you would use the command:
mpirun -np 16 nodet_mpi
Depending on your local configuration, you may also need additional
arguments to mpirun, such as -nolocal and -machinefile [file].
See your MPI documentation or system administrator for more information
on such options.
If you have processed your grid and set up the input deck correctly, you
will then see the solver start to execute.
A detailed description of the output files is given below.
Upon completion, you can either restart your job where it left off, or
combine the partitioned solution files into global solution information
using the postprocessing feature of Party.
Command Line Options
These options are specified after the executable name (e.g.
nodet_seq, nodet_mpi, party, etc).
These commands are always preceded by -- (double minus). More than one
option may appear on the command line (each option proceeded by a -- ). You can always
see a listing of the available command line options in any of the codes in the
FUN3D suite by using the command line option --help after the executable name, e.g.:
./nodet_mpi --help
or
./party --help
etc.
The options are then listed in alphabetical order, along with a short description and a list of any auxiliary parameters that might be needed, and then the code is stopped. Specific examples of the use of command line options may be found throughout this manual.
Input Files
[project]_part.n
These files contain the grid information for each of the n partitions
in the domain.
They are generated using the Party utility.
fun3d.nml (for release 10.4.1 and before, this was ginput.faces)
This file is the input deck for the solver. The name must not be modified.
[project]_flow.n (Optional)
These files contain the binary restart information for each n grid
partitions.
They are read by the solver for restart computations, as well as by
party for solution reconstruction and plotting purposes.
stop.dat (Optional)
This file is intended to aid the user in gracefully halting the execution
of the solver if needed.
At the end of every iteration, the solver will look for this file.
If the file is present, it must contain a single ASCII integer.
If this integer is greater than zero and less than the number of
iterations already performed, the solver will dump the current
solution and halt execution.
The stop.dat file is removed just before the execution is halted.
movin_body.input (Time-dependent, moving grid cases only)
(replaces grid_motion.schedule of Versions 10.0 through 10.2.0)
This namelist file is used to specify grid motion as a function of time, and is used
in conjunction with the command line option --moving_grid . See the
moving grids section below for a more detailed description of this file.
A template for this file may also be found in the FUN3D source code directory.
rotor.input (For rotor/propeller computations only)
This file is used for specifying input quantities related to rotor/propeller
combinations, and is used in conjunction with the command line option --rotor .
See the rotorcraft section below on this capability for a more detailed
description of this file.
A template for this file may also be found in the FUN3D source code directory.
solution.schedule (Optional, for specifying generalized relaxation patterns)
This input deck allows for very general control over the various relaxation schemes and where they are to be applied across the domain.
A template for this file may be found in the FUN3D source code directory.
remove_boundaries_from_force_totals (Optional)
This file is for specifying boundaries that are NOT to be included in the calculation of force and moment totals. If this file is not present, then all solid boundaries are included in the force and moment totals. This file is useful, for example, in situations where there may be a mounting sting on a wind tunnel model, but only the forces on the model are actually of interest. Note that the forces on the specified boundaries are still computed, and appear in the [project].forces file, they are just not added to the totals.
A template for this file may be found in the FUN3D source code directory.
boundaries_to_animate (Optional, for time-dependent flow animation)
This file is for specifying which boundaries are output for animation of
time-dependent cases, and is used in conjunction with the command line option --animation_freq .
See the animation of unsteady flows section below on this capability for a more detailed
description of this file.
A template for this file may also be found in the FUN3D source code directory.
aeroelastic_boundaries (Optional, for aeroelastic coupling)
This file is for specifying which boundaries are treated as the aeroelastic surface. If not present,
the default is for all solid boundaries to be considered as part of the aeroelastic surface. This
optional file only has an effect when either (or both) of the command line options
--read_surface_from_file or --write_aero_loads_to_file are specified at run time. See the
aeroelastic coupling to an external structural model section below for
more information on how FUN3D can be used for aeroelastic simulations.
A template for this file may also be found in the FUN3D source code directory.
user_vol_init.input (Optional, for user-specified initialization of
compressible flows in INCOMP=0 path)
This file allows the user to specify regions in the field with
freestream quantities other than those defined by the fun3d.nml (or ginput.faces
prior to release 10.5.0) input file.
If a grid point is contained within a region, it will be initialized as
requested when the flow solver is first started.
Regions can be boxes, spheres, cylinders, and conical frustums. The box region is defined by diagonal end points. The sphere region is specified by a point and a radius. The cylinder region is defined by a radius and two points that define the cylinder axis, while the conical frustum adds a second radius to define a linear variation along the axis.
There can be as many regions as desired, and they may overlap each other as well as boundaries in the mesh. Each subsequent region in this file will supersede the regions listed before it in the event that a mesh point is contained in more than one region. Any special boundary conditions normally used by the solver will override these user-specified quantities (no-slip boundary conditions, specified mass flux, etc).
The initialization data is provided in terms of density, sound speed, and velocity components, non-dimensionalized in the usual FUN3D convention. Freestream quantities in the solver are normally given by the following:
rho0 = 1.0
c0 = 1.0
u0 = XMACH * cos(alpha) * cos(yaw)
v0 = -XMACH * sin(yaw)
w0 = XMACH * sin(alpha) * cos(yaw)For more details on the non-dimensionalization scheme, see the information provided at the CFL3D homepage , which uses the same scheme as FUN3D.
For an example, see user_vol_init.input in the FUN3D source code directory.
Note: This initialization method was first made available in v10.2.0,
and prior to v10.3.2, the file was named user_box_init.input because
only box-shaped regions were allowed.
Output Files
[project]_flow.n
These files contain the binary restart information for each n grid
partitions.
They are read by the solver for restart computations, as well as by
party for solution reconstruction and plotting purposes.
[project]_hist.tec
This file contains the convergence history for the RMS residual, lift, drag, moments, and CPU time, as well as the individual pressure and viscous components of each force and moment. The file is in Tecplot format.
[project]_subhist.tec2 (introduced version 3.2.3)
For time accurate computations only. This file contains the sub-iteration convergence history for the RMS residuals. The file is in Tecplot format.
[project]_time_animation.tec (introduced version 10.0)
For time accurate computations only, in conjunction with the command line
option --animation_freq .
This file contains an animation the grid and solution on selected boundaries
in Tecplot format. See the animation of unsteady flows section
for more information.
[project].forces
This file contains a breakdown of all the forces and moments acting on each individual boundary group. The totals for the entire configuration are listed at the bottom.
Test Case
To ensure that you have installed and are running the solver correctly,
a couple small test cases are included in the distribution.
Go into these directories and just type make.
You may find that the last one or two digits vary on different
machines/compilers, but your results should look very similar.
Boundary Layer Transition Location Specification
There is an option in FUN3D to specify transition which is based on the
idea of turning off the turbulent production terms in “laminar” regions
of the grid.
This is the same approach taken in CFL3D and NSU3D.
FUN3D results from this approach for a DLR-F6 transonic cruise condition
are shown in
AIAA Paper 2004-0554 in the Publications section.
For this option however, you have to generate a grid with the transition
location specified by having “laminar” and “turbulent” boundaries
defined upstream and downstream of the transition location.
When you specify the type for a laminar boundary use a negative number
for the viscous boundary types in the boundary definition file.
For example, a viscous solid boundary would be defined a -4 instead of
a 4 in the [project].mapbc file for a VGrid mesh.
In the flow solver, the field nodes will look at the type of boundary
closest to that field node to decide whether or not it is a laminar or
turbulent node.
To invoke specified transition for a specific run you must use the
command line option --turb_transition, e.g.:
mpirun -np 16 nodet_mpi --turb_transition
If you run the flow solver without the --turb_transition, it will
default to fully turbulent even though you have the laminar boundaries
defined.
Note this option is only valid for perfect gas SA turbulence model.
5.3. Rotorcraft
[Note: This capability was implemented by Dave O’Brien, at the time a PhD candidate at Georgia Tech.]
FUN3D is capable of modelling a rotating blade system using different levels of approximation. In order of increasing complexity/fidelity/cost, rotor systems may be modeled as either: 1) time-averaged actuator disk, 2) time-accurate actuator blades, or 3) “first princples” modeling of the moving, articulated, rotor blades using overset, moving grids.
Both actuator methods utilize momentum/energy source terms to represent the influence of the rotating blade system. Use of the source terms simplifies grid generation, since the actuator surfaces do not need to be built into the computational grid. However, the computational grid should have some refinement in the vicinity of the actuator surfaces to obtain accurate results.
Running An Actuator Surface Solution In FUN3D
The actuator surface routines are triggered through the use of
the --rotor command line option, e.g:
mpirun -np 16 nodet_mpi --rotor
Once the rotor option has been invoked, FUN3D will search
for the rotor input deck file, rotor.input.
This file is located in the FUN3D_90 directory and is required
along with the standard input file, fun3d.nml (or ginput.faces
prior to release 10.5.0).
The two main parameters used by the actuator surface solution are
mach_number in fun3d.nml (XMACH in
ginput.faces in release 10.4.1 and before) and Adv_Ratio in rotor.input.
These two parameters affect the force coefficient calculations.
To non-dimensionalize the forces with the rotor tip speed set
XMACH=Tip Mach Number and Adv_Ratio=V_freestream/V_tip.
To non-dimensionalize the forces with the freestream velocity set
XMACH=Freestream Mach Number and Adv_Ratio=1.0.
For incompressible solutions XMACH is the artificial compressibility
parameter (suggested value = 15.0), but the Adv_Ratio will still affect the
force non-dimensionalization as described above.
Running An Overset, Moving Mesh Solution In FUN3D
(Coming soon)
Sample Rotor Input Deck
A sample rotor.input file is shown below for a conventional main rotor
/ tail rotor helicopter.
# Rotors Vinf_Ratio Write Soln Force Ref Moment Ref
2 1.0 50 1.0 1.0
=== Main Rotor =========================================================
Rotor Type Load Type # Radial # Normal Tip Weight
1 0 50 720 0.0
X0_rotor Y0_rotor Z0_rotor phi1 phi2 phi3
0.00 0.00 0.00 0.00 -5.00 0.00
Vt_Ratio ThrustCoff PowerCoff psi0 PitchHinge DirRot
6.666 0.005 -1.00 0.00 0.00 0
# Blades TipRadius RootRadius BladeChord FlapHinge LagHinge
4 1.00 0.00 0.05 0.00 0.00
LiftSlope alpha, L=0 cd0 cd1 cd2
6.28 0.00 0.002 0.00 0.00
CL_max CL_min CD_max CD_min Swirl
1.50 -1.50 1.50 -1.50 0
Theta0 ThetaTwist Theta1s Theta1c Pitch-Flap
5.00 -2.00 0.00 0.00 0.00
# FlapHar Beta0 Beta1s Beta1c
0 0.00 0.00 0.00
Beta2s Beta2c Beta3s Beta3c
0.00 0.00 0.00 0.00
# LagHar Delta0 Delta1s Delta1c
0 0.00 0.00 0.00
Delta2s Delta2c Delta3s Delta3c
0.00 0.00 0.00 0.00
=== Tail Rotor =========================================================
Rotor Type Load Type # Radial # Normal Tip Weight
1 0 50 720 0.0
X0_rotor Y0_rotor Z0_rotor phi1 phi2 phi3
1.00 0.00 0.00 -90.00 0.00 0.00
Vt_Ratio ThrustCoff PowerCoff psi0 PitchHinge DirRot
3.333 0.001 -1.00 0.00 0.00 0
# Blades TipRadius RootRadius BladeChord FlapHinge LagHinge
3 0.20 0.00 0.01 0.00 0.00
LiftSlope alpha, L=0 cd0 cd1 cd2
6.28 0.00 0.002 0.00 0.00
CL_max CL_min CD_max CD_min Swirl
1.50 -1.50 1.50 -1.50 1
Theta0 ThetaTwist Theta1s Theta1c Pitch-Flap
8.00 0.00 0.00 0.00 0.00
# FlapHar Beta0 Beta1s Beta1c
0 0.00 0.00 0.00
Beta2s Beta2c Beta3s Beta3c
0.00 0.00 0.00 0.00
# LagHar Delta0 Delta1s Delta1c
0 0.00 0.00 0.00
Delta2s Delta2c Delta3s Delta3c
0.00 0.00 0.00 0.00
The header line is where the user specifies the number of rotors, the rotor advance ratio, and how often to output the plot3d loading file. The remainder of the file is in a block structure, where each block represents the inputs for one rotor. The first line of each block is a text line that can be edited to keep the rotors organized for the user.
Header Line Inputs
#Rotors |
Number of actuator surfaces to create. The number of variable blocks must match the number of rotors specified. |
|---|---|
Vinf_Ratio |
Ratio of V_freestream to V_force_ref, where V_freestream is the freestream velocity and V_force_ref is the velocity used for force normalization. For compressible flows, and forward flight, one typically has V_force_ref = V_freestream. |
WriteSoln |
Specifies how many iterations to run before writing the Plot3D rotor
loading data.
The suggested value is Write Soln = NCYC. |
Force Ref |
Conversion factor to allow user to obtain forces in desired units; = 1.0 for standard FUN3D nondimensional force coefficients; = ( L_ref x L_ref x a_ref x a_ref) / (pi x R x R x V_tip x V_tip) to get standard rotorcraft nondimensional force coefficients; = rho_ref x a_ref x a_ref x L_ref x L_ref to get dimensional forces |
Moment Ref |
Conversion factor to allow user to obtain moments in desired units |
Actuator Surface Inputs
RotorType |
Type of rotor model to apply.
Rotor Type=1 models the rotor as an actuator disk.
Rotor Type=2 models the rotor as actuator blades [In development]. |
|---|---|
LoadType |
Type of loading to apply to the rotor model.
Load Type=1 constant pressure jump.
Load Type=2 linearly increasing pressure jump.
Load Type=3 blade element based loading.
Load Type=4 user specified loading. |
#Radial |
Number of sources to distribute along the blade radius.
Suggested value is # Radial=100. |
#Normal |
Number of sources to distribute in the direction normal to the radius.
Suggested value is # Normal=720 for Rotor Type=1 (one source every
0.5 degrees).
Suggested value is # Normal=20 for Rotor Type=2. |
TipWeight |
Hyperbolic weighting factor for distributing sources along the blade
radius.
Input range is 0.0 to 2.0, values larger than 2.0 concentrate too many
sources at the blade tip.
Suggested value is Tip Weight=0.0 (uniform distribution) |
Rotor Reference System Placement and Orientation
X0_rotor |
The x coordinate of the hub (a.k.a. center of rotation). |
|---|---|
Y0_rotor |
The y coordinate of the hub (a.k.a. center of rotation). |
Z0_rotor |
The z coordinate of the hub (a.k.a. center of rotation). |
phi1 |
The first Euler angle describing a rotation about the x axis. |
phi2 |
The second Euler angle describing a rotation about the a2~ axis. |
phi3 |
The third Euler angle describing a rotation about the b3~ axis. |
The Euler angles are one of the more confusing inputs in the rotor input deck. These angles must be input correctly to obtain the correct orientation of the source based actuator disk. The angles should all be input in degrees.
The following example will attempt to explain how to determine these
angles.
The picture below depicts the rotations phi1 = 10, phi2 = -15, and
phi3 = 15.
Initially, the thrust is assumed to be in the z direction and the
disk in located in the x-y plane.
The first rotation of phi1 about the x_ axis takes the _x,y_,_z
system to the a_1~,_a2,a3~ system shown in red below.
The second rotation of phi2 about the a2~ axis takes the
a_1,_a2,a_3~ system to the _b1~,b_2,_b3~ system shown
in green below.
The final rotation of phi3 about the b3~ axis takes the
b_1,_b2,b3~ system to the rotor reference system shown
in blue below.
The black circle represents the initial disk orientation and the blue
circle represents the final disk orientation.
In general phi1 and phi2 are sufficient to define the thrust
orientation.
phi3 only serves to change the location of the zero azimuth angle
for the rotor.
Rotor Loading Parameters
Vt_Ratio* |
The ratio of the tip speed to the velocity used for force normalization, V_force_ref; if V_force_ref is V_freestream, then Vt_Ratio = 1 / Advance Ratio |
|---|---|
ThrustCoff |
The rotor thrust coefficient.
CT~ = Thrust / [ Densityref~ x pi x R2^ x ( OmegaDim x R )2^ ]
Used when Load Type=1 or Load Type=2.
Note: The blade element model does not trim to specified thrust coefficient. |
PowerCoff |
The rotor power coefficient [Not implemented]. |
Blade Parameters
psi0 |
The initial azimuthal position of blade 1; usually (always?) 0 |
|---|---|
PitchHinge |
The radial position of the blade pitch hinge (normalized by tip radius). |
#Blades |
The number of rotor blades, only used for Load Type=3. |
TipRadius |
The radius of the blade. |
RootRadius |
The radius of the blade root, used to account for the cutout region. |
BladeChord |
The chord length of the blade, only used for Load Type=3.
The can only handle rectangular blade planforms. |
FlapHinge |
The radial position of the blade flap hinge (normalized by tip radius). |
LagHinge |
The radial position of the blade lag hinge (normalized by tip radius). |
Blade Element Parameters, only used when Load Type=3
LiftSlope; alpha,L=0 |
Used to compute the lift coefficient. |
|---|---|
cd0, cd1, cd2 |
Used to compute the drag coefficient. |
CL_max, CL_min |
Limiters to control the lift coefficient beyond the linear region. |
CD_max, CD_min |
Limiters to control the drag coefficient. |
Swirl |
Swirl=0 neglects the sources terms that create rotor swirl.
Swirl=1 includes the swirl inducing terms. |
CL~ = LiftSlope x (alpha – alphaL=0)
CD = cd0 + cd1 x alpha + cd2~ x alpha2
Pitch Control Parameters, only used when Load Type=3
Theta0 |
Collective pitch in degrees, defined at r/R=0. |
|---|---|
ThetaTwist |
Linear blade twist. |
Theta1s |
Longitudinal cyclic pitch input in degrees. |
Theta1c |
Lateral cyclic pitch input in degrees. |
Pitch-Flap |
Pitch-Flap coupling parameter, not implemented. |
Theta = Theta0 + ThetaTwist x r/R + Theta1s x cos(psi) + Theta1c x sin(psi)
Prescribed Flap Parameters
#FlapHar |
Number of flap harmonics to include, valid input range is 0 to 3 |
|---|---|
Beta0 |
Coning angle in degrees |
Beta1s, Beta1c |
Fist flap harmonics |
Beta2s, Beta2c |
Second flap harmonics |
Beta3s, Beta3c |
Third flap harmonics |
Beta = Beta0 + Beta1s x sin(psi) + Beta1c x cos(psi) + Beta2s x sin(2 psi) + Beta2c x cos(2 psi) + Beta3s x sin(3 psi) + Beta3c x cos(3 psi)
Prescribed Lag Parameters
#LagHar |
Number of lag harmonics to include, valid input is 0 to 3 |
|---|---|
Delta0 |
Mean lag angle in degrees |
Delta1s, Delta1c |
Fist lag harmonics |
Delta2s, Delta2c |
Second lag harmonics |
Delta3s, Delta3c |
Third lag harmonics |
Delta = Delta0 + Delta1s x sin(psi) + Delta1c x cos(psi) + Delta2s x sin(2 psi) + Delta2c x cos(2 psi) + Delta3s x sin(3 psi) + Delta3c x cos(3 psi)
5.4. Hypersonics
Main Solver Input File
Subsequent to release 10.4.1, the old input file ginput.faces
was replaced by a namelist file. Many of the input parameters for
hypersonic (generic gas) cases are given there, as described in
the Flow Solver Namelist Input section.
The generic gas path can currently accommodate perfect-gas, equilibrium
gas, and mixtures of thermally-perfect species in chemical and/or
thermal non-equilibrium. The user specifies the gas model in a separate
file called tdata to be defined later.
Note that in the generic gas path, the turbulent model equations are solved in a fully coupled manner with the other conservation laws.
Two options are available for second-order spatial accuracy.
When flux_construction = roe,
then the right and left states are
reconstructed to second-order using primitive variable gradients
computed using least squares from the right and left nodes.
These gradients may in turn be limited according to the standard
definition of flux_limiter in FUN3D.
When flux_construction = stvd, then the right and left states use the
nodal values (first-order-formulation) but a second-order,
anti-dissipative correction is introduced using a
STVD (Symmetric Total Variation Diminishing) formulation involving the
same nodal values of gradients.
In this case there is no limiting of gradients, other than that occurring
in the STVD formulation.
Mach number and Reynolds number per grid unit are computed from the
fundamental inputs of velocity, density, and temperature.
If a non-constant wall temperature boundary condition is specified (see
Boundary Conditions for Generic Gas Option) then the parameter
temperature_walldefault serves
only to initialize the surface boundary condition.
The flag chemical_kinetics is engaged only in the case of multiple species defined in
file tdata.
If chemical_kinetics is set to frozen for
chemically frozen flow then the chemical source
term is never called and species mass fractions can only be changed
through the action of diffusion.
If it is set to finite-rate for chemically reacting flow then the chemical
source term is called and species mass fractions change by kinetic
action of dissociation, recombination, ionization, and de-ionization.
The flag thermal_energy_model is set to frozen for thermally frozen flow or
to non-equilib
for thermally active flow (flow in thermal non-equilibrium).
This flag is engaged only when a thermal non-equilibrium model is
specified in the file tdata; otherwise thermal equilibrium is
assumed.
If it is set to frozen for thermally frozen flow then the thermal energy
exchange source term is never called and the modeled modal temperatures
(vibrational, electronic) can be changed only by the action of
conduction.
(Translational temperature still evolves through the action of flow work
but this energy is never transferred to internal energy modes.)
If it is set to non-equilib then the source term models particle collisions in
which particle internal energy in the translational, rotational,
vibrational, and electronic modes can be exchanged.
The parameter invis_relax_factor is a relaxation factor on the update, dq, to the
conservative flow variables q.
Before an update, dq is divided by the maximum value of five limiting
factors including invis_relax_factor.
The first four limiting factors are computed internally and designed to
limit the rate of change of pressure, density, temperature, and
velocity.
If invis_relax_factor is set to 1.0, no further limiting is engaged.
The parameter visc_relax_factor is a relaxation factor that multiplies only the
viscous Jacobian.
Its value should be set to 1.0; it is retained here as a place holder
for future research.
The parameter rhs_u_eigenvalue_coef is the eigenvalue limiter.
It acts only on the evaluation of the eigenvalues used on the
right-hand-side convective portion of the residual using Roe’s method.
If eigenvalues are less than rhs_u_eigenvalue_coef times the local sound speed then a
formula due to Harten is employed to smoothly limit the eigenvalue.
Numerical tests show that the heating and solution quality near the wall
are severely compromised using eigenvalue limiting when tetrahedra are used
throughout.
The parameter value should be set to 1.e-30 (it must be positive
definite) in this case.
It is retained as an input parameter in case it is needed, as in the
structured grid approach of LAURA, when prismatic elements are
introduced.
The parameter lhs_u_eigenvalue_coef is also an eigenvalue limiter but is applied only
in the evaluation of the inviscid Jacobian (left-hand-side) by Roe’s
method.
Recommended values between .001 and 1.0 provide a more well-determined
matrix.
Larger values enhance robustness with the possible penalty of slower
convergence, particularly in stagnation regions.
Gas Model Input File
The file tdata defines the gas model.
Information in this file is likely to change from one application to
another, depending on the flow regime, velocity, and atmospheric
composition.
It contains a list of key words, sometimes followed by numeric values,
which identify components of the gas model.
One or more spaces must separate keyword and values when appearing on
the same line.
Spaces may appear to the left or right of any key word.
The first line of the file must not be blank.
Options for perfect-gas, equilibrium gas, and mixtures of thermally
perfect gases can be accommodated. An example of the input data file
tdata used for each will be presented.
Perfect Gas
The filetdata contains a single line for perfect air using
Sutherland’s law for viscosity.
gamma_air 1.4This option will model air as a perfect gas.
Equilibrium Gas
[work in progress]
Mixture of Thermally Perfect Gases
two N2 .767 N O2 .233 O NO H2 N2 H2O H OHThe first entry of the file may contain an optional flag which identifies the thermal model. If no thermal flag is present or if the flag says
one, One, or ONE
then the gas is in thermal equilibrium (a one-temperature model).
If there is no thermal flag then the first line of this file must
contain species information as described in the next paragraph; this
file cannot begin with a blank line.
If the flag says two, Two, or TWO then the gas is modeled using a
two-temperature model.
The two temperature model assumes energy distribution in the
translational and rotational modes of heavy particles (not electrons)
are equilibrated at temperature T and all other energy modes
(vibrational, electronic, electron translational) are equilibrated at
temperature $T_V$.
No other thermal models are currently available; however, the source
code is written to accommodate an arbitrary number of additional thermal
degrees of freedom.
Subsequent file entries include species names, appearing exactly as
defined in the master data file species_thermo_data (see below).
If a value appears to the right of the species name, separated by one or
more spaces, then that value denotes the mass fraction of the species at
an inflow boundary.
If no value appears to the right of the species name then that species
is not present on inflow but may be produced through chemical reactions
elsewhere in the flow field.
Multiple instances of inflow boundaries can be accommodated. However, this option is not yet been exercised. For example, air may flow in from an inlet boundary and fuel may flow in from a separate inflow port. A blank line (line (7) in the example) separates instances of inflow boundary conditions. If new species are introduced in subsequent instances they are automatically initialized to zero at any previous inflow boundary. They are also available as a reactant throughout the entire flow field.
Thermodynamic Data Input File
The filespecies_thermo_data is the master file for species
thermodynamic data.
Here is a sample.
C &species_properties molecule = .false. ion = .false. elec_impct_ion = 11.264 ! Moore ? 4.453 in mars.F siga = 7.5e-20, 5.5e-24, -1.e-28 mol_wt = 12.01070 / 3 0.64950315E+03 -0.96490109E+00 0.25046755E+01 -0.12814480E-04 0.19801337E-07 -0.16061440E-10 0.53144834E-14 0.00000000E+00 0.85457631E+05 0.47479243E+01 200.000 1000.000 -0.12891365E+06 0.17195286E+03 0.26460444E+01 -0.33530690E-03 0.17420927E-06 -0.29028178E-10 0.16421824E-14 0.00000000E+00 0.84105978E+05 0.41300474E+01 1000.000 6000.000 0.44325280E+09 -0.28860184E+06 0.77371083E+02 -0.97152819E-02 0.66495953E-06 -0.22300788E-10 0.28993887E-15 0.00000000E+00 0.23552734E+07 -0.64051232E+03 6000.000 20000.000 gamma_air &species_properties molecule = .true. ion = .false. mol_wt = 28.8 suther1 = 0.1458205E-05 suther2 = 110.333333 prand = 0.7 / 1 0.00000000E+00 0.00000000E+00 0.10000000E+01 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.0 100000.000A species record consists of the species name, a species properties namelist, the number of thermodynamic property curve fit ranges, and the curve fit coefficients for each range.[1]
1 B. J. McBride and S. Gordon, “Computer Program for calculation of Complex Chemical Equilibrium Compositions and Applications”, NASA RP 1311, June 1996.
5.5. Time Accurate – Basics/Fixed Geometry
The basic input parameters for running fixed-mesh, time-dependent cases, are described under Flow Solver Input Deck . This section describes other essential information needed to run fixed-mesh time-dependent cases, and time-dependent cases in which the geometry moves.
| Nondimensionalization |
| Temporal Order of Accuracy |
| Temporal Error Controller |
| Animation of Unsteady Flows |
Nondimensionalization
A description of the nondimesionalization is under construction; in the interim, the description given in the CFL3D documentation will suffice. For compressible flows, the two codes use exactly the same nondimensionalization. Note that for incompressible flow (for which CFL3D has no counterpart), the reference velocity is the freestream velocity, rather than the freestream speed of sound.
Temporal Order of Accuracy
Currently, the available time-advancement schemes in FUN3D are multistep, backward difference (BDF) schemes. Second-order accuracy (itime = 2) has been the order of choice for a long time, although in Version 10.0, third order (itime = 3) and an “in between” second and third order scheme (“BDF2opt”, itime = -3) were added. Note that the third-order scheme is not guaranteed to be stable; in practice this is usually not a problem, but in a few cases the lack of guaranteed stability has lead to solutions which diverge after a very long time. The BDF2opt is guaranteed to be stable and hence is recommended if accuracy higher than second order in time is needed. Bear in mind that for practical applications, solution accuracy is likely to be limited by low grid resolution, so a high-order time advancement may not lead to improved overall accuracy. First order accuracy in time is rarely used. A possible exception being to reproduce steady state convergence while running in unsteady mode – as may be needed for static aeroelastic applications, for example. With a very large time step (e.g. 1.e20) and first-order time accuracy (itime=1), the time-accurate path will converge exactly as the steady state path (itime=0).
Temporal Error Controller
The name is somewhat misleading, in that this controller addresses one source of temporal errors, namely, insufficient subiterations. As described in the Flow Solver Input Deck section, the user must specify the number of subiterations in pseudo time in between each physical time step. Ideally, enough subiterations should be used to converge the mean flow and turbulence residuals to machine zero. That of course is prohibitively expensive, so a more reasonable number of subiterations must be used. The question then is, how manny subiterations are enough? It has also been observed that a certain points during unsteady simulations, subiterations converge faster, and conversely slower at other times in the simulation. Using a fixed number of subiterations sufficient for the harder portions means there will be an excess of iterations on the easier portions, thereby wasting cpu time.
The temporal error control options seeks to mitigate these issues by providing a well-founded cutoff. When using the controller, a reasonably large number of subiterations is specified, perhaps 25 to 75. The error controler itself is invoked with the command line option
--temporal_err_control TOL
where TOL is a real valued tolerence. Limited callibration studies suggest a value of 0.05 to 0.1 is reasonable. When run with this command line option, the solver will obtain an estimate of the temporal error, and when the x-momentum and turbulence residuals drop below TOL times the estimated error, the subiteration loop will terminate. If the tolerence is not reached by the end of the specified number of subiterations, a warning message is printed.
Animation of Unsteady Flows
Boundary Surface Animation
There is a limited capability to output TECPLOT files for animation of unsteady solutions. Specifically, the boundaries of the domain may be output, but no interior data is currently able to be output. Note that although this capability is generally intended for unsteady flows, the same command line options may be used to animate the convergence to the final state for steady state runs if desired.
Animation is enabled within the flow solver with the command line option:
--animation_freq INT
where INT is the (integer) frequency at which the boundary data is output. For example, if int = 1, the boundary data is output at every time step: 1, 2, 3, 4,...; if int = 4, the boundary data is output every fourth time step: 4, 8, 12, 16,... If int < 0, then the boundary data is output only for the last cycle/timestep. If the solution is being started from a steady state solution, (itime > 0 and irest = -1), then the initial solution is also output to the animation file.
The animation data is written to an ascii formatted TECPLOT file with the naming convention:
{project}_time_animation.tec
The variables output to this file are: x, y, z, rho, u, v, w, p/pinf, and cp at each output time step.
Caution: the ascii formatted files can become very large. An exisiting [project]_time_animation.tec is appended to on subsequent restarts (irest = 1). If irest = -1 an existing [project]_time_animation.tec will be deleted and a new one created.
By default, all solid boundaries for 3D cases are output if the --animation_freq command line is invoked; for
2D cases, the default is to output one of the y=constant symmetry planes.
The user may override these defaults by providing an auxiliary file with the name:
boundaries_to_animate
An example of the boundaries_to_animate file is given below:
File for specifying which boundaries are to be output when using --animation_freq No. boundaries to output (be careful with boundary lumping) 2 Boundary to output 3 5
In this case the animation file will contain only boundaries 3 and 5. If lumping is used, be sure to verify the correct boundary numbers from the [project].part_info file from party.
For moving bodies, it is also possible specify the motion of an observer, such that the resulting animation is relative to the observer’s reference frame, rather than the inertial frame. Observer motion not available in versions earlier than 10.4. See Specifying Observer Motion
“Sliced” Data Animation
Begining with Version 10.4, a limited ability to take planar cuts through boundary surface data is available from within the flow solver. For example, spanwise cuts along a wing may be taken, and then the resulting pressure and skin friction data may be plotted at each station. This capability largely parallels that of the box5/box6 utility codes, with the added ability to handle unsteady flows in a simple fashion.
The sliced data is written to an ascii formatted TECPLOT file with the naming convention:
{project}_slice.tec
The variables output to this file are: x, y, z, cp, cfx, cfy, cfz at each output time step.
Slicing occurs in the inertial frame unless an alternate reference frame is specified. For stationary geometries, the default inertial frame is the only orrect choice. For moving body cases, either the frame of one of the moving bodies (see Defining Moving Bodies) or an observer frame (see Specifying Observer Motion) may be more appropriate.
Surface data slicing is enabled within the flow solver with the command line
option:
--slice_freq INT
where INT is the (integer) frequency at which the boundary data is sliced.
The --slice_freq option operates exactly as --animation_freq
In addition to this command line option, specific instructions on where to take the slices must be provided in an auxiliary file with the name:
slice_global_bndry.input
This file contains namelist &slice_data:
An (S) following a variable description implies that the data may be specified for each slice; a (G) implies the data applies to all slices
&slice_data namelist
nslices |
Number of slices to create (G) (Default: 0); if negative, then data for only one slice station need be input, along with a spacing increment, and all the data specified for the first station will be applied to subsequent stations, with the exception of the slice location, which will be set using the spacing increment |
|---|---|
slice_increment |
Increment in slice location between consecutive slice stations (G) (Default: 0.0); to be
utilized with nslices < 0, in which case the value should be explicitly set, as the
default increment will place all slices at the same location as the first slice; if
nslices > 0, the value of slice_increment is unused |
slice_frame |
Name of the reference frame in which slice is to be taken (S) (Default: ’’ [indicates inertial frame] ); for moving geometries, to specify the observer frame, use ‘observer’; to specify the frame of a particular body, use ‘body_name’, where body_name is that specifed in the &body_definitions namelist |
slice_x |
Slice to be taken parallel to x-direction in the specified reference frame (S) (Default: .false.) |
slice_y |
Slice to be taken parallel to y-direction in the specified reference frame (S) (Default: .true.) |
slice_z |
Slice to be taken parallel to z-direction in the specified reference frame (S) (Default: .false.) |
slice_location |
Coordinate value at which slice is taken (S) (Default: 0.0) |
n_bndrys_to_slice |
Number of candidate boundaries to search while computing slice-plane intersections (S) (Default: all solid boundaries). Specifying which boundaries are candidates for slicing may speed up the slicing process; may also be used to filter out unwanted intersecions or to slice non-solid boundaries |
bndrys_to_slice |
List of n_bndrys_to_slice boundaries that will be searched to compute the slice-plane intersection (S) (Default: all solid boundaries) |
xx_box_min |
Minimum x-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: negative huge number – i.e. no bounding) Specifying bounding box surfaces can aid in filtering out unwanted intersections |
xx_box_max |
Maximum x-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: positive huge number – i.e. no bounding) |
yy_box_min |
Minimum y-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: negative huge number – i.e. no bounding) |
yy_box_max |
Maximum y-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: positive huge number – i.e. no bounding) |
zz_box_min |
Minimum z-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: negative huge number – i.e. no bounding) |
zz_box_max |
Maximum z-ccordinate used to define a bounding box to constrain the slicing. (S) (Default: positive huge number – i.e. no bounding) |
5.6. Time Accurate – Moving Geometry
This section describes the capability for simulating flows with moving/changing geometry. It is strongly recommended that the user become familiar with time-dependent stationary-geometry simulations before attempting moving-geometry cases.
Moving Bodies/Grids – General Information
NOTE: this is an active area of development, so implementation or input details may change with time.
The ability to move the grid as a rigid body (no deformation) was introduced in Version 10.0; prior versions have no provisions for moving geometries. Later versions have increased capability for deforming meshes, thereby allowing some distinction between “body motion” and “grid motion”. The current nomenclature is such that one specifies the motion of a “body” (a collection of one or more solid surfaces within the grid), and associates with that body a mechanism for moving the surrounding grid points – either rigidly, so that all points move in concert with the body, or in a deforming manner so that points near the body move in concert with the body, but points far away move little, if at all.
Note: At the present time, simulations in which “large” amplitude body motions occur should be generally be limited to single bodies with rigid mesh movement; for “small” motions it is possible to have multiple bodies moving relative to one another if the deforming mesh option is used. Until such time as it is possible to dynamically compute overset connectivities from within FUN3D (a capability under development), large relative motions involving multiple bodies are generally not possible. “Generally” being the operative word; an example is given below of a set of two flapping, pitching, rotating blades in which the large motion (rotation) is handled via rigid grid movement and smaller motions (pitch, flap) are accommodated by mesh deformation.
Grid motion is enabled via the command line option
--moving_grid
In addition to this command line option, an additional file is required to specify the details of the body motion, and to specify how the grid is moved to accommodate the motion of the body. In Versions 10.0 through 10.2 this auxiliary file was called grid_motion.schedule; beginning with Version 10.3, the file is called moving_body.input, and it is now a file of namelists. Below is a description of the use of moving grids in Version 10.3 and higher; see Moving Grids In Versions 10.0 Through 10.2 to find information on the earlier usage.
The --moving_grid command line and moving_body.input file are also required for postprocessing moving grid solutions with party.
Contrary to earlier versions of the flow solver, the part files are not modified as the grid is moved. Thus the part files always
contain the grid at is was at t=0; the restart (flow) files now contain the mesh coordinates for the current position.
Thus it is not possible to restart old moving grid solutions with the current solver.
Data in the moving_body.input file is used to define the motion of one or more “bodies”, which are user-defined collections of solid boundaries in the mesh. Grid motion is specified to accommodate the motion of the bodies: either rigid (all nodes of the mesh rotate/translate in unison with the body) or deforming (the mesh locally deforms to accommodate the motion of the solid body). Rigid mesh movement is very fast compared to a flow solution; mesh deformation requires the iterative solution to an elasticity PDE, and can range in cost from a fraction of a (time-accurate) flow solve to more than a (time-accurate) flow solve, depending on the stiffness of the elasticity PDE. Mesh deformation requires additional input files compared to rigid mesh motion, and is discussed further in the Mesh Deformation section
Two useful commandline options, especially for complex mesh movements, are
--grid_motion_only
which moves the grid without solving the flow equations, and
--body_motion_only
which moves only the body without solving the elasticity equations or the flow equations.
These options will generally be used
with the Animation of Unsteady Flows capability so that the resulting body/grid motion can
be visualized. The first option, --grid_motion_only is all that is needed for checking rigid
mesh motion input data, as the cost of moving all mesh points is very small,
and there is no chance of generating negative volumes during the the course of moving. For deforming meshes,
--body_motion_only should be used first to verify that the desired body motion has been input; this
process runs very quickly (relative to a flow solve). Once the body motion is verified, the case can be
rerun with --grid_motion_only to verify that the mesh can be deformed to follow the specified body motion
without generating negative volumes. See the section on Mesh Deformation for more
information. Once the body/mesh motion input data has been verified are correct, the flow solution may be
carried out.
If the command line option --moving_grid is invoked, the file moving_body.input must be present
in the project directory. This file may contain data for one or more of the following namelists:
&body_definitions – defines which mesh surfaces define the moving bodies
&forced_motion – specifies body motion as a function of time
&observer_motion – specifies motion of an observer as a function of time for animation purposes
&surface_motion_from_file – specifies body motion from one or more files
&sixdof_motion – specifies mass/inertial properties for bodies with 6DOF motion
&aeroelastic_modal_data – specifies modal data for static/dynamic aeroelastic analysis via time integration of the structural dynamics equations within FUN3D (Version 10.4 and higher)
Descriptions of the variables in each namelist, and their default values, are given in subsequent sections. Note that because the data are in namelists, only data that is different from the default typically need be specified. The exception is that some data for the body_definitions namelist MUST be specified to define the body of interest (e.g. the default number of bodies is 0 and must be changed); data for the other namelists may be optional depending on the application.
Sample moving_body.input files and the resulting body/grid motions are given below (animations of the motion require Flash Player‘g to view).
Post-Processing/Repartitioning Moving Grid Cases
To post-process (or repartition) moving grid cases using party, you must use the
command line option --moving_grid.
For versions 10.4 and higher, in the post-processing mode, party will give the option of viewing the results in the inertial frame or in a moving-body frame. Note: the choice is only meaningful for specified motion cases or 6DOF cases; for aeroelastic and surface-from-file cases, both options give the inertial-frame view. Below, pressure contours and velocity vectors from a falling (6DOF) cylinder case are shown from both the inertial and body frames. Pressure, being a scalar, appears the same in both views. The fluid velocity at the surface in this viscous flow problem must be identical to the surface velocity: in the inertial frame, this is the instantaneous body velocity (in -z direction); in the body frame, the body (and hence fluid) velocity is zero.
Defining Moving Bodies
The following namelist, which is input via the moving_body.input file, is used to specify
one or more bodies as collections of boundary surfaces within the mesh. This namelist
is required for all moving body/mesh cases, i.e. whenever the --moving_grid command line
option is invoked. The input structure
is fairly general in that the motion of multiple bodies may be specified, and connections
between various bodies may be specified via family trees. For example, a wing-flap system
may be defined such that the flap is a child of the wing. Thus the flap inherits any motion
specified for the wing, and may have its’ own motion specified on top of that. For example,
the wing may be specified to translate up and down, and the flap to rotate about a hinge
line such that the net motion of the flap is a combination of translation and rotation.
Such a wing-flap system is given in one of the examples below.
A (G) following a variable description means that this is a global descriptor, i.e. applicable to all moving bodies; a (B) following a variable description means that the data may be specified for each moving body
&body_definitions namelist
n_moving_bodies |
Number of bodies in motion (G) (Default: 0) |
|---|---|
body_name |
Name to identify the body (B) (Default: ’’) |
parent_name |
Name of the parent body (B) (Default: ’’ [indicates inertial ref. frame as parent]) |
n_defining_bndry |
Number of boundaries that define the body (B) (Default: 0) |
defining_bndry |
List of n_defining_bndry boundaries that define the body (B) (Default: 0) |
motion_driver |
Mechanism by which body motion is driven (B) (Default: ‘none’ Options: ‘forced’, ‘6dof’, ‘file’, ‘aeroelastic’) |
mesh_movement |
Type of grid movement associated with body motion (B) (Default: ‘static’ Options: ‘rigid’, ‘deform’) |
x_mc |
X-coordinate of moment center at t=0 (B) (Default: xmc from input file) |
y_mc |
Y-coordinate of moment center at t=0 (B) (Default: ymc from input file) |
z_mc |
Z-coordinate of moment center at t=0 (B) (Default: zmc from input file) |
s_ref |
Reference area (non-dimensional) for force/moment normalization (B) (Default: sref from input file) |
c_ref |
Reference length (non-dimensional) for force/moment normalization (B) (Default: cref from input file) |
b_ref |
Reference length (non-dimensional) for force/moment normalization (B) (Default: bref from input file) |
move_mc |
Flag to move (1) or leave the moment center fixed in space(0) (B) (Default: 1) |
dimensional_output |
Logical flag to output the body state data (displacements, velocities, and aero forces) in dimensional form for forced or 6DOF motions (G) (Default: .false.) |
ref_length |
Reference length for converting to dimensional output (G) (Default: 1.0 ft.) |
ref_density |
Reference density for converting to dimensional output (G) (Default: 0.002378 slug/ft/ft/ft) |
ref_velocity |
Reference velocity for converting to dimensional output (G) (Default: 1117.0 ft/sec) |
Specified Body Motion
The following namelist, which is input via the moving_body.input file, is used to specify
how the body(ies) defined via the &body_definitions namelist move as a function of time. Note
that this is one of two ways body motion may be specified, and is appropriate if the desired
body motion may be described as a simple rigid-body translation or rotation, with constant velocity
or sinusoidally-varying displacement. For specified motions not amenable to such basic
descriptions, the body surface points may be specified at each time step via a file (see
Body Motion via File Input), so that
any desired motion can in principle be defined (including shape-morphing bodies), with
the complication that the associated
mesh motion must be accommodated via deformation rather than rigid-grid motion.
A (B) following a variable description means that the data may be specified for each moving body
&forced_motion namelist
rotate |
Type of rotational motion 0=none, 1=constant rotation rate, 2=sinusoidal (B) (Default: 0) |
|---|---|
rotation_rate |
Rotation rate (non-dimensional) associated with rotate=1 (B) (Default: 0.0) |
rotation_freq |
Rotation reduced frequency (non-dimensional) associated with rotate=2 (B) (Default: 0.0) |
rotation_amplitude |
Rotation amplitude (degrees) associated with rotate=2 (B) (Default: 0.0) |
rotation_origin_x |
X-coordinate of rotation center (B) (Default: 0.0) |
rotation_origin_y |
Y-coordinate of rotation center (B) (Default: 0.0) |
rotation_origin_z |
Z-coordinate of rotation center (B) (Default: 0.0) |
rotation_vector_x |
X-component of unit vector along rotation axis (B) (Default: 0.0) |
rotation_vector_y |
Y-component of unit vector along rotation axis (B) (Default: 1.0) |
rotation_vector_z |
Z-component of unit vector along rotation axis (B) (Default: 0.0) |
rotation_start |