Add Tally Support ... Finally

.github/workflows/main.yml

@@ -2,9 +2,9 @@ name: CI testing
 
 on: 
   pull_request:
-    branches: ["*dev*", alpha-test*]
+    branches: ["*dev*", "*-test*"]
   push: 
-     branches: ["*dev*", main, alpha-test*]
+     branches: ["*dev*", "main", "*-test*"]
 
 jobs:
   build:

doc/source/_templates/mytallyclass.rst

@@ -0,0 +1,10 @@
+{{ objname }}
+{{ underline }}
+
+.. currentmodule:: {{ module }}
+
+.. autoclass:: {{ objname }}
+    :members:
+    :inherited-members:
+    :undoc-members:
+    :show-inheritance:

doc/source/api/modules.rst

@@ -36,6 +36,7 @@ Collections
    montepy.CommentCollection
    montepy.Materials
    montepy.Surfaces
+   montepy.Tallies
    montepy.Transforms
    montepy.Universes
 
@@ -185,7 +186,78 @@ Materials
    montepy.Nucleus
    montepy.Nuclide
    montepy.ThermalScatteringLaw
-
+
+
+
+Tallies
+^^^^^^^
+
+Tally Objects
+~~~~~~~~~~~~~
+
+.. autosummary::
+   :toctree: generated
+   :nosignatures:
+   :template: mytallyclass.rst
+
+   montepy.Tally
+   montepy.SurfaceTally
+   montepy.CellTally
+   montepy.DetectorTally
+   montepy.SurfaceCurrentTally
+   montepy.SurfaceFluxTally
+   montepy.CellFluxTally
+   montepy.EnergyDepositionTally
+   montepy.FissionEnergyDepositionTally
+   montepy.EnergyDetectorPulseTally
+   montepy.TallyType
+   montepy.Score
+
+Scoring Groups and Filters
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note::
+
+   You will rarely create these directly, rather get them from
+   :attr:`montepy.Tally.groups` and :attr:`montepy.Tally.filters`.
+
+.. autosummary::
+   :toctree: generated
+   :nosignatures:
+   :template: mytallyclass.rst
+
+   montepy.data_inputs.tally.TallyGroup
+   montepy.data_inputs.tally.FlatGroup
+   montepy.data_inputs.tally.PathGroup
+   montepy.data_inputs.tally.LatticeIndex
+   montepy.data_inputs.tally.Filter
+   montepy.data_inputs.tally.ParticleFilter
+   montepy.data_inputs.tally.SpatialFilter
+
+Tally Multipliers
+~~~~~~~~~~~~~~~~~
+
+.. note::
+
+   You will rarely create the ``Multiplier*`` classes directly, rather get
+   them from :attr:`montepy.TallyMultiplier.bins`.
+
+.. autosummary::
+   :toctree: generated
+   :nosignatures:
+   :template: mytallyclass.rst
+
+   montepy.TallyMultiplier
+   montepy.Reaction
+   montepy.data_inputs.tally_multiplier.ReactionExpression
+   montepy.data_inputs.tally_multiplier_type.ReactionOperator
+   montepy.MultiplierSet
+   montepy.SpecialMultiplierSet
+   montepy.SpecialMultiplier
+   montepy.AttenuatorLayer
+   montepy.AttenuatorSet
+   montepy.data_inputs.tally_multiplier.MultiplierScore
+   montepy.data_inputs.tally_multiplier.MultiplierBin
 
 
 Cell Modifiers

doc/source/changelog.rst

@@ -10,6 +10,14 @@ MontePy Changelog
 =============
 
 
+#Next Version#
+--------------
+
+**Features Added**
+
+* Added a :class:`~montepy.Tally`/:class:`~montepy.TallyMultiplier` object model for reading, creating, and editing MCNP tally (``F``) and tally multiplier (``FM``) inputs (:issue:`11`).
+
+
 1.6.0b1
 --------------
 

doc/source/developing.rst

@@ -8,8 +8,8 @@ Developer's Reference
 =====================
 
 MontePy can be thought of as having two layers: the syntax, and the semantic layers.
-The syntax layers handle the boring syntax things: like multi-line cards, and comments, etc.
-The semantic layer takes this information and makes sense of it, like what the material number in a cell card is.
+The syntax layers handle the boring syntax things: like multi-line inputs, and comments, etc.
+The semantic layer takes this information and makes sense of it, like what the material number in a cell input is.
 
 .. note::
 

doc/source/devguide/cell_modifier.rst

@@ -2,7 +2,7 @@
    :description lang=en:
         How to implement CellModifierInput subclasses in MontePy for data inputs that modify cells.
 
-Data Cards that Modify Cells: :class:`~montepy.data_inputs.cell_modifier.CellModifierInput`
+Data Inputs that Modify Cells: :class:`~montepy.data_inputs.cell_modifier.CellModifierInput`
 ============================================================================================
 This is a subclass of :class:`~montepy.data_inputs.data_input.DataInputAbstract` that is meant to handle data inputs that specify information about,
 and modify cells.

doc/source/devguide/collections_dev.rst

@@ -87,7 +87,7 @@ During init the inputs' "name word" (e.g., ``M3``, ``kcode``, ``f7:n``) is valid
 Conceptually these names can contain up to four sections.
 This information is stored in an instance of :class:`~montepy.input_parser.syntax_node.ClassifierNode`.
 
-#. A ``prefix_modifier`` this modifies the whole card with a special character such as ``*tr5``
+#. A ``prefix_modifier`` this modifies the whole input with a special character such as ``*tr5``
 #. A ``Prefix``, which is a series of letters that identifies the type such as ``m``
 #. A ``number``, which numbers it. These must be an unsigned integer.
 #. A particle classifier such as ``:n,p``.
@@ -117,7 +117,7 @@ How to Add an Object to :class:`~montepy.MCNP_Problem`
 
 The :class:`~montepy.MCNP_Problem` automatically consumes problem level data inputs,
 and adds them to itself.
-Cards this would be appropriate for would be things like ``mode`` and ``kcode``.
+Inputs this would be appropriate for would be things like ``mode`` and ``kcode``.
 To do this it uses the dictionary ``inputs_to_property`` in the ``__load_data_inputs_to_object`` method.
 To add a problem level data Object you need to
 

doc/source/devguide/mcnp_object.rst

@@ -7,7 +7,7 @@
 Input: :class:`~montepy.mcnp_object.MCNP_Object`
 =================================================
 
-All classes that represent a single input card *must* subclass this.
+All classes that represent a single input *must* subclass this.
 For example: some children are: :class:`~montepy.Cell`, :class:`~montepy.Surface`.
 
 How to ``__init__``

doc/source/devguide/pointers_generators.rst

@@ -42,11 +42,11 @@ if the surfaces did know, this would be bidirectional.
 
 So how do we decide which direction to point?
 In general we should default to MCNP.
-So a cell borrows a surface because a cell card in MCNP
+So a cell borrows a surface because a cell input in MCNP
 references surface numbers,
 and not vice versa.
 The exception to this is the case of inputs that modify another object.
-For example the ``MT`` card modifies its parent ``M`` card.
+For example the ``MT`` input modifies its parent ``M`` input.
 In general the parent object should own its children modifiers.
 This is an area of new development, and this may change.
 

doc/source/guide/cells.rst

@@ -66,10 +66,10 @@ Their importances will all be set to 0.
 Setting How Cell Data Gets Displayed in the Input File
 ------------------------------------------------------
 
-Much of the cell data can show up in the cell block or the data block, like the importance card.
+Much of the cell data can show up in the cell block or the data block, like the importance input.
 These are referred to MontePy as "cell modifiers".
 You can change how these cell modifiers are printed with :attr:`~montepy.MCNP_Problem.print_in_data_block`.
-This acts like a dictionary where the key is the MCNP card name.
+This acts like a dictionary where the key is the MCNP input name.
 So to make cell importance data show up in the cell block just run:
 ``problem.print_in_data_block["imp"] = False``.
 

doc/source/guide/reading_writing.rst

@@ -181,7 +181,7 @@ Information Kept
 #. The optional message block at the beginning of the problem (it's a niche feature; check out section :manual63:`4.4.1` of the user manual)
 #. The problem title
 #. ``C`` style comments (e.g., ``C this is a banana``)
-#. (Almost) all MCNP inputs (cards). Only the read input is discarded.
+#. (Almost) all MCNP inputs. Only the read input is discarded.
 #. Dollar sign comments (e.g., ``1 0 $ this is a banana``)
 #. Other user formatting and spaces. If extra spaces between values are given the space will be expanded or shortened to try to keep
    the position of the next value in the same spot as the length of the first value changes.
@@ -195,11 +195,11 @@ Information Kept
 
 Information Lost
 ^^^^^^^^^^^^^^^^
-#. Read cards. These are handled properly, but when written out these cards themselves will disappear.
-   When MontePy encounters a read card it notes the file in the card, and then discard the card.
+#. Read inputs. These are handled properly, but when written out these inputs themselves will disappear.
+   When MontePy encounters a read input it notes the file in the input, and then discards the input.
    It will then read these extra files and append their contents to the appropriate block.
-   So If you were to write out a problem that used the read card in the surface block the surface
-   cards in that file from the read card will appear at the end of the new surface block in the newly written file.
+   So If you were to write out a problem that used the read input in the surface block the surface
+   inputs in that file from the read input will appear at the end of the new surface block in the newly written file.
 
 .. note::