-
Notifications
You must be signed in to change notification settings - Fork 592
Open
Description
Description
This issue contains several small proposals to improve source code readability in the depletion module.
- Some key internal functions in
openmc.depletedo 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. Maybestep_indexpused instead ofsource_rateinSIIntegrator.integrate()x,n,bos_concused 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 suggestconcentrationres,res_listin the same functions as the above item. I suggest just expanding this toresult.nindeplete()funcindeplete()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 likeIntegrator.integrate_single_step()IPFCramSolver.__call__()to something likeIPFCramSolver.solve()TransportOperator.__call__()to something likeTransportOperator.simulate()
- Collapse
DepSystemSolverintoIPFCramSolver
DepSystemSolveris an abstract class with a single abstract method, and only has a single child class (IPFCramSolver). I propose removingDepSystemSolverunless the intention is to build it out to enable other kinds of depletion matrix solvers.
- Remove the
matric_funcparameter indeplete()
- 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.