Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding OpenmcReader and Pebble Classes #1

Merged
merged 12 commits into from
Jun 4, 2024
3 changes: 3 additions & 0 deletions src/didymus/__about__.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@


__version__ = "0.1.0"
36 changes: 36 additions & 0 deletions src/didymus/pebble.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# imports

class Pebble:
'''
Class for a single pebble object. Contains information
necessary to determine the pebble location within the core
and track its material composition and unique id number.
'''

def __init__(self, coords, rad, mat_id, uniq_id, recirc=False):
'''
Initializes a single instance of a Pebble object.

Parameters
----------

coords : array
Array containing the x, y, and z coordinates of the pebble.
rad : float
Radius of the pebble, with the same units as core measurements.
mat_id : int or str
User-defined integer or string for the material in the pebble,
which multiple pebble objects can share.
uniq_id : int
User-defined integer for identifying a specific pebble.
Each uniq_id should be distinct.
recirc : bool
Boolean for determining if a given pebble should recirculate,
for use in multi-pass cycles. Defaults to False.

'''
self.coords = coords
self.rad = rad
self.mat_id = mat_id
self.uniq_id = uniq_id
self.recirc = recirc
62 changes: 62 additions & 0 deletions src/didymus/reader.py
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a more descriptive name for this file that would work better? reader_openmc? or just readers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @nsryan2's comment. I might offer mc_reader.py standing for monte carlo reader which could be OpenMC or Serpent.

@ZoeRichter if you plan to have more than one reader, you could consider borrowing some of @yardasol's code in Saltproc for reading data from Serpent/OpenMC (and others?) Maybe I'm misremembering the purpose of depcode @yardasol.

Regardless, the pattern I'm suggesting is to have a generic reader object and have the openmc or serpent specific readers inherit from it and use the super().__init__() function (see osier.Technology).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was on the fence about this specific implementation, actually. I initially started by creating it the way you suggested - by having a parent reader that's generic, and child classes for code-specific readers. But as I was making it, I realized the ones I knew enough about to be able to implement right now didn't actually have args in common, so I made the reader(s) distinct. I think going the other way (converting didymus to a given code format) will work best in that parent-child set up, however. Do you think it would still be best to organize them under an empty parent class?

Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# import here
import numpy as np
from didymus import pebble as peb


# defining code-specific readers here:
class OpenmcReader():
"""
Class for reading Openmc pebble coordinates from the
OpenMC pack_spheres() function into and arrary of
distinct Pebble objects.
"""

def __init__(self, coord_array):
'''
Initializes the OpenmcReader

Parameters
----------
coord_array : array
Array of center coordinates, in x, y, and z, from
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Array of center coordinates, in x, y, and z, from
Array of center coordinates, in x, y, and z from

the pack_spheres() function of OpenMC.

'''
self.coord_array = coord_array

def pebs(self, peb_rad, mat_ids, uniq_ids):
'''
Creates an array of didymus Pebble objects, using
the central coordinates in coord_array.

Parameters
----------
peb_rad : float
Radius of a single pebble, with units matching those
used to create center coordinates. Assumes all
pebbles are the same size.
mat_ids : array of int or str
Array containing the mat_ids associated with each pebble
center. While multiple pebbles can share the same mat_id,
the length of the mat_ids array should match coord_array.
uniq_ids : array of int
Array containing the uniq_ids associated with each pebble
center. Each pebble should have a distinct uniq_id.

Returns
----------
peb_array : array of Pebble objects
Array containing a unique Pebble object for each
coordinate provided in coord_array.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a little unclear here, is it an object for each x, y, z set or each x coordinate, each y coordinate, and each z coordinate? The former, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, it's a pebble object for each set of (x,y,z) coordinates in coord_array (each set corresponds to a specific pebble's center). Do you think "...for each centroid coordinate provided..." would be a better descriptor (bouncing off of Sam's suggested change in a later comment)?


'''
peb_array = []
for i, coord, in enumerate(self.coord_array):
peb_array.append(
peb.Pebble(
coord,
peb_rad,
mat_ids[i],
uniq_ids[i]))

return peb_array
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
peb_array = []
for i, coord, in enumerate(self.coord_array):
peb_array.append(
peb.Pebble(
coord,
peb_rad,
mat_ids[i],
uniq_ids[i]))
return peb_array
peb_array = [Pebble(coord, pebble_radius, mat_ids[i], pebble_ids[i]) for i, coord in enumerate(self.coord_array)]
return pebble_array

List comprehensions are faster. Is every pebble going to be a unique material? Should mat_ids be part of the initialization of the OpenMCReader? It seems cumbersome (and error prone) to have users generate id's for each pebble themselves.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each pebble will not necessarily be a unique material, I think it's more likely that you will have large numbers of the same pebble material (such as having a unique material description for each pass the pebbles have made through the core). I don't think having a default for the uniq_ids/pebble_ids is a bad thing, though.