[Feature request]: Refactor `gempyor.NPI` Into `gempyor.modifiers`

[TimothyWillard]

Label

documentation, docstring, enhancement, gempyor

Priority Label

medium priority

Is your feature request related to a problem? Please describe.

The modifiers code is currently located under the gempyor.NPI submodule for legacy reasons and contains duplicated code that is under tested and under documented. This makes working with the functionality contained here challenging, it's difficult to know if changes break existing behavior or has already been implemented elsewhere as well as makes it difficult to share code without creating circular dependency issues.

Is your feature request related to a new application, scenario round, pathogen? Please describe.

No response

Describe the solution you'd like

Ultimately move gempyor.NPI and all of its contents into a consolidated, tested, and documented gempyor.modifiers module. The current setup with an ABC that modifiers extend is good, the refactored Modifier ABC needs to have:

• An __init__ method that could build the modifiers from the properties of the class so subclasses don't have to have their own __init__ methods. (Including determination of relevant subpops, see Merge emcee_batch Into dev #404 (comment))
• Have get_reduction abstract method that subclasses have to implement.
• get_reduction_df that is a thin wrapper around get_reduction (unclear if get_reduction can just cover this or not).

A first step before making these larger end goal changes though would be to document and unit test the existing functionality. This will make migrating/refactoring much easier and safer to do.

[jcblemai]

Just as a suggestion: one might also want modifiers to be a single class instead of the current architecture that loads several objects. This would allow easier plotting and debugging and all.

Some code to apply modifiers is located in parameters.py and in utils.py (I think, or in some file in the NPI/ folder)