Currently, our power system model classes source their parameters from both the user_config.ini file and API arguments. The default behavior is to use user_config.ini, but API arguments can override these settings.
Strengths of Current Setup:
Offers multiple ways to configure the model
Provides a baseline configuration for users
Weaknesses of Current Setup:
Unclear which parameter source takes precedence, leading to unexpected behavior
Hard to trace the origin of parameter values, leading to debugging difficulty
Tasks
[ ] Have a single Source of Truth. Choose either user_config.ini or API arguments as the primary configuration source. API arguments would be the logical choice if the software will be integrated into other projects. This provides a predictable and centralized configuration point.
[ ] Find a way to validate API Parameters. Enforce stricter validation of API parameters to ensure they are within acceptable ranges and of the correct data types.
[ ] Logging parameters. Implement logging to track the source and values of parameters used in each model run. This aids in debugging.
[ ] Configuration Class/Object: (Optional)? Introduce a dedicated configuration class or object to manage parameters, validation, and loading from various sources. This would improve code organization and maintainability.
Additional Notes:
Before making changes, assess the impact on existing users. If a major change is needed, consider a deprecation period for the old behavior.
Thoroughly test any changes to the configuration mechanism to ensure correctness and avoid regressions.
Update documentation to clearly explain the new configuration approach, including any changes to API usage or the user_config.ini structure.
Issue Description:
Currently, our power system model classes source their parameters from both the user_config.ini file and API arguments. The default behavior is to use user_config.ini, but API arguments can override these settings.
Strengths of Current Setup:
Weaknesses of Current Setup:
Tasks
Additional Notes: