6. Analysis
6.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,
! hminmod, hvanleer, hvanalbada, hsmooth
! (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, dldfss, 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, hrles
! (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. For example, if
the namelist name linear_solver_parameters were to be misspelled as
linear_solver_parameter (missing “s”), then all parameters within that
namelist that you think you are specifying would be ignored, and they would
assume their default values.
This is one good reason to always leave
namelist_verbosity = on, so the top of the screen output has a record
not only of what you input, but also what the code is using as well. 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).
Additional information and warnings (if necessary) are also given.
This setting (on) is the recommended option, because the user can check to see
all of the parameters being used by the code, whether explicitly being specified
in the namelist file or implicitly being used by default.
When off, only the input 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, hminmod for hypersonic-minmod limiter,
hvanleer for hpersonic-van Leer limiter,
hvanalbada for hpersonic-van Albada limiter,
hsmooth for hpersonic-smooth limiter, and
hvenkat for hypersonic-Vankatakrishnan limiter,
For hypersonic flows computed using the calorically perfect gas path
the hvanleer or hvanalbada flux limiters are recomended.
Please note that use of the h-series of flux limiters automatically turns on a
heuristic pressure based limiter that is used to augment the selected flux limiter.
When using a mixed elment grid (where the near wall grid is made up of either
hexes or prisms) the wall heat transfer and skin friction can be improved by
selecting the hminmod, hvanleer, hvanalbada, hsmooth, or
hvnekat limiters and invoking the command line option --limit_near_walls_less.
This option causes these flux limiter to be automatically “turned off” as the
grid approaches the wall. However use of this option on tetrahedral grids near
the wall can make the wall heat transfer and skin friction worse.
Use of this option may cause a decreas in robustness so use it with caution.
When using the barth, venkat, hminmod, hvanleer, hvanalbada, hsmooth, or
hvnekat 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, dldfss for Dissipative 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.
Please note for hypersonic flows computed using the calorically perfect gas path
the dldfss scheme is recomended.
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,
hrles for hybrid RANS-LES model of AIAA-2008-3854.
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.)
6.2. Boundary Condition Namelist Input
6.3. 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_90 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_90 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_90 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_90 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_90 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_90 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.
6.4. 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 + Theta1c x cos(psi) + Theta1s 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)
6.5. 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.
6.6. 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 |
tecplot_slice_output |
Output the sliced data (coordinates, Cp, Cf, etc) to a (formatted) Tecplot file, for anmiation (G) (Default: .true.) |
output_sectional_forces |
Output detailed force and moment data for each slice to a (formatted) file, this file contains F/M data like that in the [project].forces file, only for each and every slice. In addition, it contains geometrical data for each slice (le/te coordinates, moment center, etc.) Caution: for unsteady flows with frequently written data at many slice locations, this file can become very large. On the other hand, the data in the file, especially the geometry data, can be useful to assess whether the slicing is working as expected (G) (Default: .true.) |
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 |
replicate_all_bodies |
An “easy button” to set similar slice stations on multiple bodies with minimal
input beyond that required for slicing the first body. Particularly useful for
rotorcraft applications where multiple blades are to be sliced. This variable
duplicates the input slice info for all moving bodies, with the exception of
slice_frame and the bndrys_to_slice data (G) (Default: .false.) |
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) |
slice_group |
Assign this slice to a particular group number; within a group, slice locations are expected to be givien in ascending order; multiple slice groups can be used to circumvent this (S) (Default: 1) |
le_def |
number of points to consider when defining the “leading edge” of the slice; a positive number indicates an average over the points, a negative number indicates a parabolic fit over the points (S) (Default: -10 – parabolic fit over 10 points) |
te_def |
number of points to consider when defining the “trailing edge” of the slice; a positive number indicates an average over the points, a negative number indicates a parabolic fit over the points (S) (Default: +1 – “average” over 1 point, i.e. just use max coord. value of the slice) |
chord_dir |
Direction of local chord relative to the direction from leading edge to trailing edge; +1 indicates local chord in direction le -> te; -1 indicates local chord in direction te -> le (S) (Default: +1) |
use_local_chord |
Use the computed local (sectional) chord, based on the computed LE and TE locations, to normalize the sectional force and moment data; otherwise the input value of Cref will be used. (G) (Default: .true.) |
slice_xmc |
x-coordinate of the moment center in the specified reference frame (S) (Default: computed “quarter chord” of the slice) |
slice_ymc |
y-coordinate of the moment center in the specified reference frame (S) (Default: computed “quarter chord” of the slice) |
slice_zmc |
z-coordinate of the moment center in the specified reference frame (S) (Default: computed “quarter chord” of the slice) |
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) |
6.7. 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.
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 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)
&composite_overset_mesh – specifies component meshes to associate with moving and non-moving bodies in the simlulation – only used if overset grids are utilized. See Oveset Grids for more information.
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 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.) |
body_frame_forces |
Logical flag to output the (aerodynamic) forces/moments on the body in the body-frame (G) (Default: .false. i.e. output forces/moments in inertial frame) |
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) For type 2, theta = rotation_amplitude x sin(2 x pi x rotation_freq x t), where t=nondimensional time |
|---|---|
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 |
Start time (non-dimensional) of rotational motion (B) (Default: 0.0) |
rotation_duration |
Duration (non-dimensional) of rotational motion (B) (Default: 1.0e99) |
translate |
Type of translational motion 0=none, 1=constant translation rate, 2=sinusoidal (B) (Default: 0) For type 2, displacement = translation_amplitude x sin(2 x pi x translation_freq x t), where t=nondimensional time |
translation_rate |
Translation rate (non-dimensional) associated with translate=1 (B) (Default: 0.0) |
translation_freq |
Translation reduced frequency (non-dimensional) associated with translate=2 (B) (Default: 0.0) |
translation_amplitude |
Translation amplitude (grid units) associated with translate=2 (B) (Default: 0.0) |
translation_vector_x |
X-component of unit vector along translation axis (B) (Default: 0.0) |
translation_vector_y |
Y-component of unit vector along translation axis (B) (Default: 1.0) |
translation_vector_z |
Z-component of unit vector along translation axis (B) (Default: 0.0) |
translation_start |
Start time (non-dimensional) of translational motion (B) (Default: 0.0) |
translation_duration |
Duration (non-dimensional) of translational motion (B) (Default: 1.0e99) |
Output Data
In version 10.4 and higher, specified body motion (&forced_motion namelist) will
result in the following output files being generated (below, in filenameBody_N, N
is the body number):
PositionBody_N.hst |
Contains “CG” (rotation center) position and Euler angles (pitch, roll, yaw) as functions of time; default output is non-dimensional; Tecplot format. Note that Euler angles have multiple singularities and are non-unique! |
|---|---|
VelocityBody_N.hst |
Contains linear and angular velocity components of the CG (rotation center) as functions of time; default output is non-dimensional; Tecplot format. |
AeroForceMomentBody_N.hst |
Contains the aerodynamic forces and moments (about the specified moment center) acting on the body as functions of time; default output is non-dimensional; Tecplot format. |
Note: these files are created from scratch if irest=0 or irest=-1; any existing
files with these names are overwritten. The files are appended to (if they exist)
when restarting with irest=1. If they have been deleted before restarting with
irest=1 they will be created but the preceding history will be lost.
In addition to the above files, the [project]_hist.tec file contains the x, y, and z components of the specified rotation vector, as well as the position of the rotation origin as functions of time. Except for special cases, the rotation vector components will differ from the Euler angles. Note that the data in this file is for body 1 only, and is also output from versions prior to 10.4.
Specified Observer Motion (for animation)
The following namelist, which is input via the moving_body.input file, is used to specify
the motion of an observer. This optional namelist is only used when
Animating Unsteady Flows that involve moving bodies, and is
not available in versions prior to 10.4. If the observer_motion is specified, then the
resulting animation will be from the observer’s reference frame rather than the (default)
inertial reference frame. This capability may be used for, among other things, assessing
relative motions in complex dynamic motions (e.g. insuring that the cyclic pitch in a rotor
simulation is correctly enforced). The data to specify observer motion is analogous
to specifying body motion; the observer motion is applied on a global basis (G).
&observer_motion namelist
ob_parent_name |
Parent reference frame for observer (G) (Default: ’’ [indicates inertial ref. frame] |
|---|---|
ob_rotate |
Type of rotational motion 0=none, 1=constant rotation rate, 2=sinusoidal (G) (Default: 0) |
ob_rotation_rate |
Rotation rate (non-dimensional) associated with rotate=1 (G) (Default: 0.0) |
ob_rotation_freq |
Rotation reduced frequency (non-dimensional) associated with rotate=2 (G) (Default: 0.0) |
ob_rotation_amplitude |
Rotation amplitude (degrees) associated with rotate=2 (G) (Default: 0.0) |
ob_rotation_origin_x |
X-coordinate of rotation center (G) (Default: 0.0) |
ob_rotation_origin_y |
Y-coordinate of rotation center (G) (Default: 0.0) |
ob_rotation_origin_z |
Z-coordinate of rotation center (G) (Default: 0.0) |
ob_rotation_vector_x |
X-component of unit vector along rotation axis (G) (Default: 0.0) |
ob_rotation_vector_y |
Y-component of unit vector along rotation axis (G) (Default: 1.0) |
ob_rotation_vector_z |
Z-component of unit vector along rotation axis (G) (Default: 0.0) |
ob_translate |
Type of translational motion 0=none, 1=constant translation rate, 2=sinusoidal (G) (Default: 0) |
ob_translation_rate |
Translation rate (non-dimensional) associated with translate=1 (G) (Default: 0.0) |
ob_translation_freq |
Translation reduced frequency (non-dimensional) associated with translate=2 (G) (Default: 0.0) |
ob_translation_amplitude |
Translation amplitude (grid units) associated with translate=2 (G) (Default: 0.0) |
ob_translation_vector_x |
X-component of unit vector along translation axis (G) (Default: 0.0) |
ob_translation_vector_y |
Y-component of unit vector along translation axis (G) (Default: 1.0) |
ob_translation_vector_z |
Z-component of unit vector along translation axis (G) (Default: 0.0) |
If it is desired to have the observer in the frame of a moving body whose motion is specified, or results from 6DOF motion, then all that is needed is to set ob_parent_name equal to the name of that body (in quotes), without any further &observer_motion data. There may be cases in which there is no body with the desired motion, in which case the &observer_motion parameters above can be used to specify the motion relative to the ob_parent_name reference system. Note: a body whose motion is specified via file input, or whose motion is the result of aeroelastic motion, cannot be used as the ob_parent_name.
Body Motion via File Input
NOTE: this option requires that Mesh Deformation be used for grid movement.
If the surface_motion_from_file namelist is specifed in the moving_body.input file, then the solver will attempt to read in
the specified number of files for the body:
&surface_motion_from_file namelist
n_time_slices |
Number of files defining motion of the body (B) (Default: 0) |
|---|---|
repeat_time |
Non-dimensional time at which motion in files will repeat (B) (Default: 1.e99) |
The names of the file(s) containing the surface data as a function of time MUST adhere to the naming convention given below. The points defining the surface(s) in the file(s) must correspond to the surface(s) defined in the &body_definitions namelist. Generally speaking, the time span covered by these files should either encompass the time span of the current run, or the period of motion if the body motion is cyclic. The exception to this is for static aeroelastic cases, where the flow solver is only periodically coupled to a structural solver; in this case only one surface file is read in (for any one body) at the start of a run, and the TIME data is ignored (and in fact is not required).
The time values given in the files need not correspond to increments of time as specified by the parameter
time_step_nondim in fun3d.nml (DT in the ginput.faces in release 10.4.1 and before)
(though it is probably best to do so). For example, if DT=1.0, then as the code executes, the
non-dimensional time runs as 0.0, 1.0, 2.0, 3.0…
The times specified at the top of the surface files (see below) might be 0.0, 2.5, 5.0, 7.5… In this case the positions
defined in the files are linearly interpolated in time to the current solver time.
Surface File Naming Convention:
{project}.bodyN_timestepM
where:
N is the body number, 1…Number of Moving Bodies
M is the file number, 1…Number of Surface Files Defining Boundary Motion
File Format:
The surface files are ASCII Tecplot files, in FEPOINT format. A time value must appear in the title line as indicated below. An exception to the requirement of a time value appearing in the title line is if there is only one surface file specified for the current run for the current body; in that case the time value is optional, and is ignored if present. The file must contain the variables X, Y, Z, and ID for each point on the surface, where ID is the GLOBAL node number of the surface point; see below for instructions how to generate a baseline tecplot file containing the required ID information. While the surface file must have X, Y, Z and ID as the first 4 values as shown, additional variables may also be present – they will be ignored.
The following is an example of an input surface file:
TITLE="MyTitle TIME = 0.563380281690E+02"
VARIABLES = "X" "Y" "Z" "ID"
ZONE T = group0, I = 27379 J = 54616, F=FEPOINT
0.749999803300000E+00 0.332401000000000E-02 0.568688647000000E-03 756948
0.749999709200000E+00 0.466716000000000E-02 0.581249831300000E-03 756949
0.749999596400000E+00 0.614341000000000E-02 0.594249581500000E-03 756950
0.749999463300000E+00 0.773828000000000E-02 0.608274493500000E-03 756951
0.749999306600000E+00 0.945972000000000E-02 0.623389823100000E-03 756952
0.749999122200000E+00 0.113178000000000E-01 0.639686203200000E-03 756953
0.749998905500000E+00 0.133233000000000E-01 0.657242011700000E-03 756955
many lines of similar x,y,z,id data deleted
-0.179577227400000E+00 0.126451000000000E+01 -0.150364604100000E+00 872982
-0.180001486000000E+00 0.123791000000000E+01 -0.148198832700000E+00 872983
-0.179293826000000E+00 0.129235000000000E+01 -0.152598086400000E+00 872984
24130 24058 24057 24057
24058 24059 23940 23940
24129 24130 24056 24056
337 2573 335 335
23966 23967 23916 23916
24059 24061 24060 24060
24126 24129 24128 24128
many lines of similar face connectivity data deleted
1218 1193 1192 1192
1142 1130 1718 1718
24910 24899 25991 25991
24899 24910 24909 24909
The characters TIME in the title line may be either all upper or all lower case; otherwise, case is unimportant. The actual zone title (ZONE T = title) is unimportant. In the ZONE T line is the number of data points to follow, while J is the number of elements (triangles and/or quads) on the surface.
Since the user specifies the surface motion, the values of X,Y, and Z at different points in time must obviously be known. What the user will not know a priori is the correct value of ID for each node. However, the user may generate a template file for the surface in the original position as it appears in the input grid/part files by first obtaining a static-grid solution (1 steady-state iteration would be sufficient) and then post-process that solution with party to generate a MASSOUD file (TECPLOT option 3, then sub-option 2) containing the initial (t=0) file with the correct ID information. The ID data remains fixed with time even though the X,Y,Z data change, so this MASSOUD file may be used as input into a user-developed program to generate the subsequent surface motion files for the particular case at hand. NOTE: the MASSOUD file generated by party will not follow the required naming convention for moving-body specification and so must be appropriately renamed; also, the title line will not have the requisite time value and must be edited accordingly.
6DOF Motion
Note: Use of the 6DOF capability requires linking to third-party software. The required 6DOF libraries are available from Roy Koomullil at the University of Alabama
Note: all 6DOF input is dimensional, and refers to values at t=0; the values of ref_length, ref_velocity, ref_density from the &body_definitions namelist are used for non-dimensionalization of the input data, so they must be set consistently with the 6DOF input data.
For 6DOF cases, the --grid_motion_only and --body_motion_only are probably not particularly
useful predictors of the subsequent motion, unless the aerodynamic loads (not computed
when either option is invoked) have very little impact on the dynamics.
A (B) after the description indicates the data may be specified for each body; (1-3,B) indicates one or all of 3 (x,y,z) components may be specified for each body. For example body_lin_vel(2,3) would be input to specify an initial y-component of velocity for body 3.
&sixdof_motion namelist
mass |
Mass of the body (B) (Default: 1.0) |
|---|---|
cg_x |
X-coordinate of CG (B) (Default: 0.0) |
cg_y |
Y-coordinate of CG (B) (Default: 0.0) |
cg_z |
Z-coordinate of CG (B) (Default: 0.0) |
i_xx |
Moment of inertia about x axis (B) (Default: 1.0) |
i_yy |
Moment of inertia about y axis (B) (Default: 1.0) |
i_xx |
Moment of inertia about z axis (B) (Default: 1.0) |
i_xy |
Moment of inertia about x-y axis (B) (Default: 0.0) |
i_xz |
Moment of inertia about x-z axis (B) (Default: 0.0) |
i_yz |
Moment of inertia about y-z axis (B) (Default: 0.0) |
body_lin_vel |
Components of linear velocity (1-3,B) (Default: 0.0, 0.0, 0.0) |
body_ang_vel |
Components of angular velocity (1-3,B) (Default: 0.0, 0.0, 0.0) |
euler_ang |
Euler angles (1-3,B) (Default: 0.0, 0.0, 0.0) |
gravity_dir |
Normalized components of the gravity vector (G) (Default: 0.0, 0.0, -1.0) |
gravity_mag |
Magnitude of the gravity vector (G) (Default: 32.2) |
n_extforce |
Number of imposed external forces, excluding gravity (B) (Default: 0) |
n_extmoment |
Number of imposed external moments (B) (Default: 0) |
file_extforce |
File specifying external forces (B) (Default: ’’) |
file_extmoment |
File specifying external moments (B) (Default: ’’) |
Output Data
6DOF body motion (&sixdof_motion namelist) will
result in the following output files being generated (below, in filenameBody_N, N
is the body number):
PositionBody_N.hst |
Contains CG position (as specifed in &sixdof_motion) and Euler
angles (pitch, roll, yaw) as functions of time; default output is non-dimensional;
Tecplot format. Note that Euler angles have multiple singularities and are non-unique! |
|---|---|
VelocityBody_N.hst |
Contains linear and angular velocity components of the CG as functions of time; default output is non-dimensional; Tecplot format. |
AeroForceMomentBody_N.hst |
Contains the aerodynamic forces and moments (about the CG) acting on the body as functions of time; default output is non-dimensional; Tecplot format. Note: the aero forces and moments in the output file are non-dimensionalized in the standard fashion for aerodynamics; this is not the same way they are non-dimensionalized for the 6DOF equations |
ExternalForceMomentBody_N.hst |
Contains any user-specified external forces and moments acting on the body as functions of time; default output is non-dimensional (6DOF non-dimensionalization); Tecplot format. |
Note: these files are created from scratch if irest=0 or irest=-1; any existing
files with these names are overwritten. The files are appended to (if they exist)
when restarting with irest=1. If they have been deleted before restarting with
irest=1 they will be created but the preceding history will be lost.
Aeroelastic Motion (Mode-Based)
NOTE: this option requires that Mesh Deformation be used for grid movement.
Note: the implementation of the modal aeroelastic analysis in FUN3D follows nearly exactly the implementation in CFL3D, so interested parties may find some useful supplemental information on pp 191-223 of the CFL3D Tutorial.
A (G) following a variable description means that this is a global descriptor, i.e. applicable to all aeroelastic bodies; (B) means that the data may be specified for each body; (M,B) means the data may be specified for each mode associated with each body. For example, freq(4,2) would specify the frequency of mode 4 for body 2.
The modal aeroelastic capability is available in Version 10.4 and higher
&aeroelastic_modal_data namelist
nmode |
Number of aeroelastic modes used to represent the structural deformation (B) (Default: 0) |
|---|---|
plot_modes |
Logical flag to generate tecplot files of each mode shape added to the body surface to help insure validity of input modal surface data (G) (Default: .false.) |
single_modal_file |
Logical flag to read all mode shapes from a single file for each body (G) (Default: .false. i.e. each mode in a separate file for each body) |
grefl |
Scale factor between CFD grid units and structural dynamics equation units (B) (Default: 1.0) |
uinf |
Free stream velocity, in structural dynamics equation units (B) (Default: 0.0) |
qinf |
Free stream dynamic pressure, in structural dynamics equation units (B) (Default: 0.0) |
gdispl0 |
Generalized displacement of specified mode at starting time step; used to perturb mode for excitation of dynamic response (Default: 0.0) |
gvel0 |
Generalized velocity of specified mode at starting time step; used to perturb mode for excitation of dynamic response (Default: 0.0) |
gforce0 |
Generalized force of specified mode at starting time step; used to perturb mode for excitation of dynamic response (Default: 0.0) |
gmass |
Generalized mass of specified mode (M,B) (Default: 0.0) |
freq |
Frequency of specified mode, rad/sec (M,B) (Default: 0.0) |
damp |
Damping ratio of specified mode (M,B) (Default: 0.0) |
moddfl |
Type of time-varying perturbation of specified mode: 0, no perturbation; <0, modal displacement and velocity set to 0; 1, harmonic (sinusoidal); 2, Gaussian pulse; 3, Step pulse (M,B) (Default: 0) |
moddfl_amp |
Amplitude of perturbation of specified mode (M,B) (Default: 0.0) |
moddfl_freq |
Frequency of perturbation of specified mode if moddfl=1; half-width of Gaussian pulse if moddfl=2 (M,B) (Default: 0.0) |
moddfl_t0 |
Time about which Gaussian pulse is centered if moddfl=2; start time of step pulse if moddfl=3 (M,B) (Default: 0.0) |
In addition to the &aeroelastic_modal_data namelist, one or more files containing the modal surface definitions must be provided. FUN3D accepts two types of modal files: 1) each mode associated with an aeroelastic body is in a separate file or 2) all modes associated with an aeroelastic body are contained in the same file. The points defining the modal surface(s) in the file(s) must correspond to the surface(s) defined in the &body_definitions namelist.
Modal Surface File Naming Convention:
1) Separate file for each mode:
{project}.bodyN_modeM
2) All modes in one file:
{project}.bodyN_all_modes
where:
N is the body number
M is the mode number
File Format:
The modal surface files are ASCII Tecplot files, in FEPOINT format. The file must contain the variables X, Y, Z and ID as the first four variables, where X, Y, Z define the baseline surface and ID is the GLOBAL node number. For the single-mode-per-file format, these are followed by the modal coordinates XMD, YMD, ZMD; for the all-modes-in-one-file format, XMD1, YMD1, ZMD1, XMD2, YMD2, ZMD2, etc, follow.
The following is an example of a modal surface file (containing a single mode):
title="Mode 1"
variables = "x" "y" "z" "id" "xmd" "ymd" "zmd"
zone t = mode1, i = 176, j = 88,f=fepoint
0.160000000000E+02 0.000000000000E+00 0.000000000000E+00 9377 0.000000000000E+00 0.000000000000E+00 0.408356833737E+00
0.160000000000E+02 -0.640000000000E+02 0.000000000000E+00 9442 0.000000000000E+00 0.000000000000E+00 0.408356833737E+00
0.158624877930E+02 0.000000000000E+00 -0.195790082224E-01 9571 0.000000000000E+00 0.000000000000E+00 0.408374846989E+00
0.158624877930E+02 0.000000000000E+00 0.195790082224E-01 9572 0.000000000000E+00 0.000000000000E+00 0.408374846989E+00
0.158624877930E+02 -0.640000000000E+02 -0.195790082224E-01 9639 0.000000000000E+00 0.000000000000E+00 0.408374846989E+00
0.158624877930E+02 -0.640000000000E+02 0.195790082224E-01 9640 0.000000000000E+00 0.000000000000E+00 0.408374846989E+00
0.156976051331E+02 0.000000000000E+00 -0.427785292272E-01 9769 0.000000000000E+00 0.000000000000E+00 0.408396445602E+00
many lines of similar x,y,z,id,xmd,ymd,zmd data deleted
0.368598237408E-03 -0.640000000000E+02 0.139784077182E-01 19630 0.000000000000E+00 0.000000000000E+00 0.410452686861E+00
0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 19759 0.000000000000E+00 0.000000000000E+00 0.410452735145E+00
0.000000000000E+00 -0.640000000000E+02 0.000000000000E+00 19824 0.000000000000E+00 0.000000000000E+00 0.410452735145E+00
1 2 5 3
3 5 9 7
7 9 13 11
11 13 17 15
15 17 21 19
19 21 25 23
23 25 29 27
many lines of similar face connectivity data deleted
16 18 14 12
12 14 10 8
8 10 6 4
4 6 2 1
The starting point for generating a modal shape file as shown above is to first obtain a static-grid solution (1 steady state iteration would be sufficient) and then post-process that solution with party to generate a MASSOUD file (TECPLOT option 3, then sub-option 2) containing the baseline file with the correct X, Y, Z and ID information. This baseline file can then be used as input into a user-developed program to add the appropriate XMD, YMD, ZMD data for the case at hand (the X,Y,Z,ID data remain unchanged). NOTE: the MASSOUD file generated by party will not follow the required naming convention for modal file specification and so must be appropriately renamed.
Output Data
Aeroelastic body motion (&aeroelastic_modal_data namelist) will
result in the following output files being generated (below, in filename_bodyN_modeM, N
is the body number and M is the mode number):
aehist_bodyN_modeM.tec |
Contains the generalized displacement, generalized velocity, and generalized force for mode M of body N as functions of time; the output is non-dimensional;. Tecplot format. |
|---|
In addition, if the plot_modes variable is set to .true. in the &aeroelastic_modal_data
namelist, then the following files are also output:
aesurf_bodyN_modeM.tec |
Contains the x, y, z coordinates of a surface created by adding the baseline (rigid) shape of body N to the input modal shape of mode M, read from the {project}.bodyN_modeM or {project}.bodyN_all_modes files. As such it is a tool for assessing if the modal shapes have been specified and read correctly. Tecplot format. |
|---|
Sample moving_body.input Files
The first example constitutes a simple pitching airfoil, in which the mesh surrounding the airfoil moves rigidly with the airfoil. This example illustrates a shortcut: to indicate a body is made up of all solid surfaces in the mesh, without having to list each boundary surface, set n_defining_bndry = -1, and then use any integer number (0 is fine) for defining_bndry. Note that this shortcut is only applicable for n_moving_bodies = 1:
(Animation requires Flash Player‘g to view)
&body_definitions n_moving_bodies = 1, ! number of bodies in motion body_name(1) = 'airfoil', ! name must be in quotes parent_name(1) = '', ! '' means motion relative to inertial ref frame n_defining_bndry(1) = -1, ! shortcut to specify all solid surfaces defining_bndry(1,1) = 0, ! index 1: boundary number 2: body number; use any number for shortcut motion_driver(1) = 'forced', ! 'forced', '6dof', 'file', 'aeroelastic' mesh_movement(1) = 'rigid', ! 'rigid', 'deform' x_mc(1) = 0.25, ! x-coordinate of moment_center y_mc(1) = 0.0, ! y-coordinate of moment_center z_mc(1) = 0.0, ! z-coordinate of moment_center move_mc(1) = 1 ! move mom. cntr with body/grid: 0=no, 1=yes / &forced_motion rotate(1) = 2, ! rotation type: 1=constant rate 2=sinusoidal rotation_rate(1) = 0.0, ! rate of rotation rotation_freq(1) = 0.015489, ! reduced rotation frequency rotation_amplitude(1) = 4.59, ! max rotational displacement rotation_origin_x(1) = 0.25, ! x-coordinate of rotation origin rotation_origin_y(1) = 0.0, ! y-coordinate of rotation origin rotation_origin_z(1) = 0.0, ! z-coordinate of rotation origin rotation_vector_x(1) = 0.0, ! unit vector x-component along rotation axis rotation_vector_y(1) = 1.0, ! unit vector y-component along rotation axis rotation_vector_z(1) = 0.0, ! unit vector z-component along rotation axis /
The second example is for a wing with a flap. The wing (‘main’) is constituted from boundary 1 in the mesh, while the flap (‘flap’) is constituted from boundary 2 in the mesh. The wing undergoes a plunging motion in the z-direction, while the flap undergoes a pitching motion about an axis parallel to its’ leading edge. The flap is identified as a child of the wing, so that the complete motion of the flap consists of the inherited wing plunging motion plus the flap pitching motion. This 2-body motion cannot be accommodated with rigid mesh motion (unless overset, not considered here), so mesh_movement is chosen as ‘deform’:
(Animation requires Flash Player‘g to view)
&body_definitions n_moving_bodies = 2, ! number of bodies in motion body_name(1) = 'main', ! name must be in quotes body_name(2) = 'flap', ! name must be in quotes parent_name(1) = '', ! '' means motion relative to inertial ref frame parent_name(2) = 'main', ! '' means motion relative to inertial ref frame n_defining_bndry(1) = 1, ! number of boundaries that define this body n_defining_bndry(2) = 1, ! number of boundaries that define this body defining_bndry(1,1) = 1, ! index 1: boundary number index 2: body number defining_bndry(1,2) = 2, ! index 1: boundary number index 2: body number motion_driver(1) = 'forced', ! 'forced', '6dof', 'file', 'aeroelastic' motion_driver(2) = 'forced', ! 'forced', '6dof', 'file', 'aeroelastic' mesh_movement(1) = 'deform', ! 'rigid', 'deform' mesh_movement(2) = 'deform', ! 'rigid', 'deform' x_mc(1) = 0.25, ! x-coordinate of moment_center x_mc(2) = 0.25, ! x-coordinate of moment_center y_mc(1) = 0.0, ! y-coordinate of moment_center y_mc(2) = 0.0, ! y-coordinate of moment_center z_mc(1) = 0.0, ! z-coordinate of moment_center z_mc(2) = 0.0, ! z-coordinate of moment_center move_mc(1) = 0, ! do not move mom. cntr with body/grid move_mc(2) = 0 ! do not move mom. cntr with body/grid / &forced_motion translate(1) = 2, ! translation type: 1=constant rate 2=sinusoidal rotate(2) = 2, ! rotation type: 1=constant rate 2=sinusoidal translation_freq(1) = 0.03, ! reduced translation frequency rotation_freq(2) = 0.06, ! reduced rotation frequency translation_amplitude(1) = -0.1, ! max translational displacement rotation_amplitude(2) = +5.00, ! max rotational displacement rotation_origin_x(2) = 0.7798, ! x-coordinate of rotation origin rotation_origin_y(2) = 0.0, ! y-coordinate of rotation origin rotation_origin_z(2) = 0.0, ! z-coordinate of rotation origin translation_vector_x(1) = 0.0, ! unit vector x-component along translation axis rotation_vector_x(2) = 0.0885398,! unit vector x-component along rotation axis translation_vector_y(1) = 0.0, ! unit vector y-component along translation axis rotation_vector_y(2) = 0.996073, ! unit vector y-component along rotation axis translation_vector_z(1) = 1.0, ! unit vector z-component along translation axis rotation_vector_z(2) = 0.0, ! unit vector z-component along rotation axis /
The next example consists of a grid with two solid boundaries (boundaries number 2 and 3 in the mapbc file) representing two blades of a rotor. These two surfaces are grouped for the purpose of motion specification into 5 moving “bodies”: 1) ‘hub’ contains both blades and the surrounding mesh undergoes rigid mesh rotation at the angular speed of the rotor system; 2) ‘flap1’ is the first blade, and the surrounding mesh undergoes mesh deformation to accommodate a sinusoidal flapping motion about the blade root; 3) ‘blade1’ is used to specify a sinusoidal pitching motion about a spanwise axis of the first blade; 4) ‘flap2’ and; 5) ‘blade2’ specify the corresponding motions of the second blade. Thus the complete 5-body system defines a 2-bladed rotor undergoing a general rotation about a common axis, with simultaneous flapping and pitching of each blade. The rotation, flap, and pitch axes are all distinct. Each blade undergoes one flap and one pitch cycle for every rotation of the complete system. The flap and pitch amplitudes are both +/- 10 degrees.
(Animation requires Flash Player‘g to view)
&body_definitions n_moving_bodies = 5, ! number of bodies in motion body_name(1) = 'hub', ! name must be in quotes body_name(2) = 'flap1' body_name(3) = 'blade1', body_name(4) = 'flap2' body_name(5) = 'blade2', parent_name(1) = '', ! '' means motion relative to inertial ref frame parent_name(2) = 'hub' parent_name(3) = 'flap1', parent_name(4) = 'hub' parent_name(5) = 'flap2', n_defining_bndry(1) = 2, ! number of boundaries that define this body n_defining_bndry(2) = 1, n_defining_bndry(3) = 1, n_defining_bndry(4) = 1, n_defining_bndry(5) = 1, defining_bndry(1,1) = 2, ! index 1: boundary number index 2: body number defining_bndry(2,1) = 3, defining_bndry(1,2) = 2, defining_bndry(1,3) = 2, defining_bndry(1,4) = 3, defining_bndry(1,5) = 3, motion_driver(1) = 'forced', ! options: 'forced', '6dof', 'file', 'aeroelastic' motion_driver(2) = 'forced', motion_driver(3) = 'forced', motion_driver(4) = 'forced', motion_driver(5) = 'forced', mesh_movement(1) = 'rigid', ! options: 'rigid', 'deform' mesh_movement(2) = 'deform', mesh_movement(3) = 'deform', mesh_movement(4) = 'deform', mesh_movement(5) = 'deform', / &forced_motion rotate(1) = 1, ! rotation type: 1=constant rate 2=sinusoidal rotate(2) = 2, rotate(3) = 2, rotate(4) = 2, rotate(5) = 2, rotation_rate(1) = -0.011712921516, rotation_freq(2) = 0.00186416935695, ! reduced rotation frequency rotation_freq(3) = 0.00186416935695, rotation_freq(4) = 0.00186416935695, rotation_freq(5) = 0.00186416935695, rotation_amplitude(2) = +10.00, ! flap blade 1 rotation_amplitude(3) = +10.00, ! pitch blade 1 rotation_amplitude(4) = +10.00, ! flap blade 2 rotation_amplitude(5) = +10.00, ! pitch blade 2 rotation_origin_x(1) = 0.0, ! x-coordinate of rotation origin rotation_origin_y(1) = 0.0, ! y-coordinate of rotation origin rotation_origin_z(1) = 0.0, ! z-coordinate of rotation origin rotation_origin_x(2) = -1.875, rotation_origin_y(2) = +6.75, rotation_origin_z(2) = 0.0589, rotation_origin_x(3) = -1.875, rotation_origin_y(3) = +6.75, rotation_origin_z(3) = 0.0589, rotation_origin_x(4) = +1.875, rotation_origin_y(4) = -6.75, rotation_origin_z(4) = 0.0589, rotation_origin_x(5) = +1.875, rotation_origin_y(5) = -6.75, rotation_origin_z(5) = 0.0589, rotation_vector_x(1) = 0.0, ! unit vector x-component along rotation axis rotation_vector_y(1) = 0.0, ! unit vector y-component along rotation axis rotation_vector_z(1) = 1.0, ! unit vector z-component along rotation axis rotation_vector_x(2) = 1.0, rotation_vector_y(2) = 0.0, rotation_vector_z(2) = 0.0, rotation_vector_x(3) = 0.0, rotation_vector_y(3) = 1.0, rotation_vector_z(3) = 0.0, rotation_vector_x(4) = -1.0, rotation_vector_y(4) = 0.0, rotation_vector_z(4) = 0.0, rotation_vector_x(5) = 0.0, rotation_vector_y(5) = 1.0, rotation_vector_z(5) = 0.0, /
The next example consists of a wing (comprised of boundaries 7-16 in the mapbc file) in which the surface motion is specified via a series of 73 files, each representing an instant of (non-dimensional) time between t=0 and t=1. The surface motion given by the files is repeated after the repeat_time of 1.0. Details describing the format for the surface motion files, as well as an example of such a file may be found in the section Body Motion via File Input
&body_definitions n_moving_bodies = 1, ! number of bodies in motion body_name(1) = 'wing', ! name must be in quotes parent_name(1) = '', ! '' means motion relative to inertial ref frame n_defining_bndry(1) = 10, ! number of boundaries that define this body defining_bndry(1,1) = 7, ! index 1: boundary number index 2: body number defining_bndry(2,1) = 8, ! index 1: boundary number index 2: body number defining_bndry(3,1) = 9, ! index 1: boundary number index 2: body number defining_bndry(4,1) = 10, ! index 1: boundary number index 2: body number defining_bndry(5,1) = 11, ! index 1: boundary number index 2: body number defining_bndry(6,1) = 12, ! index 1: boundary number index 2: body number defining_bndry(7,1) = 13, ! index 1: boundary number index 2: body number defining_bndry(8,1) = 14, ! index 1: boundary number index 2: body number defining_bndry(9,1) = 15, ! index 1: boundary number index 2: body number defining_bndry(10,1) = 16, ! index 1: boundary number index 2: body number motion_driver(1) = 'file', ! 'forced', '6dof', 'file', 'aeroelastic' mesh_movement(1) = 'deform', ! 'rigid', 'deform' move_mc(1) = 0, ! do not move mom. cntr with body/grid / &surface_motion_from_file n_time_slices(1) = 73, ! number of files defining motion for this body repeat_time(1) = 1.0 ! time at which motion in files will repeat /
Mesh Deformation
Mesh deformation is invoked from within the flow solver (as opposed to the stand-alone
mesh deformation code used in the design process) when running in time accurate node (itime > 0) with
the commandline option --moving_grid and the mesh_movement variable for one or more bodies
defined in the moving_body.input file is set to 'deform'. Mesh deformation is also invoked
from within the flow solver if running in steady-state mode (itime=0) and the commandline
option --read_surface_from_file is specified, as would be the case for static aeroelastic
computations (see Aeroelastic Coupling for more information).
An additional commandline option that is sometimes useful for problem mesh deformation cases is:
--elasticity INT
where INT signifies the variable used to set the modulus of elasticity: 1 (E=1/s [default],
where s is the distance function used in the turbulence models) or
2 (E=1/vol). Generally speaking, the default is preferred, as the resulting system of equations
tends to require fewer iterations to converge to a reasonable tolerance. However, if there are
some small sliver cells located out in the field away from the body, and the default results in
negative volumes, --elasticity 2 may help. Note that for inviscid cases (more precisely,
if all wall bcs are inviscid), the distance function s is not computed,
and thus is not an appropriate choice. In version 10.4 and above, the flow solver
checks to see if s if available, and if not, uses the volume instead.
To solve the elasticity PDE that governs mesh deformation, a minimum of one
additional input file is required. The required file is called move_gmres.input,
in which are specified basic parameters for the solution of the elasticity PDE.
Optionally, a file move_relaxation.schedule may be used for further control
of the PDE solution process.
move_gmres.input data
ileft |
Flag for left preconditioning (0=no, 1=yes, Recommended: 1) |
|---|---|
nsearch |
Number of search directions (Recommended: 50, more will require extra CPU time typically without benefit ) |
nrestarts |
Number of restarts (Recommended: 5; more if convergence rate is slow) |
tol |
Convergence tolerance (Recommended: 10e-5 or smaller) |
A note on tol: grids with tight spacing in the wake, as are typically found on structured “C-grid” meshes (but typically NOT found in unstructured meshes) will require much smaller values of tol, perhaps 10e-9 or smaller. Reaching the lower tolerances will require significantly more restarts.
Sample move_gmres.input File
ILEFT NSEARCH NRESTARTS TOL
1 +50 5 1.e-06
move_relaxation.schedule data (optional)
This file is analogous to the optional relaxation.schedule file for the flow solver, except that the relaxation schedule prescribed in the move_relaxation.schedule file govern the solution of the linear system associated with the elasticity PDE rather than the linear system arising from the solution of flow equations. In some cases the relaxation schedule can improve convergence of the mesh deformation.
Number of Pre-Relaxation Schedules to Perform |
Number of Pre-Relaxation Schedules to Perform (Recommended: 0) |
|---|---|
Number of Global Schedules to Perform |
Number of Global Schedules to Perform (Recommended: 1 ) |
Number of Post-Relaxation Schedules to Perform |
Number of Post-Relaxation Schedules to Perform (Recommended: 0) |
Number of Steps |
Number of steps for each of the pre-, global-, and post-relaxation schedules |
Type |
Type of relaxation to perform in the specified step (see example for full description) |
Sample move_relaxation.schedule File
************************** HEFSS Relaxation Schedule ***************************
*
* This file lays out the relaxation schedule for the HEFSS solver in
* terms of pre-relaxations, global relaxations, and post-relaxations
*
* The step types are as follows:
*
* Type 1: Line-implicit relaxation through stretched grid regions
* Type 2: Point-implicit relaxation through entire domain
* Type 3: Point-implicit relaxation through boundary swaths
* Type 4: Point-implicit relaxation through entire domain - line region
* Type 5: Newton-Krylov through entire domain - line region
* Type 6: ILU(0) relaxation through entire domain
* Type 7: Global Newton-Krylov
*
********************************************************************************
Number of Pre-Relaxation Schedules to Perform
0
Number of Global Schedules to Perform
1
Number of Post-Relaxation Schedules to Perform
0
----- Pre-Relaxation Schedule -----
Number of Steps
0
Step Type Sweeps Turb Sweeps
----- Global Relaxation Schedule -----
Number of Steps
2
Step Type Sweeps Turb Sweeps
1 2 5 0
2 7 0 0
----- Post-Relaxation Schedule -----
Number of Steps
0
Step Type Sweeps Turb Sweeps
Moving Grids In Versions 10.0 Through 10.2
THIS SECTION IS APPLICABLE ONLY FOR VERSIONS 10.0 THROUGH 10.2
See Moving Grids for input specification for versions higher than 10.2.
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.
Grid motion is enabled via the command line option --moving_grid
In addition to this command line option, a file called grid_motion.schedule must be present. An example of this file, and a description of the contents of this file are given below.
Sample grid_motion.schedule Deck
************************** FUN3D Grid Motion Schedule **************************
*
* This file lays out the grid motion schedule for time-accurate, moving grid
* cases (top portion is a description; actual input data is at bottom of file;
* comment lines at top must begin with *)
*
* The flow solver will look for this file if the command line argument:
*
* --grid_motion
*
* is specified at run time
*
************************** no comments (*) past this line **********************
Number of Moving Bodies: (max of 1 for rigid mesh movement)
2
Motion Data for Body 1
Body Name:
'wing'
Parent Body Name: (use '' for no parent)
''
No. of Boundaries Defining Body: (-1: body defined as all solid bndrys in mesh)
1
List of Boundaries Defining Body: (if -1 above, input one integer)
3
No. of Surface Files Defining Body Motion:
0
Repeat Time For Motion in Surface Files:
1.e99
Rotational Motion:
rotate
-2
rotation rate (|rotate|=1) or max angular displacement (|rotate|=2)
4.59
rotational reduced frequency (0. for |rotate|=1)
0.015489
rotation origin
xorigin yorigin zorigin
0.25 0.0 0.0
unit vector in direction of rotation axis
tx ty tz
Translational Motion:
translate
0
translation rate (|translate|=1) or max displacement (|translate|=2)
0.10
translational reduced frequency (0. for |translate|=1)
0.03
unit vector in direction of translation axis
sx sy sz
1.0 0.0 0.0
Moment Center:
xmc ymc zmc
1.0 0. 0.
Moment Center Motion:
move_mc
1
Motion Data for Body 2
'flap'
Parent Body Name: (use '' for no parent)
'wing'
No. of Boundaries Defining Body: (-1: body defined as all solid bndrys in mesh)
1
List of Boundaries Defining Body: (if -1 above, input one integer)
1
No. of Surface Files Defining Body Motion:
10
Repeat Time For Motion in Surface Files:
1.e99
Rotational Motion:
rotate
-2
rotation rate (|rotate|=1) or max angular displacement (|rotate|=2)
4.59
rotational reduced frequency (0. for |rotate|=1)
0.015489
rotation origin
xorigin yorigin zorigin
0.25 0.0 0.0
unit vector in direction of rotation axis
tx ty tz
0.0 1.0 0.0
Translational Motion:
translate
0
translation rate (|translate|=1) or max displacement (|translate|=2)
0.10
translational reduced frequency (0. for |translate|=1)
0.03
unit vector in direction of translation axis
sx sy sz
1.0 0.0 0.0
Moment Center:
xmc ymc zmc
1.0 0. 0.
Moment Center Motion:
move_mc
1
Comment Lines
Comment lines may appear only at the beginning of the file; comment lines must begin with an asterisk (*);
there is no limit to the number of comment lines.
Note that after the comment section, where each line begins with *, there are other text lines. These text lines
must be present in the file, but the exact text is unimportant – they are there for organization and readability
Values with an (Int) denote integer input, (Real) denotes real input and (Char) denotes character input (in single quotes).
Number of Moving Bodies (Int)
Depending on the method of grid motion, one or more bodies may be defined for the grid system. If the mesh is moved as a rigid body (no deformation or overset grids), then there can only be one body.
Motion Data for Body ….
This begins the section where motion data for each body is specified. In the case of rigid mesh motion, this also governs the movement of the mesh as well as the body.
Body Name (Char)
A user specified name is assigned to the current body. The name must appear in single quotes.
Parent Body Name (Char)
A hierarchical structure may be specified if there is more than one body. For example, a wing system may consist of a main section and a flap. If the wing moves, the flap moves as well, but in addition the flap may have its own, independent motion. In this case the flap’s parent is the wing. The wing has no parent. Bodies without parents should have ’’ (two single quotes, one after the other) specified as the parent name.
No. of Boundaries Defining the Body (Int)
Bodies are defined by one or more mesh boundaries; this input line defines how many boundaries will be used to define the current body. For cases in which all solid surfaces are used to define the (single) body, a shortcut is achieved by setting the number of defining boundaries to -1.
List of Boundaries Defining the Body (Int)
A list (one per line) of the boundary numbers that define the body. NOTE: be sure to check the [project].part_info file generated by party to verify the boundary numbers that the flow solver will see; this is especially important if the boundary lumping option is chosen in party, as the boundary numbers will be different than those in the user-specified [project].mapbc file. Use the boundary numbers from the “Global Grid Info” section at the top of the [project].part_info file rather than those in the [project].mapbc file if lumping is used. If the number of defining bodies was set to -1 (indicating all solid boundaries in the mesh), then input only one line here, with any integer number on that line; it serves as a place holder only. [An exception to the specification of a body by boundaries can occur if the body position is read in from a file as described below; in that case the surface definition in the file which is read in overrides any boundaries specified in this grid_motion.schedule file. In such cases it is easiest just to specify -1 as the number of defining boundaries in the preceding section, with a single arbitrary integer number in this section]
No. of Surface Files Defining Boundary Motion (Int)
NOTE: this is a fairly complex feature; some experience should be gained with simpler cases in which the flow solver handles all body movement before attempting cases where the motion is governed by data files that are read in.
If the current body definition is to be specified by reading from user-supplied files, then this line specifies the number of those files to read. Each file should correspond to a different non-dimensional time value. If the body definitions come from the “No. of Boundaries Defining the Body” and “List of Boundaries Defining the Body” sections above, then input 0 (zero) on this line. Specifying the body surface from a file rather than via boundaries as above can be useful in instances where the needed body motion as a function of time is not covered by the built-in movement schemes described below. An example would be an aeroelastic case, where the shape at any given instant of time depends upon the air loads.
NOTE: this option is only valid for deforming meshes; if rigid mesh motion is chosen below, input 0 (zero) on this line.
If the number of files defining the boundary motion is greater than zero, then that number of files will be read in for the current body during the current run. See Body Motion via File Input for more information.
Repeat Time For Motion in Surface Files (Real)
If the body motion read in via the surface files described above is cyclic, this value is the non-dimensional period. If the motion is not periodic, or the motion is not specified via files, input a large value, such as 1.e99
Rotational Motion
rotate (Int)
For the standard case where the flow solver drives the body and grid motion, this parameter dictates how the body and grid are rotated:
| 0 | no rotation |
| 1 | entire grid rotated at a constant rate (rigid grid) |
| 2 | entire grid rotated sinusoidally (rigid grid) |
| -1 | body rotated at a constant rate; grid is deformed to accommodate the new body position |
| -2 | body rotated sinusoidally; grid is deformed to accommodate the new body position |
rotation rate (Real)
this is the non-dimensional constant rotation rate if abs(rotate) = 1
this is the amplitude (degrees) of the sinusoidal rotation if abs(rotate) = 2
rotational reduced frequency (Real)
non-dimensional (reduced) frequency for sinusoidal rotation, abs(rotate) = 2. If abs(rotate) = 1 set to zero
rotation origin
xorigin yorigin zorigin (Real)
x,y,z grid coordinates of rotation center
unit vector in direction of rotation axis
tx ty tz (Real)
x,y,z components of the unit vector pointing in the direction of the rotation axis (use 1 0 0 if rotate = 0)
Translational Motion
translate (Int)
For the standard case where the flow solver drives the body and grid motion, this parameter dictates how the body and grid are translated:
| 0 | no translation |
| 1 | entire grid translated at a constant rate (rigid grid) |
| 2 | entire grid translated sinusoidally (rigid grid) |
| -1 | body translated at a constant rate; grid is deformed to accommodate the new body position |
| -2 | body translated sinusoidally; grid is deformed to accommodate the new body position |
translation rate (Real)
this is the non-dimensional constant translation rate if abs(translate) = 1
this is the amplitude (degrees) of the sinusoidal translation if abs(translate) = 2
translational reduced frequency (Real)
non-dimensional (reduced) frequency for sinusoidal translation, abs(translate) = 2. If abs(translate) = 1 set to zero
unit vector in direction of translation
sx sy sz (Real)
x,y,z components of the unit vector pointing in the direction of the translation axis (use 1 0 0 if translate = 0)
Moment Center
xmc ymc zmc (Real)
x,y,z grid coordinates of the moment center of the current body
Moment Center Motion
move_mc (Int)
flag to move (0…no, 1…yes) the moment center of the current body
NOTE: Currently, only one moment center is tracked by the code, so this flag really only makes sense if there is only one body.
6.8. Overset Grids
This section describes the capability to utilize overset meshes within FUN3D. Unlike structured grids, there is no compelling reason to use overset unstructured meshes unless the analysis involves moving bodies. For general information on moving bodies, see Moving Grids
NOTE: this is an active area of development, so implementation or input details may change with time.
| Overset Grids – Overview |
| Static Grid Simulations |
| Dynamic Grid Simulations |
Overset Grids – Overview
To use overset grids, the third-party libraries SUGGAR and DiRTlib are required. See Chapter 2 of this manual for more information on where to obtain these libraries, which make targets should be compiled, and special soft-links that must be made for FUN3D to utilize these libraries.
For overset grid applications, FUN3D Version 10.5 or higher is recommended; all information below is geared toward Version 10.5 and higher. This is an evolving capability, so usually it is best to have the latest release. When configuring the FUN3D suite for overset-grid applications, be sure to use the following:
--with-dirtlib=/path/to/dirtlib --with-suggar=/path/to/suggar
where /path/to/dirtlib(suggar) is the path to your DiRTlib and SUGGAR executables. Note that if FUN3D is to be run in parallel, DiRTlib must also be configured for parallel execution, built against the same version of MPICH.
The process for using overset grids in FUN3D is to first create a composite mesh by
running SUGGAR as a stand-alone process. It is beyond the scope of this web page to
act as a detailed guide to the usage of SUGGAR. Ralph Noack provides documentation
with the SUGGAR distribution along these lines. However, the general idea is to generate
two or more independent grids about individual bodies in a multibody system (e.g. a grid
for a wing and a grid for a store in a store-separation problem, or a grid for a rotor
blade and a grid for the fuselage in a rotorcraft problem). In the discussion that follows,
these independent grids are referred to as component grids. The commands to position these
component grids relative to one another, commands to affect hole cutting, etc, are set
in the XML input file (typically called Input.xml) that SUGGAR reads. When executed with
the XML commands, SUGGAR will perform the composite assembly of the component grids, and
will (with the appropriate XML command) dump out a composite mesh. As of this
time, the only ustructured composite mesh format that SUGGAR can dump out that is also
compatible with FUN3D is the VGRID tetrahedral format. Thus, the SUGGAR XML file that
creates the initial composite mesh for FUN3D use must have:
<output> <unstructured_grid style="unsorted_vgrid_set" filename="project"> </unstructured_grid> </output>
where project is a name of the user’s choice, and will become the name of the output
composite VGRID set (e.g., project.cogsg, project.iface, project.mapbc, project.bc).
It is this composite VGRID set that is processed by the PARTY preprocessor and utilized
by FUN3D, rather than the individual component grids.
In principle, one of the other file formats that SUGGAR reads besides VGRID could
be used for the input component grids and then a VGRID composite grid could be
output using the XML syntax shown above. To date, FUN3D developers have only utilized
input component grids in VGRID format. When using VGRID input component grids,
the boundary conditions specified in the .mapbc files are set as usual, except for
grids whose outer boundary in the composite mesh will need to be interpolated
from another component mesh.
Typically, in VGRID parlance, these outer boundaries are labled “box” and usually
have a characterisic boundary condition (type 3). For overset cases, such boundaries
should be assigned a boundary condition type -1 to inform SUGGAR that it must compute
interpolation coefficients for these boundary points. Note that the component mesh that
serves as the “background” mesh should have its outer boundary conditions unchanged (e.g. type 3).
After SUGGAR has been run, the .mapbc file for the resulting composite mesh will also have
boundary condition type -1 for the interpolated boundaries. It is possible to not set the
the boundary condition type to -1 for the interpolated outer boundaries in the component-grid
.mapbc file(s), and instead use SUGGAR XML commands to specify those boundaries as overset.
However this is not the reccommended procedure, since then the corresponding boundaries
in the composite-grid .mapbc file do not get marked as -1, and there is no “paper trail” on
the FUN3D side that these boundaries are overset.
Once SUGGAR is successfully executed it will generate a [project_name].dci file. This file
will later be read in by FUN3D. Likewise, the sucecessful execution of SUGGAR wil create
the composite VGRID set ([project_name].cogsg, [project_name].iface, [project_name].bc,
and [project_name].mapbc). This VGRID set must now be processed with PARTY in the usual way,
with the exception that the following command-line option MUST be used:
--overset
NOTE: this same command-line option must be used when posprocessing with PARTY (in addition
to --moving_grid if the case is a moving grid overset case). When PARTY offers the option
to group boundaries, you will probably want to group boundaries by VGRID Family Type in order
to simplify the amount of input required when Defining Moving Bodies
for dynamic-grid applications. The boundaries that were assigned bc type -1 will appear with the
name “overset_interp” in the [project].part_info file written by PARTY.
NOTE: the PPARTY code cannot be used to process overset meshes.
Static Grid Simulations
Static, overset grid simulations may be desired in order to provide a steady-state starting point for subsequent dynamic grid simulations. Once SUGGAR has been successfully run and the resulting composite mesh partitioned with PARTY, FUN3D is run with the command-line option
--overset
This will read in the [project].dci file, and use the data therein to provide communication
of the flow solution between the various components of the composite overset mesh.
Dynamic Grid Simulations
This section only addresses the additional input needed for the utilization of overset grids in moving-grid applications; see Moving Grids for much additional information covering other required input.
For moving grids, a new dci file is required for each time step. The new dci files may either be created “on the fly” as FUN3D is run, or read in if they already exist. Most moving-body problems involve periodic motion, so the usual practice is to compute the required dci files “on the fly” during the first period of motion, and read the dci files computed during the first period for subsequent periods of motion. It requires much more time to compute the connectivity data than to read it, so this strategy should be used whenever appropriate. Certain types of motion are not periodic and cannot benefit from this strategy – 6 DOF simulations are one example.
To compute the conectivity information on the fly, use the following command line when running FUN3D:
--dci_on_the_fly
When this command line is used, the code will compute and use the connectivity data for the current time step, and will also write out the data for the current time step N to the file
[project]N.dci
At the current time the code will overwrite an existing [project]N.dci file.
If the --dci_on_the_fly command-line option is not used, FUN3D will assume the required
[project]N.dci files are available and will attempt to read them as needed.
For cases with periodic motion, first run enough time steps with the comand-line option
--dci_on_the_fly to create a sufficient number of dci files to
cover the entire period. Say the number of time steps per period is NP. Subsequent runs
should then be run with the command-line option
--dci_period NP
Once all the dci files have been created for period motion and the --dci_period NP is used,
subsequent runs can be made with an aribtrary number of time steps – not nescessariy NP
steps per run.
When restarting, the flow solver will keep track of the last dci file computed or read during the last time step of the previous run, and will use this to determine the next dci file that needs to be created or read. No special commands or flags are needed to restart an overset mesh case.
IMPORTANT: For computing connectivity data “on-the-fly”, the current paradigm in FUN3D is
to have SUGGAR running as a concurrent process – currently a single, concurrent process. As a
result, when the --dci_on_the_fly command-line option is used, the number of processors
assigned to an MPI run must be 1 (one) greater than the number of partitions. For example, if
the composite mesh has been partitioned into 64 parts, a total of 65 processors are required;
e.g. mpirun -np 65 nodet_mpi --dci_on_the_fly --overset. In the machinefile list, the
FIRST processor will be assigned to SUGGAR. Furthermore, since the SUGGAR process
requires that the entire mesh fit in core, the first processor in the machinefile list must
have sufficent memory to contain the complete mesh. As an improved, parallel version of
SUGGAR (“SUGGAR++”, currently under development) becomes available, this restriction on one
memory-laden processor will be removed.
NOTE: When the --dci_on_the_fly command-line option is NOT used, such as when continuing
a periodic simulation after all connectivity files have been created, then the number of
processors must be set back to be identical to the number of grid partitions.
&composite_overset_mesh namelist
This namelist is input via the moving_body.input file – see Moving Grids
for additional namelist input required for dynamic mesh simulations. Note that for versions
10.8 and higher, the &composite_overset_mesh namelist is greatly simplified and requires
only the name of the xml file used previously for the static overset assembly.
input_xml_file |
File containing XML commands for SUGGAR; specify the same Input.xml file as was used to
generate the initial composite grid with the “stand-alone” SUGGAR code |
|---|
FUN3D Version 10.7 and lower:
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. Note: although there are defaults set for all namelist items, virtually all defaults must be overwritten with user-supplied data.
n_component_grids |
Number of component grids in the composite mesh (G) (Default: 0) |
|---|---|
ref_vgrid_set |
Name of the component VGRID set for the body; must be same as the corresponding
filename of the vgrid_set in the SUGGAR Input.xml file used to create the
composite mesh (B) (Default: ’’) |
ref_vol_name |
(Version 10.7) Name of the volume grid for the body; must be the same
as the name of the volume_grid in the SUGGAR Input.xml file used to create the
composite mesh (B) (Default: ’’) |
ref_body_name |
(Version 10.7) Name of the body; must be the same
as the name of the body in the SUGGAR Input.xml file used to create the
composite mesh; this same body name should be used in the &body_definitions
namelist (B) (Default: ’’) |
associated_body |
Body number to associate with this component mesh (B) (Default: 0) (note: the non-moving background grid must be associated with body 0) |
input_xml_file |
(Version 10.7; in older versions: manual_hole_commands)
File containing XML commands for SUGGAR; typically used to “tweak” hole cutting beyond
SUGGAR’s default settings(G) (Default: ’’) NOTE: in version 10.7 an higher, one may use
the same Input.xml file as was used to generate the initial composite grid with the
“stand-alone” SUGGAR code; in prior
versions of FUN3D the manual_hole_commands file was related to, but not syntactically
the same as, a SUGGAR Input.xml file |
6.9. Static Aeroelastic Coupling
This section describes how coupling between the FUN3D flow solver and an external structural model may be achieved. Typically, this capability would be used to incorporate the effects of static structural deflections in an aerodynamic analysis. In principle the coupling could also be performed in time accurate mode, allowing for dynamic structural interactions, but this is probably not practical. For dynamic aeroelastic simulations, the modal approach is usually preferred.
Loads Output
Aerothermodynamic loads may be output from the flow solver by using the command line
--write_aero_loads_to_file.
This will create a file called [project]_ddfdrive.tec.timestepN,
where N is the number of timesteps completed (including restarts).
In steady state mode, this file will be written at the end of the current run.
In time accurate mode, a file will be written every time step.
(This can be varied by changing the default value of structural_coupling_freq
in the aeroelastic_module from 1 to the desired value and recompiling).
The ddfdrive.tec file is a formatted Tecplot file containing the following
variables in the “fepoint” format:
incomp = 0 or 1):
variables="x","y","z","id","cp","cfx","cfy","cfz","temp","dtdn"In the generic gas path (
incomp = 2):
variables="x","y","z","id","cp","cfx","cfy","cfz","temp","heat_flux"where
x, y, z are the coordinates of each point on the aeroelastic surface;
id is the node number for each point in the global
(as opposed to partition) numbering system;
cp is the pressure coefficient;
cfx, cfy, and cfz are the components
of the local shear stress coefficient vector;
temp is the wall temperature;
dtdn is the wall temperature gradient
(for the generic gas path, heat_flux is the local normal heat flux coefficient).
A similar file called [project]_ddfdrive.tec is also available
as a Party postprocessing option
(Tecplot option 14 for perfect gas or option 15 for generic gas).
Minor variations in the skin friction coefficients may be observed
between the file output from the flow solver and the file output
from party since the skin friction is calculated differently in each code;
for complete consistency, use the --write_aero_loads_to_file option.
Deflected Surface Input
The loads output as described above must usually be passed through an intermediate processing step to interpolate/transfer them to the structural grid, as the structural grid typically differs from the cfd grid. The user must provide for this transfer step. Similarly, output deflections from the structural model must be transferred back to the CFD grid, and this is also left up to the user. Ultimately, a new surface definition must be provided to the flow solver. This new surface file must adhere to the following naming convention:
{project}.body1_timestepM
where M is the current time step (excluding previous restarts, i.e. 1 <= M <= ncyc).
For steady state runs, M = 1, since the new surface is only read in on the first time step;
for unsteady runs, a new surface must be provided for each time step,
and the value of M is used to insure the right file is read for each time step.
As mentioned below, only one aeroelastic body is currently allowed,
hence body1 in the above naming convention.
The [project].body1_timestepM file is a formatted Tecplot file of the fepoint format, and is identical to that
described the the Time Dependent Flows Section, under Surface File Format In steady state
mode, where only one surface file is provided for the entire run of the flow solver, the time value is not
required as part of the title line.
Defining the Aeroelastic Surface
By default, all solid surfaces are assumed to be part of the single aeroelastic body. The user may override this default aeroelastic surface definition by providing an auxiliary file with the name:aeroelastic_boundariesAn example of the
aeroelastic_boundaries file is given below:
File for indicating which boundaries are aeroelastic number of aeroelastic boundaries (be careful with boundary lumping) 5 Boundary number 9 10 11 12 13
6.10. Ginput.faces Type Input
This is a description of the old method for input to FUN3D.
As of release 10.5.0, the ginput.faces input deck has been
replaced by a namelist file.
See the Flow Solver Namelist Input
section for details.
Perfect Gas
A typical ginput.faces input deck:
CASE TITLE
XMACH ALPHA YAW RE TREF PRANDTL
0.300 2.000 0.000 1.0e6 460.0 0.72
INCOMP IVISC IFLIM NITFO IHANE IVGRD
0 0 0 0 2 0
SREF CREF BREF XMC YMC ZMC
1.00000 1.00000 1.00000 0.25 0.00 0.00
CFL1 CFL2 IRAMP CFLTURB1 CFLTURB2
10.0 200.0 50 1.0 50.0
NCYC ITERWRT RMSTOL IREST
100 20 1.e-9 0
JUPDATE NSWEEP NCYCT PSEUDO_DT
3 15 10 1
ITIME DT SUBITERS
0 5.0 5
NGRID FMG_LEVS FMG_PRLNG NU1 NU2
1 1 1 1 1
FAS_LEVS FAS_CYCS NGAM
1 1 1
PROJECT_NAME:
'projectname'
The entries for each pair of lines is described in the following sections:
Freestream Conditions
XMACH |
This is the freestream Mach number for compressible flows.
For incompressible flows, this is the artificial compressibility
parameter, beta.
For incompressible flows, the suggested value is XMACH=15. |
|---|---|
ALPHA |
This is the freestream angle of attack in degrees. |
YAW |
This is the freestream side-slip angle in degrees. |
RE |
This is the freestream Reynolds number.
For inviscid computations, this value is ignored.
The input value depends on the reference length, and how
the grid is dimensioned.
If your Reynolds number is based on the MAC,
and the grid is constructed so that the MAC is one,
then the appropriate value for RE is the full freestream Reynolds number.
If the grid is constructed so that the MAC is in inches,
then RE must be set to the Reynolds number divided
by the MAC in inches. |
TREF |
This is the freestream reference temperature in
degrees Rankine.
The usual value is 460. |
PRANDTL |
This is the value of the Prandtl number.
The usual value is 0.72. |
Algorithm
INCOMP |
This flag toggles the incompressible option.
If INCOMP=0, then compressible flow is assumed
with a freestream Mach number equal to XMACH.
If INCOMP=1, then incompressible flow is used
with an artificial compressibility factor of XMACH. |
|---|---|
IVISC |
This controls the physics that you want.
The valid options are: 0:Euler, 2:Laminar,
6:Spalart-Allmaras model, 7:DES with
Spalart-Allmaras model, 8:Menter’s SST model. |
IFLIM |
This controls the limiter for the reconstruction process.
The valid options are: 0:No limiter, 1:Min-mod type,
2:Venkatakrishnan limiter.
We usually do without a limiter.
However, for Mach numbers > about 1.2, you may need
to use IFLIM=1. 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. |
NITFO |
This is the number of spatially first-order accurate
time-steps to run prior to switching to second-order
spatial accuracy. Note: for time accurate cases (itime /= 0), this
is the number of first-order accurate sub iterations to run for each time step.
The suggested value is NITFO=0. |
IHANE |
This controls which flux function you want to use
for the inviscid fluxes.
The valid options are: 0:Van Leer, 2:Roe, 3:HLLC,
4:AUFS, 5:central difference.
Roe’s scheme is suggested, but you may find that Van Leer
converges better for some cases.
For incompressible flow, the only valid option is IHANE=2.
Jacobians are Van Leer by default.
Other Jacobians can be selected with --roe_jac, --hllc_jac,
--aufs_jac, or --cd_jac command line options. |
IVGRD |
This flag is only relevant for viscous computations.
If IVGRD=1, the viscous fluxes will be neglected in cells
containing angles equal to 178 degrees or more (admittedly a hack).
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.)
The suggested value is IVGRD=0. |
Geometric References
SREF |
This is the reference area used for non-dimensionalization of forces and moments. |
|---|---|
CREF |
This is the reference chord used for non-dimensionalization of moments. |
BREF |
This is the reference span used for non-dimensionalization of moments. |
XMC |
This is the x coordinate used for moment computations, in grid units. |
YMC |
This is the y coordinate used for moment computations, in grid units. |
ZMC |
This is the z coordinate used for moment computations, in grid units. |
CFL Controls
Note: When running in time accurate mode (itime /= 0), the same definitions hold,
except that they are applied over IRAMP sub iterations during each time step:
CFL1 |
This is the starting CFL number.
The suggested value is CFL1=1.
The actual CFL number is determined by a linear ramp from
CFL1 to CFL2 over IRAMP time steps. |
|---|---|
CFL2 |
This is the maximum CFL number.
The suggested value is CFL2=200.
The actual CFL number is determined by a linear ramp from
CFL1 to CFL2 over IRAMP time steps. |
IRAMP |
This is the number of time steps over which to linearly ramp
the actual CFL number from CFL1 to CFL2.
The suggested value is 50. |
CFLTURB1 |
This is the starting CFL number for the turbulence equation.
The suggested value is CFLTURB1=1.
The actual CFL number is determined by a linear ramp from
CFLTURB1 to CFLTURB2 over IRAMP time steps. |
CFLTURB2 |
This is the maximum CFL number for the turbulence equation.
The suggested value is CFLTURB2=50.
The actual CFL number is determined by a linear ramp from
CFLTURB1 to CFLTURB2 over IRAMP time steps. |
Iteration Controls
NCYC |
This is the number of time steps to be run. |
|---|---|
ITERWRT |
The solution and convergence history will be written
to disk every ITERWRT time steps. |
RMSTOL |
This is the absolute value of the RMS residual at which the solver will terminate early. |
IREST |
This flag controls the restart option.
If IREST=0, the flow is initialized as freestream.
If IREST=1, the flow will be initialized by using
the previous solution information, and the convergence
history will be concatenated with the prior solution history.
If IREST=-1, the flow will be initialized by using
the previous solution information, but the convergence
histories will not be concatenated. |
Updates
JUPDATE |
After the first 10 iterations, Jacobians are updated
every JUPDATE iterations.
The suggested setting is JUPDATE=3. |
|---|---|
NSWEEP |
Number of Gauss-Seidel sub iterations for the linear
problem at each time step.
The suggested value is 15. |
NCYCT |
Number of Gauss-Seidel sub iterations for the
turbulence model linear problem at each iteration.
The suggested value is 10. |
PSEUDO_DT |
Needs to be set to 1 for steady-state-type cases (ITIME=0).
For time accurate cases, controls whether a pseudo time term
is added to the physical (global) time step or not. Use PSEUDO_DT=1
to add the term; otherwise use PSEUDO_DT=0.
When added, the value of the pseudo time term
varies spatially according to a local CFL constraint.
Note that when ramping the CFL of the pseudo time term, the final CFL
will be obtained only if subiters >= iramp.
The psuedo time term typically allows larger physical time steps
to be taken than might otherwise be possible. By the end of a
convergent subiteration process, the pseudo time term drops out,
giving the correct temporal discretization.
The suggested value is PSEUDO_DT=1.
[Introduced version 3.2.3.] |
Time
ITIME |
Controls time accuracy: 0:steady-state, 1:the scheme
is first-order accurate in time,
2:the scheme is second-order accurate in time,
3:the scheme is third-order accurate in time [Introduced version 10.0],
-3:the scheme is in between second-order and third-order accurate
in time (“BDF2opt”) [Introduced version 10.0].
Before version 3.2.3: 1:steady-state, 2:the scheme
is second-order accurate in time.
The suggested value is the steady-state value.
The physical time step is controlled by DT > 0. |
|---|---|
DT |
This is the actual time step used for time-accurate
computations (ITIME > 0).
The value of DT will depend on your time-dependent problem.
Before version 3.2.2, local time-stepping is used if
DT < 0 so it was only used when DT > 0. |
DTAU |
This is the pseudo-time step used for the sub iterations.
[Removed version 3.2.3: now controlled by
PSEUDO_DT, CFL1, CFL2] |
SUBITERS |
The number of sub iterations applied to solve the implicit backward time formula. |
Multigrid
NGRID, FMG_LEVS, FMG_PRLNG, FAS_LEVS, |
Multigrid parameters.
This option is not complete—leave all parameters
at their default: 1. |
|---|
Project Rootname
PROJECT_NAME |
Project name for the grid. It must be enclosed in single quotes. |
|---|
Hypersonics
In the old ginput.faces input deck, a hypersonic (generic gas)
case contained the same 21 lines of input information as ideal-gas cases
(although not all parameters were used), plus an additional 10 lines
specifically for generic gas at the end.
ginput.faces, is shown below.
Line numbers are not part of the file.
1 CASE TITLE 2 XMACH ALPHA YAW RE TREF PRANDTL 3 15.00 3.00 0.0000 4.00e5 200.0 0.72 4 INCOMP IVISC IFLIM NITFO IHANE IVGRD 5 2 2 0 0 2 0 6 SREF CREF BREF XMC YMC ZMC 7 1.00000 1.00000 1.00000 0.25 0.00 0.00 8 CFL1 CFL2 IRAMP CFLTURB1 CFLTURB2 9 1.e+06 1.e+06 100 000.100 200.000 10 NCYC ITERWRT RMSTOL IREST 11 1000 50 1.E-15 1 12 JUPDATE NSTAGE NCYCT 13 10 10 10 14 ITIME DT DTAU SUBITERS 15 1 -5.000 .001 10 16 NGRID FMG_LEVS FMG_PRLNG NU1 NU2 17 1 1 1 1 1 18 FAS_LEVS FAS_CYCS NGAM 19 1 1 1 20 PROJECT_NAME: 21 'cylinder' 22 V_INF RHO_INF T_INF LEN_REF T_WALL 23 5000.0 0.00100 200. 1. 500. 24 CHEM_FLAG THERM_FLAG TURB_MODEL_TYPE 25 0 0 0 26 RF_INV RF_VIS EIG0 EIG0_IMP 27 2.0 1.0 1.0e-30 5.e-02 28 TURB_INT_INF TURB_VIS_RATIO_INF PRANDTL_TURB 29 0.01 0.1 0.9 30 REYNOLDS_STRESS_MODEL TURB_COND_MODEL TURB_COMP_MODEL 31 0 0 0The first 21 lines of the file have identical format to traditional perfect gas FUN3D specifications. However, some entries are ignored or play a different role if the generic gas path for hypersonic flow is selected. These differences will be explained subsequently but it is assumed that the user is already familiar with these first twenty-one (21) lines. If not, the user should consult the description of the
ginput.faces file
in the perfect gas section of the FUN3D users manual first.
Additional parameters required for the generic gas path appear in lines
(22) – (31).
The format maintains the pattern of a list of parameter names on one
line and the associated parameter values positioned under the respective
name on the next line.
The generic gas path is selected when the input integer parameter INCOMP
is set to 2 on line (5).
Recall that the perfect gas, compressible path is selected when INCOMP
is set to 0 and the incompressible path is selected when INCOMP is set
to 1.
Lines (22)-(31) will only be read if INCOMP is set to 2 on line (5).
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.
The parameter IVISC may be set to 0 (inviscid flow) or 2 (viscous
flow).
Other options used in FUN3D do not apply in the generic gas path (when
INCOMP is set to 2).
Branches for laminar or turbulent flow using various models are
controlled by the new parameter TURB_MODEL_TYPE to be defined
subsequently.
Because the turbulent model equations are solved in a fully coupled
manner with the other conservation laws in the generic gas path the
parameters which control relaxation of an independent set of turbulence
equations, CFLTURB1, CFLTURB2, NCYCT in the perfect-gas path are
ignored.
Two options are available for second-order spatial accuracy.
The integer parameter IHANE from FUN3D on line (3) assumes a new role
to define these options.
Both options use Roe’s averaging.
If IHANE is set to 1 on line (4) 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 if IFLIM in FUN3D.
If IHANE is set to 2 on line (4) 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 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.
In hypersonic applications, the inflow boundary conditions are given in
terms of a uniform velocity (V_INF), mixture density (RHO_INF), and
temperature (T_INF).
These input parameter names appear on line (22) and associated values on
line (23).
The MKS system is used for these inputs; consequently, velocity must be
entered in units of meters per second, density in units of kilograms per
meter cubed, and temperature in degrees Kelvin.
The grid scaling factor (LEN_REF) converts from grid units to meters in
units of meters per grid unit.
For example, if grid units are in inches then LEN_REF is set to 0.0254
(meters per inch).
Mach number and Reynolds number per grid unit are computed from these
fundamental inputs; consequently, the entries for Mach number (XMACH),
Reynolds number (RE), reference temperature TREF, and Prandtl number
(PRANDTL) from the perfect-gas path are ignored on line (3).
A wall temperature (TWALL) is also entered on line (23) in units of
degrees Kelvin.
If a non-constant wall temperature boundary condition is specified (see
Boundary Conditions for Generic Gas Option) then this parameter serves
only to initialize the surface boundary condition.
Three gas model flags are defined on lines (24) and (25).
The flag name appears on line (24) and the associated value appears
beneath it on line (25).
The flag CHEM_FLAG is set to 0 for chemically frozen flow or to 1
for chemically reacting flow.
This flag is engaged only in the case of multiple species defined in
file tdata.
If it is set to zero 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 one 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 THERM_FLAG is set to 0 for thermally frozen flow or to 1
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 zero 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 1 then the source term models particle collisions in
which particle internal energy in the translational, rotational,
vibrational, and electronic modes can be exchanged.
The flag TURB_MODEL_TYPE engages various multi-equation turbulence
models.
This flag is set to 0 for laminar flow.
Other models are under construction.
Four numerical parameters unique to the generic gas path are named on
line (26) and set on line (27).
Their names and intended function are inherited from the structured
grid, hypersonic flow solver LAURA.
As experience is gained with the generic gas path, the role of
these numerical parameters has been modified.
The parameter RF_INV 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 RF_INV.
The first four limiting factors are computed internally and designed to
limit the rate of change of pressure, density, temperature, and
velocity.
If RF_INV is set to 1.0, no further limiting is engaged.
The parameter RF_VIS 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 EIG0 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 EIG0 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 EIG0_IMP 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.
Lines (28)-(31) contain parameter names and values for various multi-equation turbulence models. These models are under construction.
6.11. Flow Visualization Output Directly From Flow Solver
This section describes how to obtain solution output for flow visualization directly from the flow solver, without having to run party in the postprocessing mode. At the current time, only TECPLOT data output is supported; this is not to be considered as an endorsement of TECPLOT.
This capability is available in Version 10.7 and higher.
This capability is not currently available for the Generic Gas Option.
| General Information |
| Output Variable Choices |
| Boundary Data Output |
| Sampling Surface Data Output |
| Volumetric Data Output |
General Information
The FUN3D partitioning code, party, has long had a postprocessing capbility in which the files generated by the flow solver are read, combined into a single global image of the solution, and then output via user-selected options for either surface or volumetric data, typically in TECPLOT or FIELDVIEW format. There are several drawbacks to the party postprocessing approach: 1) it is slow for large meshes since one processor must do all the work; 2) it requires a processor with a significant amount of memory if the problem size is large; 3) although there are a number of output options, the output is not particularly customizable for individual requirements in terms of which variables are output.
In FUN3D Version 10.7, some of these deficiencies are addressed by allowing output to be requested from the flow solver directly. At the present time, only TECPLOT-compatible data is output, but what data is output is customizable (see Output Variable Choices). There are 3 basic categories of output: boundary data, “sampling surface” data (on surfaces such as planes, boxes and spheres), and volumetric data. Depending on user requirements, these data may be output at specified frequencies (i.e. every Nth time step / iteration) or only at the end of the execution. The processing of this data is done largely in parallel, and so is typically much faster than requesting similar output from party. Boundary data and sampling surface data are reduced to a single global image before output at a particular time step, although volumetric data is not. Thus, a solution for which volumetric data as requested will write out one file from each processor for each time step at which output is requested. TECPLOT’s multiple file read option can be used to manage the large number of files, but the number of volumetric files written out from a time-dependent case can be quite large even if written infrequently.
The naming convention for each type of data output will be described below, but the file
extension will either be .dat for ASCII files or .plt for binary files. Binary files are output
when FUN3D is configured with TECPLOT’s tecio library
(See Third-Party Libraries – TECPLOT). Assuming you have configured
FUN3D with the tecio libraries, you may still obtain ASCII output by specifyig the command-line
option --ascii_tecplot_output
Output Variable Choices
By default, the variables that are output from the flow solver are x,y,z and the primitive variables rho, u, v, w, and p. For overset meshes, iblank is also part of the default output. If these variables are not what is wanted, alternate data can be chosen via namelist input in a file called “namelist.input” (“fun3d.nml” in 10.9.0 and later); each output category (boundary data output, sampling surface data output or volumetric data output) has its own namelist – see the individual sections for details. The variables listed below are available for either boundary data output, sampling surface data output or volumetric data output. Boundary data output has a few additional variables that are available for output; these special variables are listed in that section. Most variable names should be relatively self-descriptive – a brief description is given in [ ] for completeness. Note that each variable must be spelled as shown below, i.e. pressure coefficient must be requested as cp and not Cp, c_p etc. Also note that all are input as logical variables, either .true. or .false. – e.g. cp = .true. All output variables are nondimensional.
x, y, z [grid coordinates] u, v, w [velocity components] p, cp [pressure, pressure coefficient] mach [Mach number] entropy [entropy] vort_x, vort_y, vort_z [components of vorticity] vort_mag [magnitude of vorticity] q_criterion [second invariant of the velocity-gradient tensor] iblank [grid blanking value (overset grid)] imesh [associated component mesh number (overset moving grid)] slen [distance from nearest solid surface] turb1, turb2 [turbulence variable (1 or 2 equation turb. model)] mu_t [eddy viscosity] uuprime, vvprime, wwprime [turbulent fluctuation uvprime, uwprime, vwprime velocity products] volume [dual-cell volume] res1, res2, res3, res4, res5 [mass, momentum(3) and energy residuals] turres1, turres2 [turbulence residuals (1 or 2 equation turb. model)] res_gcl [geometric conservation law residual] rho_tavg, p_tavg [time-averaged density and pressure (version 10.8 and higher)] u_tavg, v_tavg, w_tavg [time-averaged velocity components (version 10.8 and higher)] rho_trms, p_trms [time-rms density and pressure (version 10.8 and higher)] u_trms, v_trms, w_trms [time-rms velocity components (version 10.8 and higher)]
In addition, there are a few “short cut” names available – the variables in [ ] are covered by the short-cut name:
primitive_variables [rho, u, v, w, p] turbulent_fluctuations [uuprime, vvprime....vwprime] residuals [res1, res2...res4, (res5)...turres1, (turres2)] primitive_tavg [rho_tavg, u_tavg, v_tavg, w_tavg, p_tavg (version 10.8 and higher)] primitive_trms [rho_trms, u_trms, v_trms, w_trms, p_trms (version 10.8 and higher)]
NOTE: If you do not desire one or more of the default variables, you must explicitly set those variables as false in the appropriate namelist. For example, to get x, y, z and pressure coefficient output instead of x, y, z, and rho, u, v, w, and p, set primitive_variables = .false. and cp = .true. In this example, use is made of the short cut name for the primitive variables, but alternatively they could be turned off individually.
Note that although any or all of these variables may be requested, there are combinations of input parameters and output variable requests that are simply incompatable. For example, if your input deck is set for laminar flow and you request turb1, turb2 or mu_t, the code will warn you you cannot have that output, and will carry on and output just the valid output requests. Likewise, if you request turb2 output from a 1-equation turbulence model, that will be denied. There are potentially numerous other incompatible output requests – hopefully all are caught.
Boundary Data Output
Boundary output is activated via the command-line option -- animation_freq N,
where N = + / – 1,2,3… A ”+” (or no) sign for N will cause the output to be generated every
Nth time step/iteration. A ”-” sign with any (non-zero) value of N will cause output to be
written only at the end of a run. The behavior of the +/- sign is the same whether the case
is time accurate or steady, but typically one would use ”-” for steady-state (where only the
final data is usually of interest) and ”+” for unsteady flows.
To alter the default variable output (x, y, z, rho, u, v, w, p), the undesired variables must
be turned off and the desired variables turned on in the &boundary_output_variables namelist
in the namelist.input file (fun3d.nml for releases 10.9.0 and later). The example below
illustrates the use of the namelist input to
output only x and z, and rho, u, w, and cp on the boundary, as might be desired for a 2D case:
&boundary_output_variables y = .false. v = .false. p = .false. cp = .true. /
Note that these variable selections in the &boundary_output_variables namelist apply ONLY
to boundary output. Other output (e.g. sampling surface) will still contain default
variables unless similar choices are made in the appropriate namelist.
By default, the --animation_freq command will cause output of solution data for all solid
surfaces in 3D
and on one y=const. symmetry plane in 2D. The user may alter this default output by providing an file
called “boundaries_to_animate” in the run directory. This ASCII file has a very simple structure.
For example, to output data on boundaries 2, 5, and 9:
File for specifying which boundaries are to be output when using --animation_freq No. boundaries to output (be careful with boundary lumping) 3 Boundary to output 2 5 9
The text lines (lines 1,2 and 4 in the file) can contain any text (or can even be blank lines). Any boundaries in the mesh may be output in this manner, not just solid surfaces or y-symmetry planes.
All output boundaries are written to one file each time boundary data output is triggered.
The resulting boundary-data files will have the following naming convention:
[project]_tec_boundary_timestepT.dat (or .plt) if N > 0 [project]_tec_boundary.dat (or .plt) if N < 0
where T is the time step or iteration number. Within the files, each boundary is written as a separate zone, and zones are identified as, for example:
zone T "time 0.0000000E+00 boundary 5"
where the time value is zero for steady-state cases, and the current (nondimensional) time for time-dependent cases.
In TECPLOT360-2008, zones may be parsed by time (i.e. type the word time in the parse box) in the Unsteady Flow Ootions dialog box if “Flow Solution is Steady-State” is not checked. Once zones are parsed by time, they may be animated by time level; this is very useful in animating cases with multiple boundaries, or if the files corresponding to each time step are not read into TECPLOT in order.
In addition to the variables listed in Output Variable Choices, the following variables are also available for output on boundaries:
uavg, vavg, wavg [average off-surface velocity components (for streamlines)] yplus [friction length] cf_x, cf_y, cf_z [skin friction components] skinfr [skin friction magnitude, with sign] cq [heat transfer coefficient - actually just dT/dn]
The following “short cut” name is available – the variables in [ ] are covered by the short-cut name:
average_velocity [uavg, vavg, wavg]
Sampling Surface Data Output
Sampling output (output on one or more basic surfaces such as planes, spheres, and boxes) is activated via the command-line option --sampling_freq N,
where N = + / – 1,2,3… A ”+” (or no) sign for N will cause the output to be generated every
Nth time step/iteration. A ”-” sign with any (non-zero) value of N will cause output to be
written only at the end of a run. The behavior of the +/- sign is the same whether the case
is time accurate or steady, but typically one would use ”-” for steady-state (where only the
final data is usually of interest) and ”+” for unsteady flows.
To alter the default variable output (x, y, z, rho, u, v, w, p), the undesired variables must
be turned off and the desired variables turned on in the &sampling_output_variables namelist
in the namelist.input file (fun3d.nml for releases 10.9.0 and later). The example below
illustrates the use of the namelist input to
output the distance from the wall (used in turbulence models), along with the eddy viscosity,
rather than the primitve variables, on the sampling surface:
&sampling_output_variables primitive_variables = .false. slen = .true. mu_t = .true. /
Note thate these variable selections in the &sampling_output_variables namelist apply ONLY
to sampling output. Other output (e.g. boundary data) will still contain default
variables unless similar choices are made in the appropriate namelist.
The surfaces on which solution data is output must be specified by additional namelist input, described below
The resulting sampling-surface data files will have the following naming convention:
[project]_tec_sampling_geomG_timestepT.dat (or .plt) if N > 0 [project]_tec_sampling_geomG.dat (or .plt) if N < 0
where G = 1,2,...number_of_geometries (as set via the &sampling_output_variables namelist) and T is the time step
or iteration number. Within the files, a global image of the sampling surface is output, with the zone identified as,
for example:
zone T "time 0.0000000E+00 geom 3"
where the time value is zero for steady-state cases, and the current (nondimensional) time for time-dependent cases. See the note near the bottom of the boundary data output section for parsing by time level for animation of unsteady flows.
&sampling_parameters namelist
In addition to the &sampling_output_variables namelist, which is similar to
those required for boundary and volumetric output, sampling-surface output
requires additional data, which is input via a namelist called
&sampling_parameters; this namelist input must appear in the
namelist.input file (fun3d.nml for releases 10.9.0 and later). Details of the variables in this namelist are described
below. A (G) implies that the input value is set once/applies to all output
surfaces; and (S) indicates that variable must be specified for each surface.
number_of_geometries |
Number of geometries (sampling surfaces) to be output (G) (Default: 0) |
|---|---|
type_of_geometry |
Description of the geometry (S) (Default: ‘none’; choices: ‘plane’, ‘box’ ‘sphere’, ‘circle’, ‘quad’; ‘box’ and ‘sphere’ are 3D geometries, while ‘quad’, ‘circle’ and ‘plane’ are planar geometries) |
plane_center |
x,y,z coordinates of the center of the plane, for type_of_geometry = ‘plane’ (S) (Default: 0.0, 0.0, 0.0) |
plane_normal |
x,y,z components of a unit vector to the plane (sign is immaterial), for type_of_geometry = ‘plane’ (S) (Default: 0.0, 0.0, 0.0) |
box_lower_corner |
x,y,z coordinates of the lower corner of the box, for type_of_geometry = ‘box’ (S) (Default: 0.0, 0.0, 0.0) |
box_upper_corner |
x,y,z coordinates of the upper corner of the box, for type_of_geometry = ‘box’ (S) (Default: 0.0, 0.0, 0.0) |
sphere_center |
x,y,z coordinates of the center of the sphere, for type_of_geometry = ‘sphere’ (S) (Default: 0.0, 0.0, 0.0) |
sphere_radius |
Radius of the sphere, for type_of_geometry = ‘sphere’ (S) (Default: 0.0) |
circle_center |
x,y,z coordinates of the center of the circle, for type_of_geometry = ‘circle’ (S) (Default: 0.0, 0.0, 0.0) |
circle_normal |
x,y,z components of a unit vector to the circle(sign is immaterial), for type_of_geometry = ‘circle’ (S) (Default: 0.0, 0.0, 0.0) |
circle_radius |
Radius of the circle, for type_of_geometry = 'circle' (S) (Default: 0.0) |
corner1 |
x,y,z coordinates of the 1st corner of the quad, for type_of_geometry = ‘quad’; corners proceed clockwise (S) (Default: 0.0, 0.0, 0.0) |
corner2 |
x,y,z coordinates of the 2nd corner of the quad, for type_of_geometry = ‘quad’; corners proceed clockwise (S) (Default: 0.0, 0.0, 0.0) |
corner3 |
x,y,z coordinates of the 3rd corner of the quad, for type_of_geometry = ‘quad’; corners proceed clockwise (S) (Default: 0.0, 0.0, 0.0) |
corner4 |
x,y,z coordinates of the 4th corner of the quad, for type_of_geometry = ‘quad’; corners proceed clockwise (S) (Default: 0.0, 0.0, 0.0) |
crinkle |
Plot output surface(s) as crinkle surface (G) (Default: .false. [smooth]) |
print_boundary_data |
Print data (for debugging?) (G) (Default: 0 [don’t print]) |
plot |
Choice of TECPLOT or Fieldview output (G) (Default: ‘tecplot’; alternate: ‘fieldview’) |
connect_triangles |
Perform additional sorting to remove duplicate triangles where processor boundaries overlap – NOT RECOMMENDED (G) (Default: .false. ) |
In the example below, two planes of data are output;
&sampling_parameters number_of_geometries = 2, type_of_geometry(1)='plane', ! start plane 1 data plane_center(1,1) = 3.5 ! x 2nd index is geom # plane_center(2,1) = 0.0 ! y plane_center(3,1) = 0.0 ! z plane_normal(1,1) = 1.0 ! xn plane_normal(2,1) = 0.0 ! yn plane_normal(3,1) = 0.0 ! zn type_of_geometry(2)='plane' plane_center(1,2) = 0.0 ! start plane 2 data plane_center(2,2) = 10.8333333333333 plane_center(3,2) = 0.0 plane_normal(1,2) = 0.0 plane_normal(2,2) = 1.0 plane_normal(3,2) = 0.0 /
In the next example, a range of geometries are output; this example also depicts a slightly more compact means of specifying the namelist data.
&sampling_parameters
number_of_geometries=5,
type_of_geometry(1)='plane',
plane_center(:,1)=4.0,0.0,0.0,
plane_normal(:,1)=1.0,0.0,0.0,
type_of_geometry(2)='quad',
corner1(:,2)=-2.0,-5.0, 6.0,
corner2(:,2)=-2.0,-5.0,-6.0,
corner3(:,2)=-2.0 ,5.0,-6.0,
corner4(:,2)=-2.0, 5.0, 6.0,
type_of_geometry(3)='circle',
circle_center(:,3) = 0.0, 0.0, 0.0,
circle_normal(:,3) = 1.0, 0.0, 0.0,
circle_radius(3) = 5.0,
type_of_geometry(4)='box',
box_lower_corner(:,4) = -5.1, -5.1, -5.1,
box_upper_corner(:,4) = 5.1, 5.1, 5.1,
type_of_geometry(5)='sphere',
sphere_center(:,5) = 1.0, 1.0, 1.0
sphere_radius(5) = 5.0,
/
Volumetric Data Output
Volumetric output (output for every point in the domain) is activated via the command-line option --volume_animation_freq N,
where N = + / – 1,2,3… A ”+” (or no) sign for N will cause the output to be generated every
Nth time step/iteration. A ”-” sign with any (non-zero) value of N will cause output to be
written only at the end of a run. The behavior of the +/- sign is the same whether the case
is time accurate or steady, but typically one would use ”-” for steady-state (where only the
final data is usually of interest) and ”+” for unsteady flows.
Caution: volumetric data is not concatenated into a single global image, as is done for boundary ans sampling-surface data. Every processor writes its own file, for each timestep for which output is requested. Thus, a very large number of files may be generated for N > 0.
To alter the default variable output (x, y, z, rho, u, v, w, p), the undesired variables must
be turned off and the desired variables turned on in the &volume_output_variables namelist
in the namelist.input file (fun3d.nml for releases 10.9.0 and later). The example below illustrates the use of the namelist input to
output the three components of vorticity, rather than the primitve variables, at each point
in the field:
&volume_output_variables primitive_variables = .false. vort_x = .true. vort_y = .true. vort_z = .true. /
Note thate these variable selections in the &volume_output_variables namelist apply ONLY
to volumetric output. Other output (e.g. boundary data) will still contain default
variables unless similar choices are made in the appropriate namelist.
The resulting volume-data files will have the following naming convention:
[project]_partP_tec_volume_timestepT.dat (or .plt) if N > 0 [project]_PartP_tec_volume.dat (or .plt) if N < 0
where P = 1,2,...nproc (number of processors) and T is the time step or iteration number. Within the files, a single zone is written, with the zone identified as, for example:
zone T "time 0.0000000E+00 processor 32"
where the time value is zero for steady-state cases, and the current (nondimensional) time for time-dependent cases. See the note near the bottom of the boundary data output section for parsing by time level for animation of unsteady flows.
Today's NASA Official:
Jeff White, a member of
The FUN3D Development Team
Contact: FUN3D-support@lists.nasa.gov
NASA Privacy Statement