All Activity

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

Is no of sheds affected the performance, what means by no of sheds, plz elaborate

I have changed the labels for the .MET files to 2049-2058 but all of a sudden, I am not seeing any files appearing in the TMY generation tab. Is this another bug in the system?

why not partition like this :