Change setter for losses_model to allow it to set multiple loss funct…

[ncroft-b4]

…ions, anticipating more complex loss models. Adds self._dc_losses

• Closes #xxxx
• I am familiar with the contributing guidelines
• Tests added
• Updates entries to docs/sphinx/source/api.rst 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 and Milestone are assigned to the Pull Request and linked Issue.

[ncroft-b4]

The strategy I used here is to use the setter on losses_model to setup more than one loss functions attached to ModelChain. To start, self._dc_losses. In the future, a different losses_model input could setup multiple loss functions, such as self._soil_losses, self._ac_losses, etc.

It might be more appropriate to have a separate setter for each loss function, instead. But I thought it makes sense to keep a single user parameter that gets passed when setting up a ModelChain, i.e. 'pvwatts' or 'pvsyst', instead of multiple parameters for each loss function, and so it made sense to keep the single setter for the single parameter.

Would appreciate any comments on this direction before continuing further with possible future PRs to add on other loss functions, as discussed in #1069.

[ncroft-b4]

I added in some trial functions to pvsystem and modelchain in the second and third commits that add capability for calculating dc ohmic losses from a percentage input, that input being the percentage dc loss at STC. The idea would be that other loss functions could be added in a similar fashion. My next step for this push will be to add a test in test_pvsystem for the equivalent resistance function.

[cwhanse]

I'm OK with the direction this PR is taking. ModelChain.losses_model becomes an identifier for a set of loss models. Although here only a DC loss model is added, a set can grow to include irradiance, shading, soiling, etc. The set approach seems to be a practical strategy since loss models can overlap or conflict in different implementations (e.g., shading can be modeled as a reduction in irradiance, or could be accounted for by a factor applied to DC power).

[cwhanse]

Suggested change

	Calculates the equivalent resistance of the wires from a percent
	ohmic loss at STC, defined by the user as an input to loss_parameters.
	Equivalent resistance is calculated with the fucntion:
	Calculates the equivalent resistance of the wires from a percent
	ohmic loss at STC.
	Equivalent resistance is calculated with the fucntion:

[cwhanse]

This is the only DC loss applied by pvsyst? If no, is the plan to add to this method when other DC loss models are implemented?

[ncroft-b4]

In PVsyst you can also input ohms directly, which we could support pretty easily I think with a different loss parameter that uses the same model chain function but bypasses the equivalent resistance function. I want to investigate that more to confirm the method and then will work to implement.

[wholmgren]

I'm generally good with the basic function and method. I'm concerned about how this works with ModelChain. I think we're going to need to start breaking up the losses_model into a handful of options. From the pvwatts_losses kwargs, snow, soiling, wiring, and shading could all be treated with their own ModelChain kwargs.

[wholmgren]

spelling

[cwhanse]

@ncroft-b4 lmk if you'd like some help writing tests

[ncroft-b4]

@cwhanse I made an attempt at the tests. I would appreciate a review that I met the intention there.

[cwhanse]

@ncroft-b4 tests look OK so far. For coverage of line L953, the aoi method test is a model.

[ncroft-b4]

Would like to close this out in favor of #1168 which includes compatibility for arrays in the latest updates.