Flash-X · kweide · Jul 8, 2024 · Jul 6, 2024 · Jul 7, 2024
diff --git a/sphinx/source/Grid.rst b/sphinx/source/Grid.rst
@@ -404,18 +404,28 @@ Uniform Grid
 ------------
 
 The Uniform Grid has the same resolution in all the blocks throughout
-the domain, and each processor has exactly one block. The uniform grid
-can operate in either of two modes: fixed block size (FIXEDBLOCKSIZE)
-mode, and non-fixed block size (NONFIXEDBLOCKSIZE) mode. The default
-fixed block size grid is statically defined at compile time and can
-therefore take advantage of compile-time optimizations. The non-fixed
-block size version uses dynamic memory allocation of grid variables.
+the domain, and each processor has exactly one block.
+
+.. container:: flashtip
+
+   In FLASH, the uniform grid
+   can operate in either of two modes: fixed block size (FIXEDBLOCKSIZE)
+   mode, and non-fixed block size (NONFIXEDBLOCKSIZE) mode. The default
+   fixed block size grid is statically defined at compile time and can
+   therefore take advantage of compile-time optimizations. The non-fixed
+   block size version uses dynamic memory allocation of grid variables.
+   |flashx| currently only supports the Uniform Grid in NONFIXEDBLOCKSIZE
+   mode (whereas the other Grid implementations in |flashx| operate in
+   FIXEDBLOCKSIZE mode).
 
 FIXEDBLOCKSIZE Mode
 ~~~~~~~~~~~~~~~~~~~
 
+NOTE THAT THIS MODE IS CURRENTLY NOT IMPLEMENTED IN |flashx|. The remainder
+of this section thus is only for historical information.
+
 *FIXEDBLOCKSIZE* mode, also called static mode, is the default for the
-uniform grid. In this mode, the block size is specified at compile time
+uniform grid in FLASH. In this mode, the block size is specified at compile time
 as NXB\ :math:`\times`\ NYB\ :math:`\times`\ NZB. These
 variables default to :math:`8` if the dimension is defined and :math:`1`
 otherwise – *e.g.* for a two-dimensional simulation, the defaults are

diff --git a/sphinx/source/application_use.rst b/sphinx/source/application_use.rst
@@ -6,7 +6,7 @@
 Application's Use of Orcha
 ======================
 
-In this section we desribe the end-to-end pipeline of how an
+In this section we describe the end-to-end pipeline of how an
 application can use |orcha|. At first glance it may seem intimidating
 because there are several steps involved in the configurations
 process, however, the steps are many fewer in terms of what the users

diff --git a/sphinx/source/disclaimers.rst b/sphinx/source/disclaimers.rst
@@ -27,7 +27,7 @@ are listed in below.
 **Infrastructure**
 
 +---------------+--------------------------+----------------+
-| Setup too     |  Klaus Weide/Younjun Lee | mostly current |  
+| Setup tool    | Klaus Weide/Younjun Lee  | mostly current |
 +---------------+--------------------------+----------------+
 | Grid          | Klaus Weide/Anshu Dubey  | mostly current |
 +---------------+--------------------------+----------------+

diff --git a/sphinx/source/intro.rst b/sphinx/source/intro.rst
@@ -5,33 +5,33 @@
 Introduction
 ============
 
-The |flashx| code is a component-based software system for simulation of
-multiphysics applications formulated largely as a collection of partial-
-and ordinary- differential equations as well as algebraic equations. The
+The |flashx| code is a component-based software system for building
+multiphysics simulation applications that are formulated largely as a collection of partial
+and ordinary differential equations as well as algebraic equations. The
 maintained code components are written in a combination of high level
 languages such as Fortran, C and C++. |flashx| is accompanied by
-several tools written in python or C++ that provide configurability
+several tools written in Python or C++ that provide configurability
 and performance portability to the code. The distribution includes
-several existing application configurations, and tests for exercising
+several existing application configurations and tests for exercising
 these configurations. A unit-test framework is also embedded in the
 code. The code uses the Message-Passing Interface (MPI) library
-communication between nodes, though more than 
+for communication between compute nodes, though more than
 one MPI rank can also be placed on a node. HDF5 is the default mode for
 IO. |flashx| has three interchangeable discretization grids: a Uniform
-Grid, a oct-tree based adaptive grid using the |paramesh|  library, and
+Grid, an oct-tree based adaptive grid using the |paramesh|  library, and
 a block-structured adaptive grid using |amrex| library, which also mimics
 an oct-tree-like layout for use in |flashx|.
 
 The precursor of  |flashx| is FLASH, which was developed at the
 University of Chicago, and is now available from University of
 Rochester.  |flashx| has been architected from the outset to be
 compatible with increasing heterogeneity of both the platforms and the
-solvers within the code. Flash-X distribution
+solvers within the code. The Flash-X distribution
 includes solvers for compressible and incompressible fluids, and several other
 solvers needed for astrophysics and fluid-structure interaction
 applications. Not all physics and/or general solvers from FLASH have been
-migrated to  |flashx|, however, the code itself has transitioned to open
+migrated to |flashx|. However, the code that is now part of |flashx| has transitioned to open
 development and community based governance. The expectation is that
 the code will grow with community contributions. Additionally, some
-external solvers can be included as add-ons in configuration of applications
+external solvers can be included as add-ons in the configuration of applications,
 because those solvers have been designed to be compatible with |flashx|. 
diff --git a/sphinx/source/namingConventions.rst b/sphinx/source/namingConventions.rst
@@ -35,7 +35,7 @@ Naming Conventions
     remaining part of the name is lowercase and all subsequent words are
     capitalized. For example, Grid_fillGuardcells, Driver_getDt} etc
 
-**Private UnitMain funtions**
+**Private UnitMain functions**
     The private functions are named un_routineName, where *un* stands for
     a short string (usually 2 or 3 letters) derived from the unit name.
     For example gr_createDomain is a private function in the GridMain

diff --git a/sphinx/source/quickstart.rst b/sphinx/source/quickstart.rst
@@ -7,7 +7,7 @@ Quick Start
 
 This chapter describes how to get up-and-running quickly with |flashx|
 with an example simulation, the Sedov explosion. We explain how to
-configure a problem, build it, run it, and examine the output using IDL.
+configure a problem, build it, run it, and examine the output.
 
 System requirements
 -------------------