You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking further into this issue, I think the appropriate action is to add conditions to ModelChain.dc_model to protect against incompleteness or disagreement between module parameter sets and the selected DC model. However, I think there is value in wrapping pvsystem.retrieve_sam with a get_module_parameters(module name) function in the as-yet-unwritten pvlib.io_tools.
The problem we'd like to solve here, is to test module_parameters against dc_model to see if all required parameters are there.
Currently, we expect users to write into their main code two statements, e.g.,
then pass module as an argument when instantiating PVSystem, and select the matching DC model when instantiating ModelChain. If there's a mismatch between module and dc_model then an error will occur in the DC model function when the sought-for parameter is not found.
The only logical place in the current workflow to test the module keys against the dc_model, is at ModelChain.dc_model. Here, both model (the model name string) and system.module_parameters are available, and we can test for sufficient inputs. Barring objections, this is what I will do.
We could test at pvsystem.sapm but that would invite a precedent to test input at every function, which I think is overkill.
I think, in the long run, that many of the user difficulties with modules would be avoided by having pvlib.io_tools with a function get_module_parameters(module name) that would return module parameters (as a dict) if the module is found in the databases.
See #413
The text was updated successfully, but these errors were encountered: