gitronics 0.5.21__tar.gz → 0.5.22__tar.gz

{gitronics-0.5.21 → gitronics-0.5.22}/Cargo.lock

@@ -390,7 +390,7 @@ dependencies = [
 
 [[package]]
 name = "gitronics"
-version = "0.5.21"
+version = "0.5.22"
 dependencies = [
  "chrono",
  "clap",

{gitronics-0.5.21 → gitronics-0.5.22}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "gitronics"
-version = "0.5.21"
+version = "0.5.22"
 edition = "2024"
 description = "Build MCNP neutronics models from modular components"
 license = "EUPL-1.2"

{gitronics-0.5.21 → gitronics-0.5.22}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: gitronics
-Version: 0.5.21
+Version: 0.5.22
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Classifier: Programming Language :: Python :: Implementation :: PyPy

{gitronics-0.5.21 → gitronics-0.5.22}/docs/getting_started/assessments.md

@@ -1,6 +1,6 @@
 # Assessments
 
-Gitronics can also be used to manage the specific changes required to the model for a specific assessment.
+Gitronics can also be used to manage the specific changes required to a model for a specific assessment.
 The recommended practice is to create a new Git branch for the assessment.
 Then, create a new directory that will contain all the assessment-specific files (e.g. new filler models, tallies, configuration files, etc.).
 This directory could also contain post-processing scripts, organization files and others.
@@ -30,4 +30,4 @@ gitronics_project/
         └── ... 
 ```
 
-After the assessment is complete, the branch can be stored as a file via `git bundle`, and the assessment-specific files can be deleted from the main branch to keep it clean.
+After the assessment is complete, the branch can be stored as a file via `git bundle`, and then deleted from the repository to keep the main branch clean.

{gitronics-0.5.21 → gitronics-0.5.22}/docs/getting_started/building_a_model.md

@@ -1,4 +1,4 @@
-# Build Model
+# Building a Model
 
 Once a configuration file is ready, the model can be built with the `gitronics build` command.
 After the [installation of Gitronics](../installation.md) is complete, the command can be run from the terminal.
@@ -34,10 +34,6 @@ When running the `gitronics build` command, the following steps are performed:
 
 While the build is running, Gitronics will print `INFO` and `WARNING` messages to the terminal indicating the progress of the assembly.
 
-!!! tip "`WARNING` messages"
-    Watch out for `WARNING` messages, they indicate potential mistakes that will not stop the build, for example, the existence of envelope cells in the envelope structure that are not referenced in the configuration file. 
-    If the intention was to leave them empty, it is better to explicitly declare them as `null` in the configuration file to make sure they are not forgotten via `envelope_name: null`.
-
 ??? note "Example of `build` logging"
     ```
     [2026-06-23 14:38:02 INFO gitronics] Starting model build process for: configurations/valid_configuration.yaml
@@ -54,6 +50,10 @@ While the build is running, Gitronics will print `INFO` and `WARNING` messages t
     [2026-06-23 14:38:02 INFO gitronics] Build completed successfully in: output/assembled.mcnp
     ```
 
+!!! tip "`WARNING` messages"
+    Watch out for `WARNING` messages, they indicate potential mistakes that will not stop the build, for example, the existence of envelope cells in the envelope structure file that are not referenced in the configuration. 
+    If the intention was to leave them empty, it is better to explicitly declare them as `null` in the configuration file to make sure they are not forgotten: `envelope_name: null`.
+
 ## Header
 
 The `assembled.mcnp` file will contain a header comment at the top of the file like:
@@ -69,5 +69,5 @@ C ============================================================
 
 The first information line shows the Gitronics version used to build the model.
 The second line shows the configuration file used to build the model, relative to the current working directory.
-The third line shows the Git commit hash of the repository at the time of the build.
-The fourth line shows the date and time when the build was performed.
+The third line shows the Git commit hash of the **Gitronics project** repository at the time of the build.
+The fourth line shows the date and time when the build was performed.

{gitronics-0.5.21 → gitronics-0.5.22}/docs/getting_started/card_id_numbers.md

@@ -1,7 +1,7 @@
 # Card ID numbers
 
 Whenever a file of any type is loaded by Gitronics during a `build` command, Gitronics will copy and paste the cards into a single model.
-If two different files share the same card ID number, for example, two different filler models share a surface, Gitronics will include that surface twice in the assembled model, which will cause a validation error crashing the build process.
+If two different files share the same card ID number, for example, two different filler models sharing a surface, Gitronics will include that surface twice in the assembled model, which will cause a validation error, crashing the build process.
 Gitronics will warn about which card IDs are duplicated with an error message.
 
 [Migjorn](https://github.com/Fusion4Energy/migjorn), the parser used internally by Gitronics, is capable of renumbering on the fly any card ID.

{gitronics-0.5.21 → gitronics-0.5.22}/docs/getting_started/concepts.md

@@ -4,12 +4,12 @@ The following is a list of concepts or keywords that are used throughout the doc
 
 - **Gitronics**. The name of the tool and methodology.
 - **Gitronics project**. A reactor/s or other nuclear project that is managed with the Gitronics methodology.
-- **Git**. A distributed version control system that is used to track changes in the files of a **Gitronics project**.
+- [**Git**](https://git-scm.com/). A distributed version control system that is used to track changes in the files of a **Gitronics project**.
 - **Reference model directory**. A directory containing files that can be used to assemble an MCNP model.
-- **Assembled model**. The output of the `gitronics build` command, a single MCNP input file generated from a **configuration** file and the contents of the **reference model directory**.
-- **Configuration file**. A YAML file that declares which filler models and data cards are used to assemble a model.
+- **Assembled model**. The output of the [`gitronics build`](../usage/build.md) command, a single MCNP input file generated from a [configuration](configuration_file.md) file and the contents of the **reference model directory**.
+- [**Configuration file**](configuration_file.md). A YAML file that declares which filler models and data cards are used to assemble a model.
 - **Envelope structure**. An MCNP input file that defines the *level 0* geometry cells, that is, cells that do not belong to a filler universe. It is the only mandatory file in a Gitronics project.
 - **Envelope cell**. A MCNP cell that can be filled with a filler model. They are defined in the envelope structure file as cells with an inline comment of the form `$ @env:<envelope_name>`, where `<envelope_name>` is the name for the envelope cell.
-- **Filler model**. An MCNP input file that defines a *filler universe*, which is a set of geometry cells that can be inserted into an envelope cell. A filler model must have a metadata file with the same name and the `.metadata` extension.
+- **Filler model**. A MCNP input file that defines a *filler universe*, which is a set of geometry cells that can be inserted into an envelope cell. A filler model must have a metadata file with the same name and the `.metadata` extension.
 - **Data card file**. A file that contains MCNP data cards, such as materials, sources, tallies, transformations or others. These files can have the following extensions: `.mat`, `.source`, `.tally`, or `.transform`.
 - **Metadata file**. A YAML file that contains metadata related to a geometry or data card file. A metadata file must have the same name as the file it describes, but with the `.metadata` extension. These files are optional except for filler models and they can hold any arbitrary information.

{gitronics-0.5.21 → gitronics-0.5.22}/docs/getting_started/configuration_file.md

@@ -1,6 +1,6 @@
 # Configuration file
 
-This is a YAML file that declares which filler models and data cards are used to assemble a model.
+This is a [YAML](https://yaml.org/) file that declares which filler models and data cards are used to assemble a model.
 The configuration file does not need to be in the `reference_model` directory, it can be anywhere in the project.
 For example:
 
@@ -78,13 +78,14 @@ Only one source file can be specified, but any number of materials, transformati
 ### `envelopes`
 
 This field is a dictionary that maps envelope cell names to filler model file stems.
-If an envelope cell name appears in the dictionary but is not found in the envelope structure, Gitronics will raise an error.
+If an envelope cell name appears in the dictionary but is not found in the envelope structure file, Gitronics will raise an error.
 
 ## Overriding other configuration
 
 If a configuration file specifies the `overrides` field, it will inherit from the parent configuration file. The parent is loaded first and the current file is merged on top of it. Fields present in the current file take precedence; the parent provides defaults.
 
 The overriding rules are as follows:
+
 - The field `project_roots` is not inherited, it must be specified in the current configuration file.
 - The fields `envelope_structure`, `source`, `materials`, `transformations`, and `tallies` are inherited, but they can be overridden in the current configuration file. If the current file defines the field, the parent value is ignored.
 - The field `envelopes` is inherited and merged entry-by-entry. The current file can add new envelopes or change specific ones without repeating the full list. If an envelope name is present in both the parent and the current configuration, the current value takes precedence.

{gitronics-0.5.21 → gitronics-0.5.22}/docs/index.md

@@ -2,7 +2,7 @@
 
 **Gitronics** is a tool for assembling [MCNP](https://mcnp.lanl.gov/) neutronics models from modular, version-controlled components.
 
-Instead of maintaining a single monolithic MCNP input file, Gitronics lets you decompose a model into independent universe *filler models*, an *envelope structure*, and separate data cards (materials, sources, tallies, transformations). These components are assembled at build time according to a YAML configuration file.
+Instead of maintaining a single monolithic MCNP input file, Gitronics lets you decompose a model into independent universe *filler models*, an *envelope structure*, and separate data cards (materials, sources, tallies, transformations). These components are assembled at build time according to a [YAML](https://yaml.org/) configuration file.
 
 This workflow enables:
 

{gitronics-0.5.21 → gitronics-0.5.22}/docs/usage/migrate.md

@@ -42,7 +42,7 @@ Each universe found in the model is written to its own `universe_<id>.mcnp` file
 
 ### Metadata files
 
-Each filler model is accompanied by a `.metadata` YAML file. These files describe how the filler should be placed and can specify per-envelope transformation cards. Edit them to add transformations after migration.
+Each filler model is accompanied by a `.metadata` YAML file. These files describe how the filler should be placed and can specify per-envelope transformation cards.
 
 ## Verifying the round-trip
 
@@ -51,13 +51,8 @@ After migration, rebuild the model and verify it matches the original:
 ```bash
 gitronics build tokamak_project/configurations/baseline.yaml \
     --output-path tokamak_project/output
-diff models/tokamak_2025.mcnp tokamak_project/output/assembled.mcnp
 ```
 
-!!! note
-    Minor formatting differences (whitespace, line ordering within a section) are expected. The geometry and physics data should be functionally identical.
-
 ## Limitations
 
 - Data cards (materials, tallies, source) are written to a single `data_cards.source` file. After migration you may wish to split these into separate files under `reference_model/data_cards/`.
-- The migration does not attempt to detect repeated structures or simplify the model.