accert-dev · JiaZhou-PU · May 11, 2026 · May 12, 2026 · May 12, 2026 · May 12, 2026
diff --git a/.gitignore b/.gitignore
@@ -5,4 +5,10 @@
 **/sonvalidxml
 **/.DS_Store
 **/*.out
-**/install.conf
+**/install.conf
+docs/build/
+docs/source/reference/main.rst
+docs/source/reference/main/
+docs/source/reference/utility/
+docs/source/reference/database.rst
+docs/source/reference/database/
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -36,9 +36,9 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
      - `cost_1987`
    - These changes streamline the database structure, removing unnecessary complexity.
 
- **Stored Procedure Usage**:
-   - Removed previous usage of the `execute` method in the Python MySQL connector. The system now exclusively uses stored procedures for database interactions, ensuring consistency and improved performance.
-   - Removed redundant stored procedures to streamline database operations and eliminate outdated or unnecessary functionality.
+ **Database Procedure Usage**:
+   - Consolidated database interactions through named database procedures for consistency and maintainability.
+   - Removed redundant database procedures to streamline operations and eliminate outdated or unnecessary functionality.
 ### Added 
  **Fusion Model Addition**: 
    - A new fusion model has been integrated into ACCERT to extend its functionality and coverage for fusion-related cost assessments.
@@ -68,4 +68,4 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 * ACCERT relational database
 * PWR-12BE case
 * ABR1000 case
-* initial documentation
+* initial documentation
diff --git a/README.md b/README.md
@@ -18,11 +18,11 @@ The software comprises three major components:
 
 ACCERT is designed for integration with the [NEAMS
 Workbench](https://www.ornl.gov/project/neams-workbench) and relies on input
-files using Workbench's SON format. Instructions for installing ACCERT both
+files using Workbench's SON format. ACCERT uses the bundled SQLite database at
+`src/accertdb.sqlite`. Instructions for installing ACCERT both
 with and without Workbench are provided in this README.
 
 ## Documentation
 
 Documentation for ACCERT can be found
 [__here__](https://accert.readthedocs.io/en/latest/index.html).
-
diff --git a/docs/make.bat b/docs/make.bat
@@ -25,8 +25,8 @@ if errorlevel 9009 (
 	exit /b 1
 )
 
-REM Define pre-build scripts
-set PRE_BUILD_SCRIPTS=generate_sp_docs.py generate_main_docs.py
+REM Define pre-build scripts
+set PRE_BUILD_SCRIPTS=source\generate_sp_docs.py source\generate_autorst.py
 
 REM Define build command based on the first argument
 if "%1" == "" goto help

diff --git a/docs/source/dev/release.rst b/docs/source/dev/release.rst
@@ -30,7 +30,7 @@ New Features
 4. **Improved Scalability and Maintainability**:
 
    - Removed redundant tables and columns from the database, simplifying its structure.
-   - Redundant stored procedures have been eliminated to streamline database operations.
+   - Redundant database procedures have been eliminated to streamline database operations.
    - Fusion-related algorithms are now separate from the main database, housed in Python files for easier updates.
 
 5. **Refactored Algorithm Storage**:
@@ -59,14 +59,14 @@ Bug Fixes
 Performance Enhancements
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-- **Stored Procedure Usage**:
+- **Database Procedure Usage**:
 
-  - Replaced instances of the `execute` method with stored procedures for database interaction, leading to better performance and more consistent operations.
+  - Consolidated database interactions through named database procedures, leading to more consistent operations.
 
 Version 0.1.0 (04/05/2023)
 --------------------------
 
-`ACCERT relational database <https://github.com/accert-dev/ACCERT/blob/main/src/accertdb.sql>`_
+`ACCERT relational database <https://github.com/accert-dev/ACCERT/blob/main/src/accertdb.sqlite>`_
 
 `PWR-12BE case <https://github.com/accert-dev/ACCERT/blob/main/tutorial/PWR12-BE.son>`_
 
@@ -84,4 +84,3 @@ New Features
 - **Hierarchical Structure**: COAs are organized across multiple levels (typically between 0-5), decomposing complex systems into manageable components and subtasks.
 - **Installation automating**: Provides a script to automate the installation process.
 
-
diff --git a/docs/source/dev/styleguide.rst b/docs/source/dev/styleguide.rst
@@ -3,7 +3,7 @@
 Style Guide
 -----------
 
-ACCERT is written in **Python 3** and **MySQL 8**. 
+ACCERT is written in **Python 3** and uses **SQLite** for the bundled database.
 
 Style for Python code should follow `PEP 8`_.
 
@@ -19,24 +19,8 @@ Python code should work with all currently `supported versions`_ of Python.
 .. _os: https://docs.python.org/3/library/os.html
 .. _Path: https://docs.python.org/3/library/pathlib.html#pathlib.Path
 
-Style for MySQL code should follow Google coding style
-
-New MySQL code uses the `Google C++ coding style <https://google.github.io/styleguide/cppguide.html>`_, with two exceptions:
-
-Member variable names: Do not use `foo_.` Instead, use `m_foo` (non-static) or `s_foo` (static).
-Old projects and modifications to old code use an older MySQL-specific style for the time being. Since 8.0, MySQL style uses the same formatting rules as Google coding style (e.g., brace placement, indentation, line lengths, etc.), but differs in a few important aspects:
-
-Class names: Do not use MyClass. Instead, use My_class.
-
-Function names: Use snake_case().
-
-Comment Style: Use either the // or /* */ syntax. // is much more common but both syntaxes are permitted for the time being.
-Doxygen comments: Use /** ... */ syntax and not ///.
-
-Doxygen commands: Use '@' and not '\' for doxygen commands.
-
-You may see structs starting with st_ and being typedef-ed to some UPPERCASE (e.g. typedef struct st_foo { ... } FOO). However, this is legacy from when the codebase contained C. Do not make such new typedefs nor structs with st_ prefixes, and feel free to remove those that already exist, except in public header files that are part of libmysql (which need to be parseable as C99).
-
-Code formatting is enforced by use of clang-format throughout the code base. However, note that formatting is only one part of coding style; you are required to take care of non-formatting issues yourself, such as following naming conventions, having clear ownership of code or minimizing the use of macros. See the Google coding style guide for the entire list.
+SQLite procedure logic lives in ``src/accert_sqlite_procedures.py``. New
+database code should use parameterized queries for values and validate table or
+column identifiers before interpolation.
 
 Consistent style is important for us, because everyone must know what to expect. Knowing our rules, you'll find it easier to read our code, and when you decide to contribute (which we hope you'll consider!) we'll find it easier to read and review your code.
diff --git a/docs/source/examples/ap1000.rst b/docs/source/examples/ap1000.rst
@@ -0,0 +1,88 @@
+AP1000
+======
+
+The AP1000 ACCERT example is in ``tutorial/accert/AP1000.son``. It uses the
+AP1000 reference table family, which follows the TIMCAT direct-cost table
+structure and is scaled to a 2234 MWe two-unit AP1000 case.
+
+The AP1000 and LPSR direct-cost basis follows Stewart W.R. and Shirvan K.,
+"Capital cost estimation for advanced nuclear power plants," *Renewable and
+Sustainable Energy Reviews*, Nov. 2021, 111880,
+https://doi.org/10.1016/j.rser.2021.111880, and the TIMCAT reference
+implementation at https://github.com/mit-crpg/TIMCAT.
+
+.. code-block:: son
+
+   accert{
+       ref_model = "AP1000"
+       use_gncoa = False
+
+       post_process {
+           occ = true
+       }
+
+       power(Thermal){
+           value = 6800
+           unit = MW
+       }
+
+       power(Electric){
+           value = 2234
+           unit = MW
+       }
+   }
+
+The AP1000 direct-account total is represented by account ``2`` and is
+``6,673,722,963.402768`` in 2018 dollars. ACCERT prints account-review tables
+in 2024 dollars using CPI-U escalation, and the generated CSV files retain the
+reference-year cost columns with additional ``*_2024`` columns.
+
+Running the Example
+-------------------
+
+Run from the ACCERT repository root:
+
+.. code-block:: bash
+
+   python src/Main.py -i tutorial/accert/AP1000.son
+
+ACCERT writes timestamped CSV outputs such as ``ap1000_upd_acc_*.csv``,
+``ap1000_upd_ce_*.csv``, and ``ap1000_post_*.csv`` in the current working
+directory.
+
+Using AP1000 Output in CRF or IAT
+---------------------------------
+
+To use the AP1000 ACCERT output as a CRF or IAT baseline, convert the
+``ap1000_upd_acc_*.csv`` file with ``accert_output_to_crf_baseline`` and provide
+the total 20s labor hours that should be assigned to the case:
+
+.. code-block:: python
+
+   from crf import accert_output_to_crf_baseline
+
+   accert_output_to_crf_baseline(
+       "ap1000_upd_acc_20260518_215922.csv",
+       "ap1000_accert_for_crf_iat.csv",
+       reactor_type="AP1000",
+       total_20s_labor_hours=28_902_455.46,
+   )
+
+The converter keeps ACCERT direct-account costs and uses the selected CRF base
+case, such as AP1000, SFR, or HTGR, to distribute factory cost, material cost,
+labor cost, and labor-hour proportions. The converted CSV can be passed to CRF
+with ``config["baseline_csv"]`` or to IAT with ``input_csv``. For the current
+AP1000 CRF base case, use ``construction_duration_0 = 76`` months in the CRF
+configuration.
+
+The AP1000 bridge maps ACCERT accounts to CRF/IAT accounts as follows:
+``211`` to ``211``, ``212`` to ``212``, ``213`` to ``213``, ``214`` to ``216``,
+``215`` to ``214``, ``216`` to ``215``, ``217`` and ``218A`` through ``218V``
+to ``214``, ``22`` to ``22``, ``23`` to ``232.1``, ``24`` to ``24``, ``25`` to
+``26``, and ``26`` to ``233``.
+
+The full workflow is available in:
+
+.. code-block:: bash
+
+   python tutorial/combined/accert_output_to_crf_iat_example.py
diff --git a/docs/source/examples/index.rst b/docs/source/examples/index.rst
@@ -3,7 +3,7 @@
 Example
 ======================
 
-This document provides a comprehensive explanation of the ACCERT running examples, including the **PWR12-BE**, **ABR1000**, and **Fusion** reactor models. It integrates key ACCERT concepts to elucidate how the input files are structured and why they are designed in a particular manner.
+This document provides a comprehensive explanation of the ACCERT running examples, including the **PWR12-BE**, **ABR1000**, **AP1000**, and **Fusion** reactor models. It integrates key ACCERT concepts to elucidate how the input files are structured and why they are designed in a particular manner.
 
 
 
@@ -13,5 +13,6 @@ This document provides a comprehensive explanation of the ACCERT running example
 
    pwr12-be
    abr1000
+   ap1000
    fusion
-   stellarator
+   stellarator
diff --git a/docs/source/examples/stellarator.rst b/docs/source/examples/stellarator.rst
@@ -10,8 +10,8 @@ variables, and LCOE evaluation, the algorithms are leveraged from UKAEA's `PROCE
 Prerequisites
 --------------
 
-- ACCERT installation (see :doc:`Installation Guide <install>`).
-- MySQL database initialized with the updated schema containing the *stellarator* algorithms and variables.
+- ACCERT installation (see :doc:`Installation Guide <../user/install>`).
+- SQLite database initialized with the updated schema containing the *stellarator* algorithms and variables.
 - ACCERT main branch after PR #47.
 
 New Features
@@ -26,7 +26,7 @@ General Input Structure
 
 The input file for the stellarator model is located at ``accert/tutorial/accert/stellarator.son``.
 
-.. code-block:: json
+.. code-block:: text
 
    accert{
        ref_model = "stellarator"
@@ -65,5 +65,3 @@ The output will be generated in the ``tutorial/accert`` directory, as ``output.o
 
 - **stellarator_updated_account.xlsx**: Contains the updated cost breakdown for the stellarator model.
 - **stellarator_LCOE_results.xlsx**: Contains the LCOE analysis results specific to the stellarator configuration.
-
-