Repair broken link in get_pvgis_hourly documentation

[ramaroesilva]

• Closes Broken link in pvlib.iotools.get_pvgis_hourly documentation #2508
• 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.

Repairs broken link in pvlib.iotools.get_pvgis_hourly identified #2508.

[RDaxini]

I see how 30 might have meant 3, but now these add up to 15% rather than the 14% stated in the docstring, so should this be 2 rather than 3, or is something else (the docstring?) wrong here?
@cwhanse @kandersolar ?

Suggested change

	>>> 'nameplate_rating': 1, 'age': 0, 'availability': 3}
	>>> 'nameplate_rating': 1, 'age': 0, 'availability': 2}

[ramaroesilva]

Had the same question myself @RDaxini ahaha

Had to google it to remind myself that the loss factors are not additive but multiplicative. So if you do (1-loss_factor) for each source and then multiply all of them you get something like 0.859 (i.e., 14% overall loss)

I thought of adding a remark on this to the documentation, but then I thought reviewers could find it a bit unnecessary....

[RDaxini]

Thanks for clarifying, that's my mistake! You can mark this conversation as resolved, and then one of the other maintainers will approve workflows and double check the PR before merging.

[kandersolar]

Indeed PVWatts losses combine multiplicatively; see the source code of pvlib.pvsystem.pvwatts_losses.

Regarding the typo: from the comment immediately above the dict, it looks like those parameter values are not supposed to reflect the defaults but rather an example set of user-specified values. I think the 30 was intentional then, and it defeats the purpose of the example to change it back to the default value :)

[ramaroesilva]

Agree with @kandersolar remark. Can you confirm if the workflow is what I should do now?

• revert the typo that wasn't a typo, commit locally and then push to my repository

[RDaxini]

• revert the typo that wasn't a typo, commit locally and then push to my repository

Sounds correct to me:)
You can make the change manually in the file, or I think there is a function in git to revert a specific commit too. Either is fine.

[ramaroesilva]

@RDaxini @kandersolar should be good to go :-)

[RDaxini]

My bad, thanks for clarifying. And, thanks for this fix.
Let's add a whatsnew entry and then I think we're good to go.

[ramaroesilva]

My bad, thanks for clarifying. And, thanks for this fix. Let's add a whatsnew entry and then I think we're good to go.

@RDaxini, once my PR is accepted should I directly edit it in pvlib's repository?

[RDaxini]

@RDaxini, once my PR is accepted should I directly edit it in pvlib's repository?

No need, another maintainer (with write access) will use another git feature to merge your changes into the main repository—like accepting tracked changes on a word document someone else has edited. This usually happens after a couple of approvals.

[ramaroesilva]

No need, another maintainer (with write access) will use another git feature to merge your changes into the main repository—like accepting tracked changes on a word document someone else has edited. This usually happens after a couple of approvals.

Sorry, my bad. I actually meant the whatsnew entry. Is that also on the maintainer?

[RDaxini]

Sorry, my bad. I actually meant the whatsnew entry. Is that also on the maintainer?

Oh right, no you can edit the file yourself on your branch and push the changes to this PR.

Side context:
We don't always document every small change in the whatsnew file, but as first-time contributor, (IMO) it would be good to have at least your name on the v0.13.1 whatsnew file. You can also add a short statement documenting the change you made, and link both the issue and PR.

[ramaroesilva]

Side context: We don't always document every small change in the whatsnew file, but as first-time contributor, (IMO) it would be good to have at least your name on the v0.13.1 whatsnew file. You can also add a short statement documenting the change you made, and link both the issue and PR.

Thanks for pushing for this. But following the initial premise, I will leave my whatsnew contribution for #2521, which is more meaningful :-)

[kandersolar]

Thanks @ramaroesilva!