1.0.0 Alpha thread

[MicahGale]

Release

The alpha release of version 1.0.0 is now available on PyPI, and we need alpha testers.

To install this version specifically (in an isolated conda or virtual environment might be a good idea) run:

python -m pip install montepy==1.0.0a1

Changes

This release primarily focuses on redesigning the material interface. For details see the migration guide. Also the updated getting started guide shows how to use a lot of these new features.

The biggest change is that Material is no longer a wrapper of dictionary; it now behaves like a list.

This will make it a lot easier to do the following with materials:

• Query, edit, and add nuclides to a specific material
• Change what the default library, e.g., nlib=80c for a specific material
• Find all materials that contain certain nuclides
• Create a new nuclide intuitively: e.g., montepy.Nuclide("U-235m1.80c")
• Materials are now iterable themselves.

This will also make it a lot easier to work with MontePy objects in general by:

• If a typo in made in an attribute an error raised. This prevents cell.nuber = 5 from having no effect.
• Create new objects with their just their string version of the MCNP input. You can create a new cell with montepy.Cell("1 0 -2 imp:n=1"). In a lot of cases it's a better idea to do: problem.parse("1 0 -2 imp:n=1").

Features Added

Material Interface Changes

• Redesigned how Materials hold Material_Components. See migration guide
  Mat redesign #507
• Made it easier to create an Isotope (now Nuclide): montepy.Nuclide("H-1.80c")
  Improve Isotope Instantiation #505
• Improved material printing to avoid very long lists of components
  Material strings can become unruly. #144
• Allow querying for materials by components
  Allow querying materials by elements #95
• Added support for getting and setting default libraries, e.g., nlib, from a material
  Add support for particle specific libraries and default libraries.  #369
• Added most objects to the top level so they can be accessed like: montepy.Cell.
• Made Material.is_atom_fraction settable
  Make Material.is_atom_fraction settable #511

General Updates

• When a typo in an object attribute is made an Error is raised rather than silently having no effect
  Implement __slots__ to avoid user confusion #508
• Made NumberedObjectCollections act like a set
  Make NumberedObjectCollection act like a set #138
• Automatically added children objects, e.g., the surfaces in a cell, to the problem when the cell is added to the problem
  Remove duplicate objects without relying on Hashing #63
• Added ability to parse all MCNP objects from a string
  Improve ab initio DataCard __init__ #88
• Added function: MCNP_Problem.parse to parse arbitrary MCNP object
  Improve ab initio DataCard __init__ #88

Bugs Fixed

• Made it so that a material created from scratch can be written to file
  Can't make a material from scratch and export it. #512
• Added support for parsing materials with parameters mixed throughout the definition
  Support poorly formatted Material definitions #182

Breaking Changes

• Removed Material.material_components
  Mat redesign #507
• Removed Isotope and changed them to Nuclide
• Removed MCNP_Problem.add_cell_children_to_problem as it is no longer needed.

Feedback/ Ask

We ultimately need users to play with these changes in realistic situations, and find things that are broken, or that are not quite right. You can open new issues with this feedback or add them to this thread.

If you find MontePy useful, please give us a star.

Questions

Here are some open questions I have about the design I would like feedback on:

1. Should material.values and material.nuclides not be properties but functions?

   for nuclide in material.nuclides:
       pass 
   # vs
   for nuclide material.nuclides():
       pass

2. Does the way of specifying a montepy.Nuclide make sense?

3. Does the following ways of searching make sense and behave predictably?

   • nuclide in material
   • material.contains()
   • materials.get_containing()

[tjlaboss]

1. Should material.values and material.nuclides not be properties but functions?

Argument in favor of function:
The convention Material.values() implies it is more dict-like, whereas Material.values implies it is more DataFrame-like. values behaves like a generator in the same way that dict.values() does, so Material.values() feels more intuitive.

Argument in favor of property:
According to PEP8, "Designing for Inheritance":

Note 1: Try to keep the functional behavior side-effect free, although side-effects such as caching are generally fine.
Note 2: Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap.

Since these operations do not perform computationally expensive operations or have side effects or perform actions, they should be accessed as properties.

Therefore, IMO, the property notation is a better fit.

[MicahGale]

To be clear Material shouldn't be like a dictionary, it should be like a list, so Material.values() could also be misleading.