Download Latest Version geomlib.tar.gz (58.3 kB)
Email in envelope

Get an email when there's a new version of CFD Utilities

Home / REFINE_GRID
Name Modified Size InfoDownloads / Week
Parent folder
README 2021-03-22 6.2 kB
refine_grid.f90 2021-03-22 21.6 kB
build 2021-03-22 711 Bytes
densify_grid_block.f90 2020-07-29 21.9 kB
test.inp 2016-09-30 563 Bytes
double.inp 2009-11-24 563 Bytes
2d.inp 2009-11-23 526 Bytes
Totals: 7 Items   52.0 kB 0
REFINE_GRID Description:

   REFINE_GRID densifies all blocks of a multiblock grid the same way, at
   least initially.  If different treatment for different blocks is ever
   needed, we can cross that bridge when we come to it.  For now, use of
   other available utilities may suffice to extract/refine/merge groups of
   blocks appropriately.

   This version handles 2D as well as 3D structured grids.

   If grid densification were limited to integer multiples of the input
   cell counts, treatment of function files could be avoided, since DPLR's
   FCONVERT can perform grid sequencing on solution files.  However, since
   fractional multiples of cell counts are permitted here, the option to
   process function files as well as grid files is provided.

   Any function file should have the same block dimensions and formatting
   as the grid file.  One may choose to work with cell-centered function
   data and corresponding cell-centered grid, but keep in mind that if
   mere doubling of dimensions, say, is all that is required, then a DPLR
   user should be able to employ FCONVERT's options and avoid processing
   function files here.  Processing just a vertex-centered grid with no
   function file is expected to be the most common usage.

   The three index directions are treated independently (possibly with
   different degrees of refinement), meaning it is up to the user to know
   that different treatment will not produce mismatches at common block
   faces.

   Any sensible multiples of the input grid block dimensions (possibly
   non-integer multiples greater or less than 1) may be specified to
   define the output dimensions.  The same scaling applies to all blocks.

   Nothing more than 1-D spline interpolation is provided, multi-dimen-
   sional nonlinear interpolation being unreliable in the author's
   experience.  Indices are treated in the i-j-k order, and each new
   set of interpolations operates on the previous interpolated values.
   This asymmetry may lead to slight mismatches at common faces even if
   the point counts match.  [There are no easy answers here.]

   [Originally:]
   Arc-length-based monotonic Hermite cubic spline interpolation is
   employed as in OUTBOUND's option to adjust the number of radial grid
   points.  (Use OUTBOUND rather than REFINE_GRID if the grid topology
   allows it, and the off-wall direction is the only one of interest.)
   Note that 2nd-derivative continuity at the data points/spline knots is
   NOT guaranteed by such splines, which is likely to introduce noisy
   curvature at geometric surfaces.

   [Currently:}
   Conventional cubic splines are now used for the (x,y,z) coordinates.
   Local cubic splines still suffice for flow solution interpolations.

   For a completely general grid with arbitrary topology, treating all
   index directions identically may be the only safe operation.  For
   cases commonly treated in hypersonic blunt body analysis (single layer
   of grid blocks, with k = 1 at the wall), an OUTBOUND-type option is
   provided, namely preserving the input spacing off the wall rather than
   preserving the existing relative spacing.  Use it with discretion!

Control File Format (on standard input):

   [Note that the formatting of the input grid is determined by this
    program.  For the output result, use *.g/gu and *.f/fuappropriately.]

   REFINE_GRID control file. For output formatting, use *.g or *.gu names.
   my_coarse_grid.gu   ! Input grid name
   my_coarse_f.fu      ! Input function file name, or "none"
   my_refined_grid.gu  ! Output grid name (*.g | *.gu)
   my_refined_f.fu     ! Output function file name (*.f | *.fu | none)
   2 2 1.5             ! si/sj/sk applied to cell counts; may be < 1.
   1 1 2               ! mi/mj/mk: 1 retains relative spacing; 2 keeps ds1
   1. 1. 0.2           ! ds2_frctns (mi=2): ds2i = 1-sided ds2 * ds2_frctn

Procedures:

   XYQ_IO              2D analog of XYZQ_IO
   XYZQ_IO package     I/O utilities for PLOT3D grid and function files
   DENSIFY_GRID_BLOCK  Adjust the number of cells in i/j/k directions
   CHORDS3D            Arc lengths along a 3-space curve
   EXPDIS5             One-sided stretching (Vinokur/geometric hybrid)
   BLGRID              Two-sided stretching (Vinokur)
!! PLSCRV3D            Arc-length-based spline interpolation, 3-space crv.
   CSPLINE             Conventional cubic spline for the grid lines
   LSCFIT              Monotonic Hermite (local) cubic spline for the flow

History:

   11/19/09  D.A.Saunders  Adapted OUTBOUND's radial point count option.
   11/21/09    "     "     Introduced the cspline_module and applied it
                           to the grid coordinates (only) to improve
                           curvature continuity on geometric surfaces.
                           Block boundary effects are still likely.
   11/23/09    "     "     If a scale factor is 2., preserve the odd/
                           evenness of the input dimension.  I.e.,
                           odd n --> 2n - 1, but even n --> 2n for the
                           case of cell-centered data.  If it is 0.5,
                           use of THIN_GRID & THIN_FLOW is recommended.
                           Todd White suggested checking for blocks with
                           negative cell volumes.
   09/29/16    "     "     Aaron Brandis noticed that a scale factor of 4
                           didn't preserve oddness as expected, the way 2
                           does. Therefore, treat all integer multipliers
                           the same way.  Remember, even point counts are
                           still likely for cell-centered data.
   07/28/20    "      "    The algebraic method 1 does not preserve smoothly
                           varying cell spacings.  Introduce the technique of
                           ARBDIS in an attempt to do so.  It seems to work
                           well with the algebraic results as a starting soln.
   09/23/20  Jeff Hill     Updated file handling to support 2D grids.

Author:  David Saunders, ELORET Corporation/NASA Ames Research Center, CA
         Now with AMA, Inc. at NASA ARC.
Source: README, updated 2021-03-22