-
Notifications
You must be signed in to change notification settings - Fork 500
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
Python source class refactor #2524
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this clear improvement @pshriwise. A few comments on readability and the test for compiled sources.
openmc/source.py
Outdated
Attributes | ||
---------- | ||
type : str | ||
Indicator of source type. One of ('source', 'mesh', 'file', 'compiled') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems redundant and potentially confusion to declare a Source
as type 'source'
. Perhaps choose something other than 'source'
for the default type. Maybe 'analytic'
, 'computed'
, ???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. I think matching the class name here makes sense ("independent"
). If we feel that this name isn't sufficiently descriptive then perhaps we should change both.
I also need to remove "mesh"
from the list here. These changes were initially added on top of my branch adding a mesh source class..
@@ -18,6 +18,6 @@ | |||
<particles>1000</particles> | |||
<batches>10</batches> | |||
<inactive>0</inactive> | |||
<source library="build/libsource.so" parameters="1e3" strength="1.0"/> | |||
<source strength="1.0" type="source"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This source should still have a 'library'
member, if I understand the changes to source.py
correctly.
…ted results are not null.
…ing error is raised when attrs are set on existing instance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lingering inconsistency in the string to be used for the type of the independent source. Wonder if that should be declared once at a high scope and reused?
docs/source/io_formats/settings.rst
Outdated
@@ -449,24 +449,29 @@ attributes/sub-elements: | |||
|
|||
*Default*: 1.0 | |||
|
|||
:type: | |||
Indicator of source type. One of ``independent_source``, ``file``, or ``compiled``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The files below only have type='independent'
- either this documentation or those files should change...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other classes use the unique component of the class name as their type, so we should do the same here. Updating that docstring now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR @pshriwise! In addition to the line comments, please search through the documentation (*.rst) for the needed name changes (openmc.Source as well as anything related to custom sources).
Co-authored-by: Paul Romano <[email protected]>
…id source type when reading from XML
… write particle type to XML.
Co-authored-by: Paul Romano <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two more small changes and then this is good to go!
openmc/source.py
Outdated
@property | ||
def file(self): | ||
return self._file | ||
|
||
@file.setter | ||
def file(self, filename: str): | ||
cv.check_type('source file', filename, str) | ||
self._file = filename |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The argument in the constructor is filename
but the property is file
. Since this is a new class, let's pick one and be consistent. In fact, it might be better to call it path
and make sure it accepts pathlib.Path
objects.
Co-authored-by: Paul Romano <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more little fixes needed:
Co-authored-by: Paul Romano <[email protected]>
Thanks again @pshriwise! |
The
Source
class currently holds attributes that allow it to specify sources that contain independent distributions to be sampled, file sources, and custom/compiled source libraries to be called to generate particles.On the C++ side, we have three classes that inherit from a common
Source
class:IndependentSource
,FileSource
, andCustomSource
.These changes refactor the Python API's source classes so that there are corresponding classes to those in the C++ interface.
Source
has been renamed toIndependentSource
and a new base class,Source
has been added to the module. Three classes inherit fromSource
:IndpendentSource
,FileSource
, andCompiledSource
. (I renamedCustomSource
toCompiledSource
in both the C++ and Python code since I think that name is more clear).This name change from
Source
toIndependentSource
is going to cause a lot of updates to user scripts/code. With that being, such a hassle I'd understand if we don't decide to keep that change just for the sake of parity between the C++ and Python classes. cue revival of a discussion about PyBind/automated wrapping hereIn terms of file specs, sources can now be identified by a
type
attribute on the XML element, but interestingly the logic in C++ for how these sources are created still holds, so oldsettings.xml
files should still work with the OpenMC executable if we don't change that code. This is not true for XML files, however. Older XML files can no longer be read into Python objects unless we use similar logic to that of the C++ code, which would make thetype
attribute just a placeholder for information. I'd be interested in others' thoughts here.