You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue contains several small proposals to improve source code readability in the depletion module.
Some key internal functions in openmc.deplete do not have docstrings:
Integrator._timed_deplete()
SIIntegrator._get_bos_data_from_operator()
Integrator._get_start_data()
Docstrings should be added to these functions.
Some classes/functions could benefit from different internal variable names:
Integrator._i_res. Maybe step_index
p used instead of source_rate in SIIntegrator.integrate()
x, n, bos_conc used interchangeably for the nuclide concentration in Integrator.integrate(), SIIntegrator.integrate(), Integrator._get_bos_data_from_operator(), etc. This also applies to n_list. We should pick one name and use it consistently across the entire codebase. I suggest concentration
res, res_list in the same functions as the above item. I suggest just expanding this to result.
n in deplete()
func in deplete() to something more descriptive (this function solves the depletion matrix).
I'd love to hear other's opinions on the naming scheme.
Rename the __call__() class methods to something more readable
Integrator.__call__() to something like Integrator.integrate_single_step()
IPFCramSolver.__call__() to something like IPFCramSolver.solve()
TransportOperator.__call__() to something like TransportOperator.simulate()
Collapse DepSystemSolver into IPFCramSolver
DepSystemSolver is an abstract class with a single abstract method, and only has a single child class (IPFCramSolver). I propose removing DepSystemSolver unless the intention is to build it out to enable other kinds of depletion matrix solvers.
Remove the matric_func parameter in deplete()
My understanding is that we exclusively use the Chain.form_matrix() function for this. Are there cases where we want to allow a user to write their own function to build the matrix?
Alternatives
Compatibility
This may require some changes to docstrings depending on what action is taken.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Description
This issue contains several small proposals to improve source code readability in the
depletion
module.openmc.deplete
do not have docstrings:Integrator._timed_deplete()
SIIntegrator._get_bos_data_from_operator()
Integrator._get_start_data()
Docstrings should be added to these functions.
Integrator._i_res
. Maybestep_index
p
used instead ofsource_rate
inSIIntegrator.integrate()
x
,n
,bos_conc
used interchangeably for the nuclide concentration inIntegrator.integrate()
,SIIntegrator.integrate()
,Integrator._get_bos_data_from_operator()
, etc. This also applies ton_list
. We should pick one name and use it consistently across the entire codebase. I suggestconcentration
res
,res_list
in the same functions as the above item. I suggest just expanding this toresult
.n
indeplete()
func
indeplete()
to something more descriptive (this function solves the depletion matrix).I'd love to hear other's opinions on the naming scheme.
__call__()
class methods to something more readableIntegrator.__call__()
to something likeIntegrator.integrate_single_step()
IPFCramSolver.__call__()
to something likeIPFCramSolver.solve()
TransportOperator.__call__()
to something likeTransportOperator.simulate()
DepSystemSolver
intoIPFCramSolver
DepSystemSolver
is an abstract class with a single abstract method, and only has a single child class (IPFCramSolver
). I propose removingDepSystemSolver
unless the intention is to build it out to enable other kinds of depletion matrix solvers.matric_func
parameter indeplete()
Chain.form_matrix()
function for this. Are there cases where we want to allow a user to write their own function to build the matrix?Alternatives
Compatibility
This may require some changes to docstrings depending on what action is taken.
The text was updated successfully, but these errors were encountered: