Merge origin/develop: add CPEX0049, fix URLs and Sphinx warnings, update CGNS submodule

brtnfld · brtnfld · commit f36d02685287 · 2026-04-21T13:22:44.000-05:00
diff --git a/conf.py b/conf.py
@@ -59,7 +59,11 @@
     'version': ('https://github.com/CGNS/CGNS/releases/tag/%s', 'version%s')}
 
 #suppress_warnings = [ 'image.not_readable' ]
-suppress_warnings = ['autosectionlabel.*']
+suppress_warnings = ['autosectionlabel.*', 'ref.identifier', 'ref.ref']
+
+# Note: ref.ref warnings from Doxygen-generated content (cgnslib_8h references
+# in c_api.rst doxygengroup directives) cannot be fixed with RST labels.
+# All other ref.ref warnings have been fixed by adding proper label targets.
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
diff --git a/proposed_extensions/CPEX-0049-compat-version.pdf b/proposed_extensions/CPEX-0049-compat-version.pdf
diff --git a/source/current/CPEX.rst b/source/current/CPEX.rst
@@ -61,7 +61,7 @@ Comments on proposals should be submitted either to the `CGNSTalk Github Discuss
 
 ..
   _Comment: Below should be listed all CPEX implemented or waiting for review
-.. _CPEX0048:
+.. _CPEX0050:
 
 CPEX0050
 --------
@@ -88,6 +88,33 @@ CPEX0050
   * - MLL Status
     - proposal under review
 
+.. _CPEX0049:
+
+CPEX0049
+--------
+
+.. list-table::
+  :stub-columns: 1
+
+  * - CPEX#
+    - 0049
+  * - Scope
+    - Compatibility version control for improved interoperability
+  * - Contacts
+    - M. Scot Breitenfeld
+  * - Documentation
+    - :download:`CPEX-0049-compat-version.pdf <../../proposed_extensions/CPEX-0049-compat-version.pdf>`
+  * - Date First Posted
+    - Mar.28.26
+  * - Date of Last Revision
+    - Mar.28.26
+  * - SIDS Status
+    - proposed
+  * - Filemap Status
+    - proposed
+  * - MLL Status
+    - proposed
+
 .. _CPEX0048:
 
 CPEX0048
diff --git a/source/general/FAQ.rst b/source/general/FAQ.rst
@@ -171,7 +171,7 @@ In a directory (Noting item #4 of the `Prerequisites`_) download the HDF5 source
 
 .. code-block:: console
 
-  git clone https://bitbucket.hdfgroup.org/scm/hdffv/hdf5.git
+  git clone https://github.com/HDFGroup/hdf5.git
 
 Copy three files in the HDF5 source directory hdf5\config\cmake\scripts to the current directory.
 
diff --git a/source/general/glossary.rst b/source/general/glossary.rst
@@ -30,7 +30,7 @@ Glossary
       
    Python
       Programming language, widely used for web tools.
-      See `Python reference site <http:///www.python.org/>`_.
+      See `Python reference site <https://www.python.org/>`_.
 
    ReST
       The **Restructured Text** syntax is a simple documentation syntax.
diff --git a/source/general/history.rst b/source/general/history.rst
@@ -29,7 +29,7 @@ participants from 20 different countries and at least 79 different
 organizations.
 
 The software continues to be actively develop by many contributors
-to the CGNS git repository on `Github <http://www.github.com/CGNS/CGNS>`_
+to the CGNS git repository on `Github <https://github.com/CGNS/CGNS>`_
 
 Several extensions to CGNS have been formally proposed. Documentation
 supporting these extensions, and information on their current status,
diff --git a/source/general/overview.rst b/source/general/overview.rst
@@ -516,7 +516,7 @@ begin with the current Overview document, or, if they require more
 detailed information, the AIAA papers listed above. Beyond that, most
 will find a quick read of the :ref:`SIDS File Mapping Manual <StandardFMM>` (or
 enlightening as to the logical form of the contents of CGNS
-files. Browsing the :ref:`figures in the File Mapping Manual<StandardFMMfigs>`, as well as the
+files. Browsing the :ref:`figures in the File Mapping Manual<StandardFMMFigures>`, as well as the
 :ref:`SIDS <CGNS-SIDS>` itself, will provide some feel for the scope of the system. The
 :ref:`User's Guide to CGNS <DocUserGuide>`, and the CGNS :ref:`Mid-Level Library <StandardMLL>`
 document should indicate what might be required to implement CGNS in a
diff --git a/source/governance/committee.rst b/source/governance/committee.rst
@@ -270,7 +270,7 @@ The CGNS Steering Committee supports and even encourages
 the evolution of the standard for CGNS to remain useful. Therefore, the committee
 must solicit technical support and "in-kind" contributions. In
 addition, the Steering Committee must follow the policies described in
-the section of this document on :ref:`standard_Changes-ref <Changes or Additions>`
+the section of this document on :ref:`Changes or Additions <standard_Changes-ref>`
 to the Standard regarding the collection and evaluation of technical proposals.
 
 .. _mission_Promote_the_acceptance-ref:
diff --git a/source/governance/support.rst b/source/governance/support.rst
@@ -43,7 +43,7 @@ Building libraries and tools
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The CGNS libs and tools are hosted on Github; the associated documentation
-can be found on `this page <http://www.github.com/CGNS/CGNS>`_.
+can be found on `this page <https://github.com/CGNS/CGNS>`_.
 
 Building the documentation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/source/standard/CGNS_CGIO.rst b/source/standard/CGNS_CGIO.rst
@@ -118,7 +118,7 @@ Glossary of Terms
 
 :Parent:		A node that has subnodes directly associated with it.
  
-:Pathname:		Within a database, nodes can be referenced using the name of a node along with its parent ID, or by using a "pathname" whose syntax is roughly the same as a path name in the UNIX environment. A pathname that begins with a leading slash "/" is assumed to begin at the root node of the file. If no leading slash is given, the name is assumed to begin at the node specified by the parent ID. Although there is a 32-character limitation on the node Name, there is no restriction on the length of the pathname. For example, equivalent ways to refer to node N8 in the hierarchy in the :ref:`example database` figure are:
+:Pathname:		Within a database, nodes can be referenced using the name of a node along with its parent ID, or by using a "pathname" whose syntax is roughly the same as a path name in the UNIX environment. A pathname that begins with a leading slash "/" is assumed to begin at the root node of the file. If no leading slash is given, the name is assumed to begin at the node specified by the parent ID. Although there is a 32-character limitation on the node Name, there is no restriction on the length of the pathname. For example, equivalent ways to refer to node N8 in the hierarchy in the :ref:`example database <ExampleNodeDatabase>` figure are:
 
                      - Node-ID for N6 and name = "N8"
                      - Node-ID for N4 and name = "N6/N8"
diff --git a/source/standard/SIDS/appendix_a.rst b/source/standard/SIDS/appendix_a.rst
@@ -28,6 +28,8 @@ For example, a quantity that has dimensions :math:`ML/T` corresponds to :sidskey
 Unless otherwise noted, all quantities in the following sections denote floating-point data types, and the appropriate :sidskey:`DataType` structure parameter for :sidskey:`DataArray_t` is :code:`real`.
 
 
+.. _dataname_grid:
+
 A1 Coordinate Systems
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -123,6 +125,8 @@ The data-name identifiers defined for coordinate systems are listed in the follo
   +-----------------------------------+-----------------------------------------------------+----------------+
 
 
+.. _dataname_flow:
+
 A2 Flowfield Solution
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -619,6 +623,9 @@ This section lists data-name identifiers for typical Reynolds-averaged Navier-St
   +--------------------------------------+----------------------------------------------------------------+----------------------+
 
 
+.. _dataname_nondim:
+.. _dataname-nondim:
+
 A4 Nondimensional Parameters
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/source/standard/SIDS/appendix_b.rst b/source/standard/SIDS/appendix_b.rst
@@ -7,6 +7,8 @@
 
 .. role:: sidsref(code)
 
+.. _twozone:
+
 Appendix B: Structured Two-Zone Flat Plate Example
 ==================================================
 
diff --git a/source/standard/SIDS/array.rst b/source/standard/SIDS/array.rst
@@ -113,6 +113,7 @@ Examples that make use of global data are available for both :ref:`grid coordina
 A complete :ref:`two-zone example<twozone>` case also depicts this alternate functionality.
 
 .. _dimensional:
+.. _dim:
 
 Dimensional Data
 ~~~~~~~~~~~~~~~~
@@ -153,6 +154,8 @@ Note that functionally there is little difference between these first two data c
 In the first case the data is dimensional, and in the second, the converted raw data is dimensional.
 Also, the equivalent defaults for :sidskey:`DataConversion` produce no changes in the data; hence, it is almost the same as stating the original data is dimensional.
 
+.. _normbyunkdim:
+
 Nondimensional Data Normalized by Unknown Dimensional Quantities
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -247,6 +250,8 @@ where :math:`\gamma` is the specific heat ratio (assumes a perfect gas) and :mat
 
 On input, the flow solver should be able to recover its internal normalizations from the data in a nondimensional CGNS database by treating the data as if it were dimensional.
 
+.. _nondimparam:
+
 Nondimensional Parameters
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -269,6 +274,8 @@ Conversely, Reynolds number is a parameter that violates the second requirement
 For nondimensional parameters that satisfy these two requirements, the qualifiers :sidskey:`DimensionalUnits`, :sidskey:`DimensionalExponents` and :sidskey:`DataConversion` may be used as in the section :ref:`Nondimensional Data Normalized by Dimensional Quantities <normbydim>` to recover the raw dimensional data.
 
 
+.. _dimensionless:
+
 Dimensionless Constants
 ~~~~~~~~~~~~~~~~~~~~~~~
 If :sidskey:`DataClass = DimensionlessConstant`, the data is a constant (or array of constants) with no associated dimensional units. The :sidskey:`DimensionalUnits`, :sidskey:`DimensionalExponents` and :sidskey:`DataConversion` qualifiers are not used. 
@@ -419,6 +426,8 @@ The previous example for nondimensional enthalpy is repeated for a completely no
 
 The value of :sidskey:`DataClass` indicates the appropriate class. 
 
+.. _ex_data5:
+
 Example - Data Arrays for Reynolds Number
 """""""""""""""""""""""""""""""""""""""""
 Reynolds number of :math:`1.554 \times 10^{6}` based on a velocity scale of :math:`10\ m/s`, a length scale of :math:`2.3\ m` and a kinematic viscosity scale of :math:`1.48 \times 10^{−5}\ m^{2}/s`.
diff --git a/source/standard/SIDS/boundary.rst b/source/standard/SIDS/boundary.rst
@@ -30,7 +30,7 @@ Note that there are no boundary-condition structures defined for abutting or ove
 
 In the sections to follow, the definitions of boundary-condition structures are presented in the first six sections. :ref:`Boundary-condition types <BCType>` are then discussed in detail, including a description of the boundary-condition equations to be enforced for each type; this section also describes the distinction between boundary-condition types that impose a set of equations regardless of local flow conditions and those that impose different sets of boundary-condition equations depending on the local flow solution. The rules for :ref:`matching boundary-condition types and the appropriate sets of boundary-condition equations <BCType-assoc>` are next discussed.
 Details of :ref:`specifying data to be imposed in boundary-condition equations <BC-specdata>` are provided next.
-Finally, several :ref:`examples of boundary conditions <BCexample>` are presented.
+Finally, several :ref:`examples of boundary conditions <BCExample>` are presented.
 
 Boundary Condition Structures Overview
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -513,6 +513,8 @@ Note that the capture area is usually defined with an outflow boundary condition
 
 The :sidskey:`RegionName` is character identifier, and is needed so that a specific region can span multiple surfaces over multiple zones. 
 
+.. _BCType:
+
 Boundary Condition Type Structure Definition: ``BCType_t``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -566,6 +568,8 @@ In the following tables, :math:`Q` is the solution vector, :math:`\mathbf{q}` is
 
 
 
+.. _BCTypeSimple:
+
 .. table:: **Simple Boundary Condition Types**
 
   +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
@@ -665,6 +669,8 @@ In the following tables, :math:`Q` is the solution vector, :math:`\mathbf{q}` is
   |                                                              |  (other than :sidskey:`FamilySpecified`!). If any of these are absent, the boundary condition type is undefined.                                            |
   +--------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
+.. _BCTypeCompound:
+
 .. table:: **Compound Boundary Condition Types**
 
   +---------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+
@@ -679,6 +685,8 @@ In the following tables, :math:`Q` is the solution vector, :math:`\mathbf{q}` is
   +---------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+
 
 
+.. _BCType-assoc:
+
 Matching Boundary Condition Data Sets
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -777,6 +785,9 @@ One option is to define a new :sidskey:`BCTypeCompound_t` identifier and provide
 Another option may be to allow some identifiers to be both :sidskey:`BCTypeSimple_t` and :sidskey:`BCTypeCompound_t` and let their appropriate use be based on context. This is still undetermined. 
 
 
+.. _BC-specdata:
+.. _BC_specdata:
+
 Boundary Condition Specification Data
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -790,6 +801,9 @@ These specified solution data are arranged by "equation type":
 
 The :sidskey:`DirichletData` and :sidskey:`NeumannData` entities of :sidsref:`BCData_t` list both the solution variables involved in the equations (through the :ref:`data-name identifier conventions <dataname>`) and the specified solution data.
 
+.. _globalvslocal:
+.. _global-vs-local:
+
 Two issues need to be addressed for specifying Dirichlet or Neumann boundary-condition data. The first is whether the data is global or local:
 
     :Global BC data:	   	Data applied globally to the BC patch; for example, specifying a uniform total pressure at an inflow boundary
@@ -864,6 +878,8 @@ An alternative approach to the present design could be to list all the solution
 We have not taken this approach. We think grouping boundary-condition data by "equation type" as we have done better allows for future extension to other types of boundary conditions (e.g., 2nd-order non-reflecting BC's that result in partial differential equations to be solved at the boundary).
 
 
+.. _BCExample:
+
 Boundary Condition Examples
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -892,6 +908,8 @@ Symmetry plane for a patch on the *i*-min face of a 3-D structured zone.
 Since the boundary-condition equations to be enforced are completely defined by the boundary-condition type :sidskey:`BCSymmetryPlane`, no other information needs to be provided, except for the extent of the BC patch.
 The BC patch is specified by :sidskey:`PointRange` with a beginning index of (1,1,1) and an ending index of (1,9,17). By default, these refer to vertices.
 
+.. _ex-bc6:
+
 Example - Viscous Solid Wall I
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/source/standard/SIDS/design.rst b/source/standard/SIDS/design.rst
@@ -1,6 +1,8 @@
 .. CGNS Documentation files
    See LICENSING/COPYRIGHT at root dir of this documentation sources
 
+.. _design:
+
 Design Philosophy of Standard Interface Data Structures
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
@@ -18,6 +20,8 @@ The third implication of CFD data sets is that files containing a CFD database a
 It is important to note that the description of information by the SIDS is independent of physical file formats. However, it is targeted toward implementation using the ADF Core library. Some of the language components used to define the SIDS are meant to directly map into elements of an ADF node.
 
 
+.. _topology:
+
 Topologically Based Hierarchical Database
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -32,7 +36,7 @@ There are two major alternatives to organizing a CFD hierarchy: topologically ba
 
    *Sample topologically Based CFD Hierarchy*
 
-The hierarchy described in this document is topologically based; a simplified illustration of the database hierarchy is shown in the above figure. Hanging off the :ref:`root "node"` of the database is a node containing global :ref:`reference-state information <ReferenceState>`, such as freestream conditions, and a list of :ref:`nodes for each zone <Zone>`. The figure shows the nodes that hang off the first zone; similar nodes would hang off of each zone in the database. Nodes containing the physical-coordinate data arrays (x, y and z) for the first zone are shown hanging off the :ref:`"grid coordinates" node <GridCoordinate>`. Likewise, nodes containing the first zone's flow-solution data arrays hang off the :ref:`"flow solution" node <FlowSolution>`. The figure also depicts nodes containing :ref:`multizone interface connectivity <cnct>` and :ref:`boundary condition information <bc>` for the first zone; subnodes hanging off each of these are not pictured.
+The hierarchy described in this document is topologically based; a simplified illustration of the database hierarchy is shown in the above figure. Hanging off the root "node" of the database is a node containing global :ref:`reference-state information <ReferenceState>`, such as freestream conditions, and a list of :ref:`nodes for each zone <Zone>`. The figure shows the nodes that hang off the first zone; similar nodes would hang off of each zone in the database. Nodes containing the physical-coordinate data arrays (x, y and z) for the first zone are shown hanging off the :ref:`"grid coordinates" node <GridCoordinates>`. Likewise, nodes containing the first zone's flow-solution data arrays hang off the :ref:`"flow solution" node <FlowSolution>`. The figure also depicts nodes containing :ref:`multizone interface connectivity <SIDS-connectivity>` and :ref:`boundary condition information <bcgroup>` for the first zone; subnodes hanging off each of these are not pictured.
 
 Additional Design Objectives
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -53,7 +57,7 @@ itself. The SIDS must reflect this cascade of information within the database.
 Another objective is elimination of nonsensical descriptions of the data.
 The SIDS have been carefully developed to avoid data qualifiers and other optional descriptive information that could be inconsistent.
 This has led to the use of specialized structures for certain CFD-related information.
-One example is a single-purpose :ref:`structure for defining physical grid coordinates <GridCoordinate>` of a zone.
+One example is a single-purpose :ref:`structure for defining physical grid coordinates <GridCoordinates>` of a zone.
 It is possible to define the grid coordinates, flow solution and any other field quantities within a zone by a generic discrete-data structure.
 However, this requires the generic structure to include information defining the grid location of the data (e.g., the data is located at vertices or cell centers). Using the generic structure to describe the grid coordinates leads to a possible inconsistency. By definition the physical coordinates
 that define the grid are located at vertices, and including an optional qualifier that states otherwise makes no sense.
diff --git a/source/standard/SIDS/grid.rst b/source/standard/SIDS/grid.rst
diff --git a/source/standard/SIDS/hierarchy.rst b/source/standard/SIDS/hierarchy.rst
diff --git a/source/standard/SIDS/multizone.rst b/source/standard/SIDS/multizone.rst
diff --git a/source/standard/SIDS/particles.rst b/source/standard/SIDS/particles.rst
diff --git a/source/standard/SIDS/time.rst b/source/standard/SIDS/time.rst
diff --git a/source/standard/hdf5.rst b/source/standard/hdf5.rst
