PVsystUser

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

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.

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.

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 :

Please see the green rectangle in the screenshot below. What do the shading lines that fall inside the green square represent? That area is outside of sun path for the project's location; why they have a specific shape if they don't have any meaning?

Could you please explain why?

I have created a custom Pan File in PVsyst 8 and imported it in PVsyst 7, there are few param (eg: Rsh and Rs. ) that has been changed. What could be the reason?

How to install previous version of PVsyst? The link is not working: https://www.pvsyst.com/download-pvsyst/

If February 29th is missing from a leap year weather dataset, does it affect only that specific day, or does it impact the rest of the year as well? For example, when importing NSRDB weather data for 2020 (a leap year) into PVsyst, but excluding February 29th from the dataset: Does the PVsyst output for March 1st still correspond to the actual March 1st? Or does PVsyst treat the March 1st data from the file as February 29th, thereby shifting all subsequent days? Additionally, when running PVsyst for a specific year, does the software calculate the sun position based on that exact year (e.g., accounting for leap years), or is the sun position fixed for each calendar day regardless of the year?

- You are right, the terrain has been included in the scene and that's what is causing the issue. - PVsyst 8 crashes every time I want to import the scene and that's why I am using PVsyst 7.4 -I have shared the project and log with the support team 4 days ago, before writing here but it seems this chat was more helpful and thank you!

I haven't chosen a good word. Instead of "similar" I should have said why there are still shading when there is no tree. From your answer I realized that's might be the effect of backtracking. Although I am surprised because backtracking is activated in both runs and I have checked it few times. Could it be a glitch?

I ran a similar scene (the only difference is that Tracking plane, horizontal N-S axis instead of Tilted Axis) and no iso shading diagram is generated: But I don't understand how one has tracking plane as horizontal N-S axis and the otehr one has tilted axis?

I have the same exact shading scene one with 30m and 10 m tall trees and one without trees, why: iso-shading diagram has loss line in both variant and they are very similar ? why the avg axis tilt is different between two variant?

How does PVsyst handle inverter shutdown due to cold temperatures? Edit Query

In other words: 4.2% is a normal average of monthly losses. Shouldn't this annual average reflect the lower irradiance/generation during winter?

GlobInc has no relation to soiling. What I wanted to understand is how PVsyst calculates the yearly average "Soiling" from monthly values? For example, in January, we have an 11.8% soiling loss, but since January has low irradiation and thus lower generation, this 11.8% loss might actually be smaller in impact than a 6.8% loss in March. When we weight the monthly losses with GlobInc, the annual average results in 2.8%. However, PVsyst suggests an annual average of 4.2%. How does PVsyst calculate this annual average, and how is the lower irradiance during winter reflected in this calculation?

How does PVsyst calculate that yearly average? Starting from monthly loss and calculating the POA-weighted average the yearly value is much lower than what PVsyst offers. Example is here:

I saw the help page below but E_Grid calculated based on TMY which itself is a statics entity.

What could be the possible source of difference in P50 and E-Grid simul. here:

If EArray is effective energy at the output of array (and right before entering the inverter) Why the inverter loss over nominal inv. power should be applied on the DC side before entering the inverter?

I sent the project! Thank you Andre!