All Activity

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 :

We have two location to define partitioning: List and management of objects zoning > filed properties > partition What is the difference between these two and which one should we use? When the string length is 26 in 1P, is the screen shot below, a correct way of partitioning in zoning? if yes, why we use 2 for nb. of rectangles in width and not the string length (number of modules in series)? A visual guide can help a lot. The partitioning in confusing. even in the link below , they don't say where should we put string size? It just says how to define number of modules in height, but how about width? https://www.pvsyst.com/help/project-design/shadings/electrical-shadings-module-strings/partition-in-strings-of-modules.html#summary-for-common-cases

I changed this number to different values ( 0.5, 2m, 30m) and it seems it is not reflected anywhere. at least when having multiple zones with different distance from ground , they all look to at the same heigh :

Hello, In version 8 you can create multiple field types in the orientations window and assign different bifacial parameters to different sub-systems. Thus, even if the tilt and azimuth are identical, create 2 orientations and assign each orientation to a sub-array in the system window, corresponding to the two sub-systems with different pitch in the 3D scene. You find a similar example in the DEMO tracking system Annecy, variant VC5: 2 fields of Trackers with different pitch Kind regards

Dear Nikoloz, In PVsyst Stand-alone, there’s no inverter component by design: the load (“User’s needs”) is defined as an energy demand (kWh), independent of whether the end-use is DC or AC. If you do have AC loads through a battery inverter, PVsyst’s recommended approach is to model it as an efficiency penalty. They also state the rationale: stand-alone (battery) inverters are fundamentally different from grid-tied PV inverters, so they’re not handled via the usual inverter database and are planned for a future implementation. Regards,