port Purdue bifacial irradiance model from PVLib Matlab

[cwhanse]

PVLib MATLAB contains open source code for a model for front and rear surface irradiance, for bifacial modeling, in three files starting with "pvl_Purdue_". It would be valuable to port this model to python. The model takes the "infinite sheds" bifacial irradiance approach. #717

[cwhanse]

@nappaillav porting is doable, it would be a big effort though.

@wholmgren @mikofski The bifacial irradiance model is the major difference in capability between pvlib-python and Pvlib for MATLAB. Beyond that, Pvlib for MATLAB also has a set of functions to translate IV curves and estimate module-level series resistance, but I think these are of much less interest.

[nappaillav]

The matlab codes are well written with demo codes and examples. Hence porting is doable.
I'll look into the implementation and get back soon.

[mikofski]

Should we drop #717 then? it's nearly done, the last bit is just to integrate over the angles from zero to pi for each position on the front or back of the pv surface. I guess I should've checked the MATLAB pvlib first. How does it compare with nrel/bifacialvf? #717 has an advantage that it isn't limited by the number of rows in front of or behind the row in consideration.

[cwhanse]

@mikofski I think it is worth completing #717, and I'll volunteer to review. There are several variants of the "infinite sheds", 2D, modeling approach for back surface irradiance, each differing in details of effects accounted for/neglected, and calculation style. I don't see that industry has converged to one model and there have been several recent papers comparing among available models. From my point of view, more models is better at this stage of maturity.

[nappaillav]

Functions to implement from brief examination :

pvl_getaoi()

pvl_iam_martinruiz_components()

pvl_perez()

pvl_Purdue_albedo_model()
	VF_Integral_Diffuse()
	VF_Shadow()
	ViewFactor_Cross()
	ViewFactor_Gap()

I found equivalent pvl_getaoi() function in irradiance.py. Do let me know if there is any other equivalent functions available in pvlib-python.

[cwhanse]

pvl_iam_martinruiz_components.m corresponds to pvlib.iam_martinruiz_diffuse, I believe.
For pvl_perez.m we can use pvlib.irradiance.get_sky_diffuse with model='perez'.

The other functions are not in pvlib in any form.

[nappaillav]

I'm having doubts if pvlib.irradiance.get_sky_diffuse() corresponds to pvl_perez() or pvlib.irradiance.perez() because the matlab function returns [SkyDiffuse,SkyDiffuse_Iso,SkyDiffuse_Cir,SkyDiffuse_Hor]. This can be reproduced using the following parameter in perez(*,*,.., model='allsitescomposite1990', return_components=True) function.

We might also have to add acotd, atand, acosd and cotd to tools.py

[cwhanse]

Good point. pvlib.irradiance.get_sky_diffuse doesn't pass the return_components keyword to perez(). Would calling perez() as you describe work instead of calling get_sky_diffuse? No other sky diffuse model wrapped by get_sky_diffuse can return components so I don't think it's wise to elevate return_components.

As far as additional trig functions, please add them to bifacial.py as needed for this PR. We can move them to tools.py later if there are other uses in the library.

[wholmgren]

As far as additional trig functions, please add them to bifacial.py as needed for this PR. We can move them to tools.py later if there are other uses in the library.

I'd put them in tools.py to begin with since that's where the other trig functions live. Easier to maintain if they're all in one place even if some of them are not reused across the library. tools.py is also not part of the public API, so no need to worry about private functions.

Would calling perez() as you describe work instead of calling get_sky_diffuse? No other sky diffuse model wrapped by get_sky_diffuse can return components so I don't think it's wise to elevate return_components.

Agree, agree.

[nappaillav]

To start with I will add trigonometry to tools.py along with the tests.
@cwhanse Then I will update get_sky_diffuse() to return components rather than using perez().
Do correct me if I'm wrong :)

[cwhanse]

To start with I will add trigonometry to tools.py along with the tests.
Yes

@cwhanse Then I will update get_sky_diffuse() to return components rather than using perez().
Do correct me if I'm wrong :)
No. Please use perez() instead of updating get_sky_diffuse()

And thanks!

[nappaillav]

I have created a pull request for additional trigonometry function, can you please review the request.

[cwhanse]

I have created a pull request for additional trigonometry function, can you please review the request.

Code looks fine. Test failure is unrelated, don't worry about it.

[nappaillav]

I have a doubt wrt to pvlib.iam.martin_ruiz_diffuse(surface_tilt, a_r=0.16, c1=0.4244, c2=None) and
matlab function Rloss_Beam_Front, Rloss_Iso_Front, Rloss_Albedo_Front = pvl_iam_martinruiz_components(SurfTilt,AOI_Front,Rloss_Para). The python function returns iam_sky and iam_ground. how should i compute pvl_iam_martinruiz_components?

[cwhanse]

pvlib.iam.martin_ruiz_diffuse is the same as pvl_iam_martinruiz_components, I believe.

[nappaillav]

pvl_iam_martinruiz_components return 3 values [Rloss_Beam,Rloss_Iso,Rloss_Albedo] but pvlib.iam.martin_ruiz_diffuse returns iam_sky and iam_ground.

[cwhanse]

The value for Rloss_Beam is the output of pvlib.iam.martin_ruiz.

[nappaillav]

@cwhanse can you check the code and help me write unit test for pvl_Purdue_*.py code.

[nappaillav]

@cwhanse I have updated my code related to this issue and given a pull request. PR #1187

[cwhanse]

@pvlib/pvlib-maintainer I'm looking to clean up stale PRs in anticipation of merging #717. #914 and #1187 are attempts to port a Purdue bifacial model from Matlab to python. The concerns mentioned (but not described) here are unresolved.

Any objections to closing this issue and the two stale PRs?

[kandersolar]

No objection to closing stale PRs; we can always reopen if desired. Would it make sense to change this issue's goal to be an independent implementation consistent with the reference instead of porting the Matlab code?

[cwhanse]

Would it make sense to change this issue's goal to be an independent implementation consistent with the reference instead of porting the Matlab code?

It would. The concerns are details of implementation that are not specified in the paper and don't appear correct in the Matlab code. I believe there was a thesis behind the work, which I haven't looked for.

[cwhanse]

Closing due to merge of #717