Irradiance Model for solar plants in slope terrain

[JoseVinicius1998]

Second, my studies about the PVLib package don't have an irradiance model for solar plants in sloped terrains. I see; there is the tracking algorithm for slope terrain, but not for the irradiance model.
The features would be essential because there isn't this model in any other package, Python, and this implementation certainly will help some projects and academic studies.
At this moment, I am studying the development of an algorithm to improve the harvesting irradiance, considering bad weather in a solar plant installed in sloped terrain with bifacial panels. It would be perfect for this model to finish my studies.

[kandersolar]

Hi @JoseVinicius1998, can you clarify what part of the existing models is insufficient? Do you have a specific model in mind that pvlib should implement?

It's true that the ground-reflected and sky diffuse models assume a horizontal ground surface, so maybe there is room for improvement there. I doubt that the error is very large, assuming reasonably small terrain slope angles, but it would be interesting to see data about this.

Also this related thread might be useful for you: #1340

[JoseVinicius1998]

Thanks @kanderso-nrel for your attention. You gave me an good idea to study right now: to analyze the differences between the POA in a solar panels with a backtracking algorithm considering sloped terrain and other ignoring the sloped terrain.

But, backing to the problem, I would want to analyze the best angle to position a single-axis tracking considering all the environment conditions: bad weather, sloped terrain, different albedos, bifacial panels, and others. So, my idea is testing all the possibles angles to position a solar panel, and through the DNI, DHI and other parameters like slope_azimuth, slope_tilt, albedo, bifaciality, and others to check the best angle.

So I can compare the difference existent between this angle delivery for this idea and the traditional algorithm, to check how much is possible to improve the energy production.

[mikofski]

@kanderso-nrel I believe we considered applying the same rotation matrices from “slope-aware backtracking” to the ground plane in the “infinite sheds” model (rotating the solar vector to find the equivalent horizontal basis) but we decided to delay that until a later PR. If completed now, that might almost accommodate the POA calculation of panels on arbitrary slope except that the panels would still be constrained to a specific orientation wrt the ground, so not completely arbitrary. EG if the module surfaces have different (az, ze) than ground not sure if we would have that covered, maybe?

[kandersolar]

@mikofski I think there are some secondary things to consider in addition to rotating the solar vector and module orientations into the ground's reference frame. I haven't thought it through completely, but at least GCR is affected by frame rotations, and poa_ground_diffuse wouldn't be based on GHI anymore, I think you'd have to transpose DNI & DHI onto the tilted ground plane instead. There's also the issue that the sky dome isn't the full 180 degrees anymore since it has to cede some to the terrain ("diffuse horizon shading"?). Maybe it would be straightforward to accommodate all of that, but I think it would take some thought to make sure nothing is being overlooked.

@JoseVinicius1998, for estimating insolation gains from improved tracking, you might be interested in the references cited in this small conference paper: https://www.nrel.gov/docs/fy22osti/82811.pdf

[cwhanse]

Trying to wrap my mind around this: rotating the solar vector, or transposing to a new "horizontal" plane, both strike me as potentially confusing. Is there a way to adjust system tilt and system azimuth instead? That way, all the ground and module geometry stays in the Array instances.

[kandersolar]

Ah I was just thinking about how one might be able to "trick" the existing pvlib.bifacial.infinite_sheds code (which assumes flat terrain in several places) into modeling a sloped system in a conceptually consistent way. Wasn't thinking at all about how to cleanly integrate something like that into the pvlib classes.

[JoseVinicius1998]

@kanderso-nrel, this reference is exactly what I have studied; excellent paper. I have also used the pvlib.bifacial.infinite_sheds function in my simulations, and I believe the only difference would be my wish to consider a sloped terrain.

I let my thanks. Congratulations sirs. The PVLib package is a fantastic tool for solar plant simulations.

[spaneja]

Hey @JoseVinicius1998 - I am not sure I follow the request fully. To note, the irradiance functions in pvlib are not specific to terrain-type. Instead, tracker-rotations/surface_tilts can be calculated to fit undulating terrain-profiles (see pvlib.tracking.calc_axis_tilt and pvlib.tracking.calc_cross_axis_tilt in pvlib.tracking.singleaxis).

While @kanderso-nrel is correct in stating that ground-reflected and sky diffuse models assume a horizontal ground surface, I agree that the differences would be minor. Items like bifacial modules and albedo can be researched using the variety of transposition/other functions, but specific to terrain profile, there is no independent irradiance calculation.

Side note - thank you for the words on our paper!

[mikofski]

I believe on a slopped terrain, the view of the sky from a point on the module should be (cos(ψ1) - cos(ψ2))/2 where ψ2-ψ1 is the angle the subtends the view of the sky between the tops of neighboring modules. Even on a modest downward slope, this may give modules a slight advantage.

There are a few papers that use view factor algebra and Hottel’s crossed strings method to analyze adjacent rows on rooftops (http://dx.doi.org/10.1063/1.4943122). This method differs from pvlib, but should yield similar results.

As for albedo, in my opinion the slope doesn’t matter because GHI is defined on a horizontal plane, so I think only the horizontal distance between neighboring rows is needed to get the unobstructed ground reflection α(GHI). Then I think conservation of energy can be used to scale the ground reflectance from a different perhaps longer area. Finally the same view factor equation (cos(ψ1) - cos(ψ2))/2 can be used for each point on the ground or perhaps try that crossed strings method?

Like others have said, I don’t know how much of a difference this will make, maybe minor, so perhaps start by reading Appelbaum’s & Aronescu’s work to see what they found. Their contact info is on Research Gate https://www.researchgate.net/publication/297597252_View_factors_of_photovoltaic_collectors_on_Roof_Tops

[mikofski]

@kanderso-nrel it would be nice to revisit this goal of expanding infinite sheds or some 2D model to arbitrary mono-slopes. Does anyone have a reference we can use to go forward. I think the simple rotation matrix approach (like what we used for slope aware backtracking) can work here with some caveats on slope.

1. we can back out the GCR for the rotated reference frame, horiz_r2r_dist / cos(slope_beta) = sloped_r2r_dist but we would also need to back out the new "tilt" of the modules as well, assuming slope_beta is the slope perpendicular to the module racks, then the new tilt = tilt_beta - slope_beta?
2. GHI may not differ much if the slopes are modest, or we scale the GHI by the ratio of the horizontal distance between rows versus the distance along the slope, EG: GHI_slope = GHI*horiz_r2r_dist / sloped_r2r_dist = GHI*cos(slope_beta) or ~GHI for slopes <3-arcdegrees b/c `cos(3[deg]) = 0.99863
3. ignore changes in the sky dome, in the rotated reference frame the part it cedes to the ground is recovered by the slope in an infinite mono-plane

I think it's worth at least a try for slopes <10-deg (cos(10[deg]) = 0.985)

[kandersolar]

I don't have a reference. I have a nebulous goal of writing a paper extending previous view factor models to accommodate these more complex cases, but no concrete timeline to get it done.

[mikofski]

Maybe someone from SolarFarmer team could collaborate and/ or support? Do you know Javier Lorente? (@jalpelo)

[mikofski]

@pvlib/pvlib-core Coming back to this - at the very least, ignoring horizon, we could handle arbitrary azimuth easily enough by rotating the reference of the solar vector around the z-axis to line up with the system so that it appeared to be N*-S* aligned, this solves any horizon issues for now right?

I am looking at a dual-tilt case right now with modules facing slightly SE and NW, and I have to model it multiple times because I can't use infinite sheds to get the bifacial. That's crazy. I should be able to just enter the system azimuth and get the bifacial performance in one go. I'll try to put together a PR. Are we open to that?