Update gh pages

docs/Grid.html

@@ -406,16 +406,24 @@ <h3>Implementing Boundary Conditions<a class="headerlink" href="#implementing-bo
 <section id="uniform-grid">
 <span id="sec-grid-ug"></span><h2>Uniform Grid<a class="headerlink" href="#uniform-grid" title="Link to this heading"></a></h2>
 <p>The Uniform Grid has the same resolution in all the blocks throughout
-the domain, and each processor has exactly one block. The uniform grid
+the domain, and each processor has exactly one block.</p>
+<div class="flashtip docutils container">
+<p>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.</p>
+block size version uses dynamic memory allocation of grid variables.
+Flash-X currently only supports the Uniform Grid in NONFIXEDBLOCKSIZE
+mode (whereas the other Grid implementations in Flash-X operate in
+FIXEDBLOCKSIZE mode).</p>
+</div>
 <section id="fixedblocksize-mode">
 <h3>FIXEDBLOCKSIZE Mode<a class="headerlink" href="#fixedblocksize-mode" title="Link to this heading"></a></h3>
+<p>NOTE THAT THIS MODE IS CURRENTLY NOT IMPLEMENTED IN Flash-X. The remainder
+of this section thus is only for historical information.</p>
 <p><em>FIXEDBLOCKSIZE</em> 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<span class="math notranslate nohighlight">\(\times\)</span>NYB<span class="math notranslate nohighlight">\(\times\)</span>NZB. These
 variables default to <span class="math notranslate nohighlight">\(8\)</span> if the dimension is defined and <span class="math notranslate nohighlight">\(1\)</span>
 otherwise – <em>e.g.</em> for a two-dimensional simulation, the defaults are

docs/_sources/Grid.rst.txt

@@ -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

docs/_sources/application_use.rst.txt

@@ -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

docs/_sources/disclaimers.rst.txt

@@ -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 |
 +---------------+--------------------------+----------------+

docs/_sources/intro.rst.txt

@@ -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|. 

docs/_sources/namingConventions.rst.txt

@@ -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

docs/_sources/quickstart.rst.txt

@@ -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
 -------------------

docs/application_use.html

@@ -94,7 +94,7 @@
 
   <section id="application-s-use-of-orcha">
 <span id="chp-application-use"></span><h1>Application’s Use of Orcha<a class="headerlink" href="#application-s-use-of-orcha" title="Link to this heading"></a></h1>
-<p>In this section we desribe the end-to-end pipeline of how an
+<p>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

docs/disclaimers.html

@@ -105,7 +105,7 @@
 <p><strong>Infrastructure</strong></p>
 <table class="docutils align-default">
 <tbody>
-<tr class="row-odd"><td><p>Setup too</p></td>
+<tr class="row-odd"><td><p>Setup tool</p></td>
 <td><p>Klaus Weide/Younjun Lee</p></td>
 <td><p>mostly current</p></td>
 </tr>

docs/intro.html

@@ -86,34 +86,34 @@
 
   <section id="introduction">
 <span id="sec-introduction"></span><h1>Introduction<a class="headerlink" href="#introduction" title="Link to this heading"></a></h1>
-<p>The Flash-X 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
+<p>The Flash-X 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++. Flash-X 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. Flash-X 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 Flash-X.</p>
 <p>The precursor of  Flash-X is FLASH, which was developed at the
 University of Chicago, and is now available from University of
 Rochester.  Flash-X 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  Flash-X, however, the code itself has transitioned to open
+migrated to Flash-X. However, the code that is now part of Flash-X 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 Flash-X.</p>
 </section>
 

docs/namingConventions.html

@@ -116,7 +116,7 @@
 remaining part of the name is lowercase and all subsequent words are
 capitalized. For example, Grid_fillGuardcells, Driver_getDt} etc</p>
 </dd>
-<dt><strong>Private UnitMain funtions</strong></dt><dd><p>The private functions are named un_routineName, where <em>un</em> stands for
+<dt><strong>Private UnitMain functions</strong></dt><dd><p>The private functions are named un_routineName, where <em>un</em> 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
 subunit.</p>

docs/quickstart.html

@@ -94,7 +94,7 @@
 <span id="chp-quickstart"></span><h1>Quick Start<a class="headerlink" href="#quick-start" title="Link to this heading"></a></h1>
 <p>This chapter describes how to get up-and-running quickly with Flash-X
 with an example simulation, the Sedov explosion. We explain how to
-configure a problem, build it, run it, and examine the output using IDL.</p>
+configure a problem, build it, run it, and examine the output.</p>
 <section id="system-requirements">
 <h2>System requirements<a class="headerlink" href="#system-requirements" title="Link to this heading"></a></h2>
 <p>You should verify that you have the following:</p>