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.,

sandia_modules = pvlib.pvsystem.retrieve_sam('sapm')
module = sandia_modules['Seraphim_Solar_System_SRP_275_6PA']

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.

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions