All Activity

With PVsyst version 7, it was an automatic mode for diffuse shading calculations for systems that involve trackers, in version 8 the automatic mode has been removed. Now, users are required to manually define a representative tracker for diffuse shading calculations. You define a representative tracker by clicking “Tools”, “Trackers diffuse shading definition”. In this tool you can choose to calculate the diffuse shading factor for all trackers, or select a representative tracker that will be used to evaluate the diffuse shading factors You can find more details about this update and instructions in the PVsyst Help documentation here: PVsyst Diffuse Losses with Tracking Systems. Indeed, many updates and improvements has been done since version 7.2.16 that especially concerning the near shadings. In general you can find the changes that has been done in the release notes and major changes are discussed in the forum in the links below: https://www.pvsyst.com/help/release-notes/index.html#exec-1--version-801 https://forum.pvsyst.com/forum/29-pvsyst-main-changes/

Continuing the question: I am thinking about 1 - ignoring this shape difference and count it as uncertainty, or 2 - Consider the module as monofacial, and "boost" GPOA values with the mantioned formula: E_Total = E_POA + E_Rear * 𝜑 or E_rear = RPOA * (1 - "Structural shading factor") The second option makes sense? If so, which formula would be more accurate? Thanks! Rafael

That's a very interesting topic! I am also carrying out a performance analysis, with RPOA measurement... Since it is not possible to use it on the .MET file (like GPOA), I am trying to fit the bifacial parameters (structure shading + transparent fraction) running multiple simulations and comparing the results (GlobBak) to the measured GPOA, to see which one fits best. Apart from the absolute values, all simulations showed the shape curve similar to GHI, while the measured curve showed a shape similar do GPOA: Is this have something to do with the assumption that the re-emitted irradiance is isotropic? This text below was taken from PVsyst help: Or am I doing something incorrect? Maybe "Globak" is not the right variable to compare with RPOA? Even so, would the shape of the curves would be that different? Best regards, Rafael

Thanks

I ran the same variant in PVsyst 8 and got a huge difference in near shading loss. Does it make sense? please see the highlighted cells below. the only difference between two is they were ran in two different versions:

Thanks but there is no such thing in V 7.2.16

Thank you Auriane - just to ensure that I have this correct, it's best to apply the rear-side structural shading factor to the measured RPOA because it is most important is to account for the light that is realistically reaching the rear side of the modules? This equation for E_rear would look something like the following using the measured RPOA... E_rear = RPOA * (1 - "Structural shading factor") So, please correct me if I'm wrong, but it sounds like it's accurate to say that GlobBak is not by itself analogous to measured RPOA because it has been reduced by a structural shading factor, where an unobstructed RPOA pyranometer would not be. I understand that what's most accurate may be to calculate the incident irradiance on the rear side of the module, but in my experience many engineers desire to modify measured sensor values as little as possible. In such a case, would it be more analogous to combine GlobBak + BackShd so that in the performance analysis both E_rear terms reflect the rear side irradiance before being reduced by the shading factor?

Hello, This limit that the error message is referring to is in the Project setting, not the advanced parameters. Kind regards

Hello, I have a problem in a grid connected project by 25kW MID 25KTL3-X inverter. It's my pleasure if anybody can kindly help. I selected Trina solar 720Wp Panel for my project then I tried to connect one 18 modules string to one MPPT input and 2x16 modules str ings to the other MPPT input. Although I changed the limits of PnomRatio and Oversizing array/inverter nominal power to 1.6 or even 2 the "inverter power strongly undersized" error message is still not cleared and I can not go to simulation step.

From a rear side measurement of the POA, you still have to apply a shading factor corresponding to the torque tube, cables, etc ("structure shading factor") in order to compute how much light effectively reaches your panel. This effective light corresponds to GlobBak. All relevant irradiance for bifacial calculation are defined here https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-results.html

Please verify the Trackers diffuse shading definition in the Tools tab. If you are not using the All trackers option, verify that a representative set of trackers have been chosen.

Pertaining to capacity or PR testing, the following equation is frequently referenced for total irradiance calculations: E_Total = E_POA + E_Rear * 𝜑 ...where 𝜑 is equal to the module bifaciality factor. My question concerns the E_Rear term: if a PV system has a pyranometer installed in the rear plane of array in such a way that it is unobstructed by structures such as the torque tube, and the E_Rear used for the physical PV system is the measured RPOA from this pyranometer, what do you recommend using for the E_Rear term to calculate an equivalent model-side E_Total? Would the E_Rear term be the output variable GlobBak, a combination of factors such as GlobBak + BackShd, or something else? Reference: Waters, Martin, Chris Deline, Johan Kemnitz, and Jeffrey Webber. 2019. Suggested Modifications for Bifacial Capacity Testing: Preprint. Golden, CO: National Renewable Energy Laboratory. NREL/ CP-5K00-73982. https://www.nrel.gov/docs/fy20osti/73982.pdf

I am adding this question under this thread as it might be a version-related issue similar to the above issue. I have two projects that are the same except for the shading layout. I see ~2% difference in the near shading loss (4.5% vs. 6.7%), which does not make sense for not such a big difference in their layout. The site is flat, and the module is First Solar so no backtracking. We have removed the trees, and the result didn't change. Could you please give us some idea of what we can check to nail down the source of the issue? We can't share the logs. Some screenshots are shared below.

Hello, In PVsyst version 8 you do not have any limitations of how many orientations you can define. Please update to the newest version. Kind regards

The backtracking is a strategy to avoid mutual shadings. Thus, in the morning and evening when the sun is low, as in your example, the trackers will avoid mutual shadings by tracking "backwards" . If you do not want to have this behavior, deselect the backtracking option.

Please update to the newest version If you must stay at version 7, you can mark all the tables and move the selection using the arrow, or define the height in the tools section:

Indeed, the loss fraction is set for STC (standard test conditions) and the simulation will be done in real conditions that will vary between sites.

hello my project is bigger one and it has 12 roof of many azimuth and i need a single pvsysts file for it how i can do that i see that using several azimuth max we can put is 8 azimuth thanks in advance for your reply

Does PVsyst have any stow- strategy in the simulation when backtracking is on. The reason I am asking is because in "orientation" tab when backtracking is on, the modules will go to stow at sunrise and sunset (when moving the sun in the screen shot below to the extreme ends)

My PVsyst version is 7.2.16.

Ohmic loss is proportional to power. Abu Dhabi has much higher irradiance compared to Berlin. Also, not sure if it is intentional, but you're simulating the 10th year of operation. If unintended, be sure to set it to year 1 on the degradation tab. Ohmic losses - PVsyst documentation

Hello, I did a similar test in version 8.0.18 and is seems to work as it should on my side. The zone to the left is places 0.5m above the ground the the zone to the right 5m above the ground. If the issue persist, please describe further how to reproduce it. Kind regards,

Hello, The two locations to define the partitions are equivalent. If you change one, the other will update. The example below is from the DEMO tracking system Annecy with strings of 20 modules in 2P The partition model is intended to represent the stringing configuration. Therefore, if a table contains one string (e.g., 26 modules), you should define a single rectangle in length (Y-direction), since all modules are electrically connected as one string. If a table contains multiple strings, a separate rectangle should be defined for each string. For example, if a table has 52 modules—corresponding to two strings—you should define two rectangles in length.

Yes the number of sheds will have an impact of the performance, considering that the first and the last rows are not accounted for in the same way, since they will not experience the same shading patterns as the tables in the middle of the system. When there are many rows, this difference may be neglected. You can read more about the impact in the following help page: https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-nbofsheds.html?h=number

I meant you have to change the date itself from 2059 to 2049 in your csv data before importing. The other files should not be changed. File name should not matter. If you struggle to do it, please send a request at support@pvsyst.com with your input csv data attached