Skip to content

Catch key errors when selecting from module databases #417

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cwhanse opened this issue Feb 1, 2018 · 3 comments
Closed

Catch key errors when selecting from module databases #417

cwhanse opened this issue Feb 1, 2018 · 3 comments

Comments

@cwhanse
Copy link
Member

cwhanse commented Feb 1, 2018

See #413

@jkfm
Copy link
Contributor

jkfm commented Feb 2, 2018

Thanks for opening! Maybe we should also change the documentation to make this more obvious!

@cwhanse
Copy link
Member Author

cwhanse commented Aug 27, 2018

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.

@cwhanse
Copy link
Member Author

cwhanse commented Sep 5, 2018

Via #548

@cwhanse cwhanse closed this as completed Sep 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants