Differences between bifacialvf and pvfactors

[tcapelle]

Hello, I just wanted to know the difference between both modelling approaches? Should not we join forces? Is there a 3D VF model somewhere I could work with, ideally not in matlab? I will probably get more answers at bifiPV next september. See you there, Thomas

[mikofski]

@anomam can probably answer this better, but I see the main difference between bifacialvf and pvfactors as this:

• pvfactors solves for equilibrium of radiosity on all surfaces using the radiation network analysis model developed by Antoni K. Oppenheim (Transactions of the ASME 1956). This is essentially an implicit model that is solved by matrix inversion, but requires view factors and emissivities of all surfaces. This is method is described in detail in Incorpera & DeWitt, "Fundamentals of Heat and Mass Transfer"
• bifacialvf is an explicit solution that uses view factors to consider irradiance from all surfaces, but not at equilibrium - for example it does not account for infinite reflections between say between the ground and the panels. Secondary reflections are considered higher order terms that are negligible.

Note: both bifacialvf and pvfactors are 2-dimensional models.

@shirubana has developed a 3-D model using raytracing that is bifacial_radiance. PV Lighthouse has also developed a 3-D raytracing model, I think it's called SunSolve.

AFAIK, no one has developed a 3-D view factor model, although I think it would be a welcome addition using either the radiosity network or the explicit method or both.

• that's my opinion

[anomam]

Hi @tcapelle , I agree about joining forces, but as mentioned by @mikofski the approaches are a bit different and I think there's value in keeping both around. Btw, it's great to see that there's a renewed effort to futher develop bifacialvf, I hadn't noticed until now :tada:

I'm not very knowledgeable about bifacialvf, but concerning the theory on pvfactors, the paper, and the docs should be helpful. I am also not aware of @mikofski's references, but we do cite Howell, J. R., Menguc, M. P., & Siegel, R. (2010). Thermal radiation heat transfer. CRC press which is probably similar. In any case and building on what was said above, generally the radiation equilibrium analysis cannot be solved by a matrix inversion because the terms are not linear wrt the unknowns (eg sigma * T^4, ...), but the intuition was that in the case of PV systems the emissivity term can be neglected because of the relatively low temperatures, which leads to a system that is linearly invertible, and you can also add "sky" terms to it in the context of PV systems with little efforts. So this is definitely "implicit" as mentioned above.

pvfactors does have an explicit mode since v1.0.2 called "fast" mode that is described here, and which leads to good approximations as well. I believe there is still a difference in how the view factors are calculated compared to bifacialvf even in explicit mode: I could be wrong, but I think that bifacialvf uses a "wedge"-type of approach to calculate view factors (as opposed to what pvfactors does: formulas from Howell) that allows it to naturally apply AOI losses to each wedge, and that's very useful especially when you compare to reference cell measurements. @cdeline and @mikofski can probably answer this better. (in pvfactors you currently need a bit of post-processing to include that)

@tcapelle I think you told me that you're already using bifacial_radiance, which relies on ray-tracing, and I think that's the best approach for 3D modeling at this moment. And I have doubts that a 3D view-factor approach would be as efficient as ray-tracing to calculate back surface irradiance, but I could be wrong.

I hope this helps!

[tcapelle]

Thanks for the answers, We have our own 3D-VF model here at INES and we are thinking about open source it, it is a matlab code that we may be porting to python/julia. Our results show that it very accurate. I found today this Sandia VF model that do 3D viewfactors.

I really like pvfactors, it is a very polished piece of software, I would like to port our 3D model in the same way (with a geometry class, vf class, etc...). I have not found a good 3D geometry library like shapely to do the meshing in 3D. I may need some help btw.

Regarding radiance, we have not been able to get good results to validate the model.

[cdeline]

Hi All! I can point you to a few validation studies of bifacial_radiance compared with the view factor model and other empirical models. They’re on the bifacial_radiance wiki: https://github.com/nrel/bifacial_radiance/wiki. I’m also attaching a comparison of 1-axis tracking system simulations, and a journal article that looked at a mock rooftop installation compared with simulations. Cheers! [cid:image001.png@01D54DCE.E39915C0]

[cdeline]

oops - attachments didn't go.. Try this one:

[cdeline]

Here's the journal paper: Ayala - Comparison of bifacial irradiance model prediction with field validation - JPV 2019.pdf

[tcapelle]

Hope to see you at Bifi! Greetings. Thomas

[tcapelle]

@anomam Have you benchmarked pvfactors against bifacialvf? I get very different results for the same config. I put a nb to show: https://gist.github.com/tcapelle/e5bf4ca8d11129fc676e24652c710df5

[anomam]

@anomam Have you benchmarked pvfactors against bifacialvf? I get very different results for the same config. I put a nb to show: https://gist.github.com/tcapelle/e5bf4ca8d11129fc676e24652c710df5

Hi @tcapelle , that's super interesting work, thanks for sharing! I would be very interested in learning more about the physical configuration of your system at some point if you have some time. I helped a little bit a former co-worker with this very recent benchmark from IEEE here, and it seemed like although there are differences on a timestep basis, it didn't seem to have a big impact on a rolled up energy gain basis (page 5). But I do need to spend some time to rigorously investigate the differences at some point, I just haven't had time unfortunately :(

[tcapelle]

@anomam thanks for the paper! Figure 4 confirms what I am seeing. The model is overestimating backside irradiance by a factor of 2 compared to a reference cell. I may need to install a backside pyrano!

Our config is not optimal, with some racking and less than perfect installation of reference cells. The distance between rows is huge (9 m) so very little contribution of interrow shading/reflection.

It was a very massive structure designed for monofacial, that we are testing with bifacial. The good thing is that I have a lot of data, with a 5 s interval, with real DNI measured on site.

[tcapelle]

It would be awesome that we share data to validate at as many locations as we can. We are building a paper similar to yours, including the 3D model, I will push to have a binder repo with every part of the paper to be reproducible.

[anomam]

It would be awesome that we share data to validate at as many locations as we can. We are building a paper similar to yours, including the 3D model, I will push to have a binder repo with every part of the paper to be reproducible.

That's awesome @tcapelle , it's actually one of the main reasons why we made pvfactors open-source; to collaborate with people in the industry and to build more accurate and usable models! So I'd be more than happy to help with this :)

[tcapelle]

Ok, I have created a PR to start comparing models.

[tcapelle]

@anomam @cdeline @shirubana I put a repo/notebook to compare pvfactors and bifacialvf. Can you take a look? I also put the data we used (one year, 5T interval, with reference cells).

[cdeline]

Thanks Thomas, this is a really interesting comparison. First of all, I really appreciate the work that you had done to speed up the bifacialvf engine - running your examples is much faster than what we currently have in bifacialvf. I'll have to look more closely at your methodology to see how you achieved it. I'd recommend implementing this speed-up in a future release.

I took a look at the comparisons, and it does appear that we have different Grear values - on the order of 35% different - for the 'front row' comparison that you showed. Our agreement is much better for an 'interior' simulation - within 7%. So this may mainly be a difference with the 'front' simulation. I have to admit that we have only compared the 'interior' simulation in bifacialvf with field data, and implemented it in SAM. We should take a look at the implementation to see if there is a problem here- it was originally written in C#, and moved over to Python, so maybe theres a bug somewhere in the translation?

Have you taken a look at the 1-axis tracking simulations by chance? I'd be interested to see the difference between bifacialvf and pvfactors here too.

[shirubana]

Hey! Thanks for starting this. I'll start taking a look today, as well as to the old bifacialvf code and the python ~ see what I can figure out.

[tcapelle]

@cdeline Haven't tried tracking with bfiacialvf yet. I need to make sure that the same tracking values are input to both models, so bypassing the internal tracking calculations. I don't know why my version should be faster, have not made significant changes, only replaced a while loop. I added a tracking example to the repo

[anomam]

@anomam @cdeline @shirubana I put a repo/notebook to compare pvfactors and bifacialvf. Can you take a look? I also put the data we used (one year, 5T interval, with reference cells).

Hey @tcapelle sorry for the delayed response as I was traveling. Thanks a lot for the amazing effort with the notebooks, this is super helpful as I'm starting to think more and more about why we have such big differences between the two packages. Recently I've been focusing a lot on speed improvements in pvfactors (releases v1.2.0, etc) to have an explicit mode that runs 8760 simulations in just a couple of seconds. I have to focus on more of this in the next few weeks but it's very much on my radar to add a new vf calculation class (or mode) that accounts for AOI losses. Hopefully for next month... My gut feeling tells me that it's probably where most of the difference comes from... and it would be great to cross it out if that's not the case.

[tcapelle]

@anomam If you need help doing that I am here!

[tcapelle]

@anomam regarding speed, have you thought about using vectorized code on GPU? I have been using torch as a direct replacement for numpy with good results.

[anomam]

@anomam regarding speed, have you thought about using vectorized code on GPU? I have been using torch as a direct replacement for numpy with good results.

Thanks for the tips @tcapelle ! For the moment I'm trying really hard to speed things up on CPUs since it's available to all users, but if that doesn't work out I'll definitely look into more exotic things like GPUs! 💯 Thx! I was able to speed up the explicit (fast) mode as of v1.2.0, leading to 8760 simulations running in less than 2 seconds, and that gave me great ideas for the full mode (reflection equilibrium). It's a different beast, but I'm onto something and I'm trying to allocate time to work on it :) I have good hopes we'll get a good boost there as well before the end of the year!

[tcapelle]

I am putting some effort on constructing a vectorized differentiable GPU compatible 3D viewfactors library, motivating everyon here to move out of matlab. I would really appreciate some guidelines from @anomam because I really like pvfactors code. www.github.com/tcapelle/vf3d I am currently developing a pytorch branch using as base geometry Kaolin and Kornia. My final goal, is having a completely differentiable framework so one can compute derivatives of height, tilt, pitch, etc.. for different metrics.

[anomam]

I am putting some effort on constructing a vectorized differentiable GPU compatible 3D viewfactors library, motivating everyon here to move out of matlab. I would really appreciate some guidelines from @anomam because I really like pvfactors code. www.github.com/tcapelle/vf3d I am currently developing a pytorch branch using as base geometry Kaolin and Kornia. My final goal, is having a completely differentiable framework so one can compute derivatives of height, tilt, pitch, etc.. for different metrics.

Hey @tcapelle, that sounds daunting but fun!! I'm spread super thin these days with all the changes happening at my company, but I'd love to help and provide some initial design inputs if you need it! Let's find a way to converse more efficiently :)

[tcapelle]

@anomam I would love your help!

[anomam]

Hi @tcapelle , you probably already know some of this but:

• pvfactors now runs full reflection 8760 simulations in 2 seconds since v1.3.0
• it can also account for AOI losses in different ways since v1.4.0, including the method from Bill Marion's paper (see tutorial on using AOI losses in the full mode)

Concerning the initial question you asked here; I was expecting drastic changes with AOI losses added to pvfactors, considering the big gaps observed between pvfactors and bifacialvf. But it was not enough to explain the kind of difference you found in your analysis:

But I just learned something new about bifacialvf via a co-worker that could explain it!

Hi @cdeline @shirubana , could you please tell me if my understanding below is correct? It seems like the only portion of the ground considered for ground reflections to the back surface of the PV rows is the one labeled as rtr in the schematics below.

But this can be a considerably smaller portion of the ground seen by the PV back side, especially if the rows are high up. Am I missing something? If that's correct, what are the justifications for considering just a portion of the ground and not its entirety? (I can think of computational speed for instance)

This is the best explanation I currently have that could explain why bifacialvf predicts much less irradiance compared to pvfactors, and as shown in @tcapelle 's analysis above.

@amir-asgharzadeh cc'ing you as this is a new hypothesis that could explain the gaps we saw in our benchmark paper.

[cdeline]

Hi all, thanks for taking a look. I'll have to circulate this around here over the next week, but at first glance based on the documentation in the getGroundShadeFactors() function you may be correct. Out of curiosity, for pvfactors, how large of an area do you consider for the ground reflected component? There will be diminishing returns as you include additional rtr distances in front and behind the set of modules...

[mikofski]

Hi @anomam , bifacialvf does not just consider a small portion of the ground. It discretizes the ground into many small segments indicated by n in the drawing. It discretizes across the ground because each discrete section of the ground has different view factors of the sky: Then bifacialvf discretizes the PV surface, and for each discrete segment, m on the PV surface, it integrates over 180 discrete angle bins, some of which see the ground, some of which see the reflection from the neighboring module, and some of which see the sky. For the angle bins from PV surface segment m that see the ground, each angle bin will see different ground segments n, which each have a different view factor (although assumed the same GHI and albedo). Also each angle bin will have a different IAM value (bifacialvf is using Snell's and Fresnel's laws to generate IAM from reflectivity, absorptivity, and glass parameters like index of refraction - perhaps this leads to differences?).

And just to clarify further, bifacialvf additionally looks 2 rows ahead and 2 rows behind when calculating the view factors for each segment n on the ground. For example, the segment n shown in the image in the paper is showing the vewfactor of the sky above the current row, but the bifacialvf code also looks at the view factor between the rows ahead and behind the current row as well 2 rows ahead and behind. How many rows it looks ahead and behind depends on whether you select front row, back row, or interior row - those are 3 options available. There's also a 4th option, single row.

Checkout bifacialvf.vf.getSkyConfigurationFactors:

This method determines the sky configuration factors for points on the ground from the leading edge of one row of PV panels to the leading edge of the next row of PV panels behind it. This row-to-row dimension is divided into 100 ground segments and a sky configuration factor is returned for each ground segment. The sky configuration factor represents the fraction of the isotropic diffuse sky radiation (unobstructed) that is present on the ground when partially obstructed by the rows of PV panels.

From here you can see that the ground is divide into 100 segments. For more insight, take a look at bifacialvf/tests/test_vf.py.

[anomam]

Hi all, thank you for the super quick replies. And happy Thanksgiving to those celebrating it!

Hi all, thanks for taking a look. I'll have to circulate this around here over the next week, but at first glance based on the documentation in the getGroundShadeFactors() function you may be correct. Out of curiosity, for pvfactors, how large of an area do you consider for the ground reflected component? There will be diminishing returns as you include additional rtr distances in front and behind the set of modules...

@cdeline ok, thanks a lot for checking it! I'm looking forward to having a definitive answer on that one. Per your question:

• pvfactors default behavior is to consider a ground that spans from -100 m to + 100 m, and it builds (any number of) PV rows starting at the 0m origin. But I haven't seen anyone use more than 5 PV rows, so the ground is generally an order of magnitude bigger than the PV array.
• the whole ground is considered for the ground reflections, there's no concept of rtr area in pvfactors. The only segmentation of the ground is due to the cut points, which define what part of the ground is seen by either the front or the back side of a PV row.

I'm not sure I understand the part on "diminishing returns" with additional rtr distances : ( Please could you elaborate?

@mikofski , thanks a lot for the reply as well! I think the part on discretization (of both the ground and the hemispheres) was already pretty clear to me. But to clarify my question, I'm asking more about what section of the ground does bifacialvf decide to discretize? And why? (ie the row-to-row dimension you cited)

[mikofski]

Ok, I see, then bifacialvf see the sky above the current row, the sky 2 rows in front and 2 rows in back, for a total of 5 rows. Then for each part on the surface, it integrates the full 180 that is viewable, which would include as much of the ground in front or behind as the angle allows it to view

[anomam]

@mikofski thanks, these are very good points, but I'm still a bit confused... Let's take the case of 2 PV rows like in the schematics from the paper If we look at the back side of the left PV row:

• Iike you just said, it does make sense that if you discretize the whole hemisphere from 0 to 180 degrees to calculate the view factors of that back surface, you would look at the whole ground (and of course the sky + the front of the right PV row) 👍
• but then I'm confused about the rtr section in the schematics. If you calculate the incident irradiance only for the n ground segments in the rtr section, but if your PV back surface sees ground areas outside of the rtr section, how do you know how much light is reflected from the ground outside of the rtr section to the back surface?

[mikofski]

Except for the first & last rows, and maybe the 2nd and 2nd to last rows, the internal rows are all identical. It's just something similar to this pattern over and over again, The shape of the curve would change depending on height above ground, flattening as pv surfaces go higher.

Therefore, if you are looking ahead of the rtr section, say near 0′ that's the same as looking at a segment near the end of the rtr say n[95:], and conversely if the angle is looking past the bottom of the pv surface behind it to see the ground of the row behind it, say near 90° to 110° that's like the front of the rtr section, say like n[:20].

And the view factors of the first & last rows are just (1-cos(tilt))/2,

Ok, I'm not sure exactly what bifacialvf does for the 2nd row and 2nd to last rows, but I think it probably treats them like interior rows, so perhaps there could be some small error, but that's only 2 rows out of what 100 or more? Peanuts. Do you think the treatment of the 2nd & 2nd to last could cause big difference?

Also this assumes that the pv array layout is uniform, same terrain slope, same pile heights of support structures, same rack size, etc.

Also if the height above ground is zero, then the pv surface can only see one rtr section.

[anomam]

That is SO interesting @mikofski , you're helping me so much, thank you! I think we're really getting to the bottom of this.

• I have to apologize for the following because it was very well written in the README file, but you just made me realize that bifacialvf always models 5 PV rows. That's new info on my end.
• Also, your explanation seems to confirm that there are some special approximations happening for the ground and concerning the location of the shadows, and for the incident irradiance on the ground (and therefore for ground reflections as well). What you're saying makes sense to me: if you're trying to model a large PV array, then the ground shadow pattern seen by the 'interior' PV rows is always the same, and it can therefore be approximated by what you describe is happening to the 'center' PV row in bifacialvf (index 3, in range [1 - 5])

But I don't think that's what @tcapelle was trying to model for his test site, and so that's where I'm getting very curious now. My understanding of @tcapelle 's PV system is that he's considering 2 due-south fixed-tilt PV rows, and he looked at the backside of the southernmost PV row. It's of interest to me as well because that's a similar situation to the one in @amir-asgharzadeh 's benchmark paper, for the Sandia fixed tilt PV system analysis. I haven't been able yet to put my hand on R&D test data for model validation and benchmark that was measured at a site with 5 PV rows... The most I've played with is 3 (single-axis trackers).

So in order to model @tcapelle 's site: his analysis models 2 PV rows in pvfactors, looking at the first one; and 5 PV rows in bifacialvf, looking at the first one as well.

• So now, is what you described below what's happening in bifacialvf for the ground seen by the back side of the first PV row? Or is the back side of the first PV row only seeing 1 rtr section? (@cdeline @shirubana please feel free to chime in)

Therefore, if you are looking ahead of the rtr section, say near 0′ that's the same as looking at a segment near the end of the rtr say n[95:], and conversely if the angle is looking past the bottom of the pv surface behind it to see the ground of the row behind it, say near 90° to 110° that's like the front of the rtr section, say like n[:20].

• also @tcapelle , I think that if we used your scripts to compare bifacialvf and pvfactors predictions for the back side of the center PV row in a system of 5 PV rows (index 3 in range [1 - 5]; and actually index 2 in range [0 - 4] in pvfactors) - and if I understand correctly what was just said - the predictions should be much closer between the two models. But it would be just for the sake of comparing the models since we don't seem to have measured data for this situation.

[shirubana]

Hi all,

@mikofski description is accurate of what bifacialvf is doing for the "interior row", however it also has a "first", "last" , and "single" row options that consider different sky view factors.

The drawback as you have found in the software is that while the sky view factors consider those 5 rows, the ground is only 1 row to row, and it should be more depending on the view blocked by the previous/following rows. This might be why we particularly see that at higher clearances it starts to underpredict more and more. @cdeline and I are going to try to modify/update this issue so thanks for bringing it up:)

[mikofski]

Personally, I think that we have a responsibility to portray realistic bifacial pv arrays to the industry. I think we have been doing a disservice testing & modelling small arrays, and then drawing conclusions and extrapolating performance to large arrays.

This might be why we particularly see that at higher clearances it starts to underpredict more and more

I think the reverse is also true for conclusions drawn from small arrays and extrapolated to big arrays. I have read that height is a major factor in bifacial arrays, and have even seen manufacturers recommend specific heights, but that's actually only true for very small arrays that mostly see the surrounding ground as @anomam and @tcapelle have indicated, but for a normal sized pv system of 1, 10, or 100 MW, height will play a smaller role than say gcr or tilt, because most of the rows are interior. EG in a 2, 3, or 5 row system the front row which sees all of the ground in front of it out to the horizon is 50%, 33%, 20% of the array. Ditto for the 2nd row which sees a little more than the 3rd row, but less than the 1st. But in a large array with 100 or 1000 rows then the front row is only 1% or 0.1%.

[shirubana]

On the front of validation, I was meaning to share this data with @tcapelle and all for a while. It's not a ton of rows, but it's very 3 long rows, with sensors facing the front and the back. It's what we used for the benchmarking and validation on [this paper ](https://ieeexplore.ieee.org/abstract/document/8534404)

I uploaded the[ data here](https://bit.ly/2OwE2VH)

[tcapelle]

On the front of validation, I was meaning to share this data with @tcapelle and all for a while. It's not a ton of rows, but it's very 3 long rows, with sensors facing the front and the back. It's what we used for the benchmarking and validation on [this paper ](https://ieeexplore.ieee.org/abstract/document/8534404)

I uploaded the[ data here](https://bit.ly/2OwE2VH)

Thanks! @florenthaffner @franciscoarayarojas take a look!

[FlorentHaffner]

On the front of validation, I was meaning to share this data with @tcapelle and all for a while. It's not a ton of rows, but it's very 3 long rows, with sensors facing the front and the back. It's what we used for the benchmarking and validation on [this paper ](https://ieeexplore.ieee.org/abstract/document/8534404)

I uploaded the[ data here](https://bit.ly/2OwE2VH)

Oh great !! Thanks @shirubana :)

[shirubana]

Okay we dug up a bit more. My last comment/impression based on what I remembered was wrong --it does consider more than just 1 rtr, so the underprediction is not due to this. It replicates the ground segments if the view includes adjacent rtrs. At the most extreme view angles ( which are probably inconsequential) where the one degree view angle views a ground segment greater than 0.99 rtr, it uses an average ground ghi for the rtr. So, it should be fine for horizontal orientations.

The way it works for "interior" rows is, the ground irradiance values for each dx gets calculated for one rtr, but when calculating "getBackSurfaceIrradiances" gets replicated as needed -- based on the first whole degree in arc that sees the ground, and last is 180.

[shirubana]

@tcapelle @FlorentHaffner @franciscoarayarojas @cdeline I updated the OTF experiment measurement files uploaded to be a lot more descriptive, included the reflectivity measurements ('albedo data'), more explanations overall and weather data, as well as our analysis functions (outdated from the current software versions). I hope this is useful! It's also been submitted it to the real NREL repository, I'll share the link when it becomes available for real.

[FlorentHaffner]

Hi all !

As some of you have seen at the bifi workshop, we developed at CEA a 3D view factor approach. It is on Matlab and can be used as it is but, as your tools, we still can imagine hundreds of improvements :)

As Thomas suggested in this conversation, we were thinking of making this 3D approach differentiable and open source on python, in order that all of you, and others, could use it and potentially contribute.

But for this, we need to build a (very (very)) strong case at CEA because they are quite reluctant to an open source solution for now. (They just see open source as a way to give valuable knowledge for free without any benefit)

That’s why I need you to make this happen sooner !

Do you have any document/presentation/insights/whatever it is that sums up all the “benefits” of making our approaches open source (indicators like number of persons using it, number of bugs found by someone else, number of external contributions). I have no idea what you could give me but if you have something consistent to convince my superiors to make our approach open source, just send them to me please ! If you don’t have anything like this, I’ll make my own based on what I can found on Github.

And hopefully in a few months we’ll make your 3D VF approach open source !

Thanks :)

[mikofski]

ICYMI: ask for data in favor of open source @cwhanse @wholmgren

[renegacitua]

@anomam Hi, i'm starting to use pvfactors, is a really great tool, but i had a question. Is the program capable of discretizing the terrain? I mean, I know that it consider the "cut points" and the shadow and not shadow areas, but it can consider a certain zone where I can consider a bigger value of albedo?

In other words, i want to quantify the impact of install a reflective surface on the front or under of the PV row, is this possible with pvfactors? What would you recommend me for this?

I appreciate your help, regards!

[shirubana]

@renegacitua I know bifacialVF discretizes the ground into a number that is currently set internally to 100, but could be very easily made an input. One of our proposal for the next cycle of funding is to be able to change the reflectivity of some of those zones to different values exactly for that :) We have a tutorial on bifacial_radiance to do that too ~ 14 - Cement Pavers example Here's an example of use of that sim (external) or some other ones were we do 'AgriPV' so there are sections that are a different albedo from the plants.

[renegacitua]

@renegacitua I know bifacialVF discretizes the ground into a number that is currently set internally to 100, but could be very easily made an input. One of our proposal for the next cycle of funding is to be able to change the reflectivity of some of those zones to different values exactly for that :) We have a tutorial on bifacial_radiance to do that too ~ 14 - Cement Pavers example Here's an example of use of that sim (external) or some other ones were we do 'AgriPV' so there are sections that are a different albedo from the plants.

@shirubana thanks for the advise, i been working with bifacial_radiance, its a really great tool but it takes time to understanding. I want to ask you two questions, 1) Do you have any book or source that explain how the ray-tracing works on a simulation? I mean how radiance works and how it compares to the reality (i mean the trajectory of the photon, etc...) 2) I want to import my own TMY file but i don't understand how and what the software needs, by what i understand it download an IWEC file and generate an Excel EPW file with two columns, is that the DNI and DHI by hour or something else?

Thanks for your help, keep safe!