Accept albedo in weather input to ModelChain.run_model method

[cwhanse]

• Closes ModelChain should accept albedo in weather dataframe #1387
• I am familiar with the contributing guidelines
• Tests added
• [ ] Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Re-opens #1469.

Tests pvlib.irradiance and pvlib.clearsky functions with albedo as a Series.
Allows albedo to be specified as a column in weather for ModelChain methods.

[kandersolar]

Some very minor comments, but LGTM. I think we've said in the past that there's no need to add new functionality to SingleAxisTracker, but I don't mind leaving it in seeing as you've already gone to the effort of adding it :)

[wholmgren]

Thanks @cwhanse for the big lift.

[wholmgren]

I think we need similar test for Array.

[cwhanse]

I'm not seeing the gap to be filled by an Array test. PVSystem.get_irradiance is (mostly) a wrapper for Array.get_irradiance, so this PVSystem test confirms that data passes through to irradiance.get_total_irradiance and back.

[wholmgren]

That's true, but Array is an independent part of the API. So far we've been pretty good about testing that each layer of the API returns the correct values or make assertions that the correct parameters are passed through. A relatively easy approach would be to create a copy of test_PVSystem_multi_array_get_irradiance with values set for all of the optional method arguments.

I won't object if others think this is unnecessary.

[cwhanse]

Makes sense. It's just that we should construct a new solution due to changing the kwargs from default. test_PVSystem_multi_array_get_irradiance_multi_irrad confirms that PVSystem.get_irradiance and Array.get_irradiance return consistent values.

I note a small inconsistency has crept in: Array.get_irradiance defaults to the Hay-Davies model, whereas irradiance.get_total_irradiance defaults to the isotropic sky diffuse model.

[wholmgren]

@cwhanse this PR has one line that fails stickler. any other reasons to hold off on merging it?

[cwhanse]

@wholmgren it's ready as far as I know. I fixed that line.

[wholmgren]

@kanderso-nrel ready to merge?

[kandersolar]

Reading back through #1387, several people advocated for raising an error if albedo was specified in both weather and as a property of the PVSystem/Array, but I don't think this code does that. Oversight, or intentional?

[cwhanse]

Reading back through #1387, several people advocated for raising an error if albedo was specified in both weather and as a property of the PVSystem/Array, but I don't think this code does that. Oversight, or intentional?

Oversight. Code will be emended soon.

[cwhanse]

On third thought, I think the current behavior (weather albedo is used when present, otherwise PVSystem.arrays albedo is used) is better than either raising a warning or error if albedo is provided in both weather and on PVSystem.arrays.

The default for PVSystem.Array is 'albedo'=None, which results in an assigned albedo (either from surface_type or 0.25). No Array is instantiated without an albedo. weather containing 'albedo' would then always generate a warning or error.

[cwhanse]

One improvement that could be made: when albedo is on ModelChain.system.arrays, it is not currently being transferred to ModelChain.results.albedo. Make that part of this PR, or a follow-on? Done in this PR.