Intent: Demonstrate setup and execution of moving overset grids (FUN3D Version 10.7 and higher)

This tutorial will describe how to set up and run a case with moving geometry utilizing overset meshes.

Note: the input data provided in the download files is for FUN3D Version 10.7 and higher and will not work without modification with earlier versions

All the grid and input files may be downloaded below. Note that the grids for this case are very coarse and are intended for demonstration, rather than accurate aerodynamic analysis. The geometry consists of a wing and a store, and is one of the geometries included in SUGGAR training materials.

The user should be familiar with running the baseline flow solver, and preferably with running moving geometry cases that don’t require overset grids (See Time Accurate – Moving Geometry).

The process is composed of a few basic steps. The download file has a directory structure roughly aligned with these steps. This directory structure is convenient for demonstrating the process, but is not required. First, a composite mesh with the configuration in the initial position is generated from component meshes (in this case wing and store) by running SUGGAR. The domain connectivity information (dci) for the geometry in the initial position is also computed by SUGGAR. Next, the composite mesh is partitioned using party. The resulting part files are then used for both an initial, steady-state computation and a subsequent, time-dependent, moving grid computation in which the store motion is specified as a constant downward velocity. The included README files provide step-by-step directions similar to those given on this web page.

Compilation and linking

To use overset grids, you must obtain, compile and link the third-party libraries SUGGAR and DiRTlib. See Third-Party Libraries – SUGGAR and Third-Party Libraries – DiRTlib for details.

Files

Download (9.6Mb) and gunzip/untar the files:

Wing_Store/
  README
  Component_Grids/
    store.cogsg
    store.mapbc
    wing.cogsg
    wing.mapbc
    wing.bc
    store.bc
  T=0_Domain_Connectivity/
    Input.xml
    README
  Part_Files/
    party.input
    README
  Steady_State/
    README
    RUN_IT
    fun3d.nml
  Dynamic_Specified/
    moving_body.input
    README
    RUN_IT
    fun3d.nml

Create the composite mesh and initial domain connectivity information

In this step the component grids, located in the Component_Grids directory, are combined into a single composite VGRID set using SUGGAR, and at the same time the domain connectivity information is computed for the configuration in the initial t=0 position. Below it is assumed that your suggar executable is called suggar_3d_opt.linux-64; your executable may be named differently, depending on your compilation platform and compilation options. It is also assumed for illustration purposes that your SUGGAR executable is located in a directory /Your/Path/To/Suggar. The input for SUGGAR is provided in the Input.xml file located in the T=0_Domain_Connectivity directory.

  cd Wing_Store/T=0_Domain_Connectivity
  ln -s ../Component_Grids/* .
  ln -s /Your/Path/To/Suggar/suggar_3d_opt.linux-64 .
  (./suggar_3d_opt.linux-64 Input.xml > suggar_output) >& suggar_error &

At this point you should have the domain connectivity file wingstore.dci, along with a VGRID file set (wingstore.cogsg, wingstore.mapbc, wingstore.bc) for the composite mesh. You may want to check to see if any orphan points resulted – indeed a handful (11) occur:

  grep "orphans because" suggar_error

You may want to use the GVIZ utility code for SUGGAR, available from Ralph Noack to view the composite mesh. GVIZ allows visualization of the composite mesh, hole points and fringe points, and can aid in debugging hole-cutting issues. However, it is beyond the scope of this FUN3D tutorial to describe the use of GVIZ.

Partition the composite mesh

The next step is to use party to partition the composite mesh. Below, it is assumed that your party executable is located in /Your/Path/To/Party

  cd ../Part_Files
  ln -s ../T=0_Domain_Connectivity/wingstore.* .
  ln -s /Your/Path/To/Party/party .
  ./party --overset <party.input

At this point you should have 8 partition files. If you wish to use other than 8 processors, modify the last line in party.input (you will also then need to modify the RUN_IT scripts in the Steady_State and Dynamic_Specified directories). In addition to the wingstore_part.N files, for overset cases we will need the wingstore.part and wingstore.g2l files generated by party.

Steady-state solution

Next, we obtain a steady-state solution for the configuration in the t=0 position. This steady-state solution will be used as the initial solution for the dynamic simulation. A sample run script, RUN_IT, is provided, though it may need modification for your particular system. Note that the RUN_IT script contains some command-line options not available in FUN3D earlier than version 10.7. These command-line options are used to generate solution-visulaization (TECPLOT) output from within the flow solver without running party for post-processing. Below, it is assumed that your FUN3D executable (nodet_mpi) is located in /Your/Path/To/Fun3d

  cd ../Steady_State
  ln -s ../Part_Files/*_part.* .
  ln -s ../Part_Files/wingstore.g2l .
  ln -s ../Part_Files/wingstore.part .
  ln -s /Your/Path/To/Fun3d/nodet_mpi .
  ./RUN_IT

In version 10.7 and higher, the—animation_freq -1—sampling_freq -1 options generate TECPLOT output at the end of the flow solver execution. See Flow Visualization Output Directly From Flow Solver for more information. Here we have used the—sampling_freq option, together with input from the namelist.input file (fun3d.nml in version 10.9.0 and later), to extract Cp data on a y=0 plane through the flow domain. The—animation_freq option, together with input from the namelist.input file (fun3d.nml in version 10.9.0 and later), is used to extract Cp data on the solid surfaces (wing and store surfaces). Because this is an overset mesh, the default output will contain iblank data. If you have configured FUN3D to link against TECPLOT’s tecio libraries (See Third-Party Libraries – TECPLOT), then these visualization files will be binary, and will have a .plt extension; otherwise, they will be ASCII files and have a .dat extension. TECPLOT360-2008 was used to generate the following image from the wingstore_tec_boundary.plt (or .dat) and wingstore_tec_sampling_geom1.plt (or .dat) files. Value blanking on variable iblank was used, with blanking for iblank=0.

Dynamic, moving-grid solution

The steady-state solution obtained above may be used as a starting point for the moving-mesh simulation. Not all moving-mesh simulations need be or in fact can be started from a steady state, although in this case the steady-state initial condition is reasonable. Note that the same part files used for the steady simulation are used here; part files remain unchanged as the mesh is moved.

  cd ../Dynamic_Specified
  ln -s ../Part_Files/*_part.* .       (part files correspond to the composite mesh)
  ln -s ../Part_Files/wingstore.g2l .
  ln -s ../Part_Files/wingstore.part .
  ln -s ../Component_Grids/* .         (dynamic overset grids need the component grids too)
  ln -s ../T=0_Domain_Connectivity/wingstore.dci .  (always need the initial dci data)
  ln -s ../T=0_Domain_Connectivity/Input.xml .
  ln -s /Your/Path/To/Fun3d/nodet_mpi .

The motion simulation here is one in which the velocity of the store is specified to be constant, in a downward direction. The moving_body.input file provided in the download tar file is reprodiced below:

&body_definitions
  n_moving_bodies = 1,        ! number of bodies in motion
  body_name(1) = 'store',     ! name must be in quotes
  n_defining_bndry(1) = 1,    ! number of boundaries that define this body
  defining_bndry(1,1) = 4,    ! index 1: boundry number index 2: body number
  mesh_movement(1) = 'rigid', ! 'rigid' or 'deform'
  motion_driver(1) = 'forced' ! motion is specified below
/

&forced_motion
  translate(1) = 1,               ! translation type: 1=constant rate 2=sinusoidal
  translation_rate(1) = -0.2,     ! translation veolcity (mach)
/

&composite_overset_mesh
  n_component_grids    =   2,      ! obsolete in version 10.8 and higher
  ref_vgrid_set(  1)   = 'wing',   ! obsolete in version 10.8 and higher
  ref_body_name( 1)    = 'wing',   ! obsolete in version 10.8 and higher
  ref_vol_name( 1)     = 'wing',   ! obsolete in version 10.8 and higher
  associated_body(  1) =   0,      ! obsolete in version 10.8 and higher
  ref_vgrid_set(  2)   = 'store',  ! obsolete in version 10.8 and higher
  ref_body_name( 2)    = 'store',  ! obsolete in version 10.8 and higher
  ref_vol_name( 2)     = 'store',  ! obsolete in version 10.8 and higher
  associated_body(  2) =   1,      ! obsolete in version 10.8 and higher
  input_xml_file = 'Input.xml'
/

See Time Accurate – Moving Geometry for descriptions of all input parameters above. However, a few comments are warranted here. In creating the part files, the option to “lump boundaries by vgrid family” was chosen. Thus in the composite mesh, the store appears as a single boundary, boundary number 2. This is reflected in the wingstore.part_info that is created when party is run in the Part_Files directory. It is this lumped boundary numbering that must be used in the &body_definitions namelist above. Because the compressible flow equations in FUN3D are normalized with speed of sound, the specification of the body velocity of -0.2 is equivalent to Mach 0.2 (downward); the freestream Mach number in this case is 0.95.

FUN3D Version 10.8 and higher: &composite_overset_mesh namelist contains only one entry, input_xml_file, and this should be specified as the Input.xml file that was used with SUGGAR to compute the initial (static) DCI data.

FUN3D Version 10.7: In the &composite_overset_mesh namelist, the ref_body_name should correspond to the name specified in the corresponding <body > component of the input_xml_file file. The input_xml_file should correspond to the Input.xml file used to assemble the initial composite mesh. If the body is in motion, ref_body_name should also correspond to the body_name in the &body_definitions namelist. Likewise, the associated_body should correspond to the body number in the &body_definitions namelist if the body is in motion. If not in motion, the associated_body should be set to 0, as exemplified by the wing component grid. The ref_vgrid_set in the &composite_overset_mesh namelist should correspond to the filename specified in the <volume_grid > entry of the input_xml_file. Likewise, the ref_vol_name should correspond to the name specified in the <volume_grid > entry. In this example the ref_body_name, ref_vgrid_set, and ref_vol_name all happen to be the same, but that need not be the case in general.

The included RUN_IT script for the moving mesh run is reproduced below.

#!/bin/sh
(mpirun -np 9 -nolocal  -machinefile machinefile ./nodet_mpi --dci_on_the_fly --sampling_freq 5  --animation_freq 5 --moving_grid  --overset > screen_output) >& error_output &
exit

Several important points need to be made here. First, note that the command line option --dci_on_the_fly is used trigger a computation of new domain connectivity information at each new time step. This is necessitated by the use of --overset in conjunction with --moving_grid, together with the fact that dci files do not exist aprior for the store mesh at each new position. If the dci files for each time step did already exist, then --dci_on_the_fly would not be needed and they would simply be read in each time step. When --dci_on_the_fly is utilized, the flow solver will write out dci files for each time step; these can be reused for repeat runs, without having to do the (relatively expensive) calculation of the dci data each step. This is most useful in periodic motions, where the the flow solver is first run for one period of motion with --dci_on_the_fly. Subsequent restarts omit --dci_on_the_fly and instead use --dci_period N where N is the number of time steps in the period. Note that this example is NOT periodic, so any restarts beyond the 50 time steps in the fun3d.nml file need to be run with --dci_on_the_fly.

Note also that although this example was partitioned in 8 parts, the number of processors used is 9. When --dci_on_the_fly is used, the number of processors MUST be one larger than the number of partions. At the current time, one processor is dedicated to computing the dci data. Future versions of the SUGGAR libraries are expected to support multiple processors for the dci computation. A very important consequence of the single processor computation of the dci data is that that processor must have sufficient memory to hold the entire mesh on that processor. The SUGGAR processor is the first processor in the machinefile list. If the dci files already exist, so that --dci_on_the_fly is not used, the the number of processors must be set back to equal the number of partitions.

The command-line options—sampling_freq 5 —animation_freq 5 are used to dump out tecplot files much like was done for the steady-state case, except that now the files are generated every 5 time steps. File names contain “_timestepN” to denote which timestep they correspond to. TECPLOT360-2008 was used to generate the animation files below. All .plt (or .dat) files were read with the multiple files option, and in the “Unsteady Flow Options” panel (under the “Analyze” panel) was used to parse the zones by time. Then animation was created using the “Step by Time” option in the “Animation” panel. The first animation shows Cp, analogous to the still image created from the steady-state solution. The second animation shows the dynamic hole cutting as the mesh is moved. To make this animation the mesh was colored by the contour variable imesh. Since there are only two meshes in the composite mesh, all points are either blue (wing) or red (store). Since the mesh in this examle is so coarse, the hole cuts tend to be more ragged than with finer meshes, and likewise the contours not as smooth as with finer meshes..