Repository navigation
Implementing a "plug-in model" architecture #373
Description
Issues #227 and #306, in addition to the existing Sandia and DeSoto device performance models, suggest that pvlib could benefit from a "plug-in model architecture" that would establish common API requirements that anyone need follow to plug in their performance models into the greater modeling chain.
I might be able to design something around the device performance models, but I wouldn't be able to do this quickly/easily for the inverter models, etc. I worry that this will be like herding cats, however!
Activity
wholmgren commentedon Sep 13, 2017
Sounds great, but I don't know what this means in practice. Can you be more specific about what this would look like? Would it be code or documentation?
As of now, contributors write a function that implements their model and conforms to the variable and style rules. Hopefully they (and the reviewers) try to make the API similar to existing functions with similar purposes. Then we have a handful of functions and methods that provide unified interfaces to different kinds of models (e.g. get_solarposition, total_irrad, get_clearsky). Finally, ModelChain provides a unified interface to multiple modeling steps. I am reluctant to ask contributors, particularly new contributors, to go through those library-wide integration steps, though.
Note that
ModelChainprovides support for user-defined models: http://pvlib-python.readthedocs.io/en/latest/modelchain.html#User-defined-modelswholmgren commentedon Jul 26, 2019
This blog post on entrypoints made me think of your plug in idea. Not sure what this would look like in practice either.
https://blog.danallan.com/posts/2019-07-24-use-entrypoints-more/
markcampanelli commentedon Jul 30, 2019
Python 3.7's dynamic module attributes offers a fairly lightweight plugin discovery mechanism: https://realpython.com/python37-new-features/#customization-of-module-attributes
I'm trying to absorb the above entrypoints approach to make an informed comparison.