Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
move pvsystem.retrieve_sam to iotools
See original GitHub issueWhat do people think about moving pvsystem.retrieve_sam into the iotools subpackage? First brought up in #436.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
PVLIB_Python Documentation - Read the Docs
Moved functions for cell temperature from pvsystem.py to temperature.py. ... Created pvlib.iotools.read_surfrad() to read NOAA SURFRAD data.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’m not sure what the practical advantage of splitting the function by module/inverter would be. The API would remain the same in that you’d have to specify a string for the specific module/inverter database. I guess we could have different functions for each database.
https://github.com/pvlib/pvlib-python/blob/f8921bd3879c4bcd9c0242005319729ab04ce7f6/pvlib/pvsystem.py#L1529-L1547
I’m in favor of moving it to iotools. I’d like to consider splitting that function into two, to read module and inverter parameters separately.