Measuring front/back irradiance when mattype/rearMat == sky gives unexpected values

[ERafaelMartinez]

Hello everyone!

First of all, thanks for you contributions to this project. I've been using it recently to create some APV simulations, for which I defined a PV geometry by placing some modules in space. As shown in the following picture:

Computing the bifacial irradiance around the modules (front and back covers) seem to have worked out so far.

My issue appears when trying to compute the ground irradiance. My procedure is the following:

Place sensors in a mesh as fine as the computer takes in a reasonable amount of time (usually for testing I'm using 100x100). When defining the sensors, I write the linepts string for the front and the back side of the probes as shown in the code snippet below:

normal_vector = [0, 0, -1]

dx = (xmax - xmin) / (sensors_x - 1)
dy = (ymax - ymin) / (sensors_y - 1)

x = np.arange(xmin, xmax, dx)
y = np.arange(ymin, ymax, dy)
z = np.array([0.05])

# points on the frame of reference of the module
points = np.array(np.meshgrid(x, y, z)).T.reshape(-1, 3)

# write the points to a string for its further use
frontpts = ""
backpts = ""
for point in points:
    xpos = point[0]
    ypos = point[1]
    zpos = point[2]
    vx = normal_vector[0]
    vy = normal_vector[1]
    vz = normal_vector[2]
    frontpts += f"{xpos} {ypos} {zpos} {vx} {vy} {vz} \r"
    backpts += f"{xpos} {ypos} {zpos} {-vx} {-vy} {-vz} \r"

This frontpts, and backpts strings are something analogous to what the _linePtsMakeDict method produces, to then be passed into _irrPlot and ultimately used as input for the rtrace function. If my understanding is correct, for frontpts, the normal vector required is the one pointing towards the surface [0, 0, -1] (as it is the direction of the light in which we are interested (incoming radiation)), and then, for the backpts I take the negative [0, 0, 1], which corresponds to the same orientation but in oposite direction, so that the light measured is outgoing.

Given a timestep with daylight, using the gendaylit function, and setting the albedo to a numerical value of 0.25, the computations show something expected for the front side (or incoming radiation) as shown in the picture below:

However, when checking the "back side", i.e., the measured irradiance in the outgoing direction [0,0,1], i.e., the light reflected by the ground, i.e., the albedo, the values are super low for all of those points that are not directly under any of the panels. It seems like, only for the points that have any kind of object on top (i.e.,rearMat!=sky) the irradiance is getting calculated (and the value matches approximately the albedo of 0.25). For the others points, where rearMat==sky) the value is just too low, and does not represent a correct value. As a sample, please look the following picture:

Note that the only points that are coloured with a relatively higher value are the ones directly under the modules. In otherwords, for these, rearMat != sky, and for the others, rearMat == sky. To illustrate this, please look at how the results were exported:

This table shows the points where rearMat == sky, and therefore have an unexpected rear irradiance:

This other table shows the other case, here you can see that the Back/FrontRatio matches the albedo:

I wonder why is this happening. I really could not solve this issue so far. It may be related with how the sky is defined...? Any help and ideas is very much appreciated!

[stella51]

hi Rafael, did you manage to solve this? i'm interested as i'm trying to compute ground irradiance for APV systems as well, both for fixed and tracker structures

[shirubana]

Hi,

@ERafaelMartinez --- this is not an error, it is just not understanding what rtrace is doing. The sensors are like vectors, and they will provide you the irradiance value of the first material they encounter. In the case where you are pointing them to the sky, they are touching the sky at different parts of the diffuse sphere. The sky is divided into 145 (if I recall correctly) patches of different radiance values; the only real high values will be on the patch or position where the sun is.

I am not sure why you are trying to measure the albedo of the material as that is a property that you set already when you selected your ground albedo or material/

@stella51 please see our gallery of multiple agriPV tutorials https://bifacial-radiance.readthedocs.io/en/latest/examples.html, or if you have specific questions email me happy to help. There is also a newer trainign into bifacial_radiance use for agriPV here https://github.com/NREL/InSPIRE/tree/main/AgriPV-raytracing-training

[ERafaelMartinez]

Dear @shirubana and @stella51

Thank you for your response. Indeed I later figured out what you mention. As you correctly point out, I later found in a manual that when invoking rtrace, we have the options -i and -I. One of them triggers the calculation at the intersection of the vector and the next surface as you just described. The other one triggers the calculation at the exact given point.

The reason for my confusion is that I thought that the actual behavior was the latter.

With a small adaptation to the function where the rtrace is called, I could modify the option to produce the desired behavior.

Thank you for reaching out, and sorry for not sharing my findings earlier to close this issue.