Code refactoring and clear interface definitions
Closed this issue · 3 comments
The code could use a bit of refactoring, such that the interfaces are more clear and everything is only done in one place. A few things that occured to me (there might be more such issues):
-
prince.util
needs a cleanup. It currently contains a collection of function for widely different purposes. Several functions related to physics can be moved to other modules (ieget_AZN
toprince.data
.prince.util
should only containt technical function suchs for reading files, printing info, etc.
-> Moved to _deprecated module -
TheInterpolator
class is not used at the moment, remove?
-> Moved to _deprecated module -
(related to 1) The function for
util.get_AZN
to get mass and charge numbers is redundant withdata.PrinceSpecies
and explicitly depends on the NEUCOSMA ID definiton. This should be bundeled in one place (probablydata.PrinceSpecies
) to make it easier to switch the ID definitions later or include particles not defined in NEUCOSMA.
-> Not yet fully adressed, see issue #12 -
The energy grid is not handled consistetly throughout the code. There is the class
EnergyGrid
defining bins, centers, widths, etc. However several classes just copyEnergyGrid.bins
and then recompute the widths usingutil.bin_widths
and other functions. This should be bundled in one place, in case we might need different energy grids per species later.
-> Adressed, howeverutil.bin_widths
is still used for the grid in x=E_da/E_mo -
The Individual classes should not require a reference to a
PrinceRun
object, to make the actual dependencies more clear. -
Restructure cross_sections.py to a package with several submodules. The base class in one module, and the derived ones in other modules.
This refactoring should be done before or after the other changes, to not produce too many conflicts. We should settle on the interface definition before publishing the code, as not to later break compatibility.
- Restructure cross_sections.py to a package with several submodules. The base class in one module, and the derived ones in other modules.
I am currently working on this in the branch refactoring
OK, I keep track when refactoring is merged into master and then start my tasks