Michele Oliosi

Part or most of the differences may come from the diffuse shadings calculation. With large scenes I would advise to always go through the 3D scene >Tools > Tracker diffuse shadings definition tool. Here is a help page that should cover this topic: https://www.pvsyst.com/help/tracking_diffuse.htm

Dear RobSolar, No at the moment this is not really possible. We have had a similar suggestion by various users recently, so we will try to address this issue in the future.

Dear @Hossam you are right and I was mistaken. When looking at yearly values the PR and PRTemp should agree. We need to track down the mistake here.

Only if the different strings are on different MPPT inputs. At the moment PVsyst won't handle inputs with different lengths of strings.

In terms of simulation, if the parameters are similar, the losses should be similar. Trying to get the two values to agree I would suggest the following: First of all a few things to check: If you are using the "fast" mode i.e. using the table, go to both shading factor tables (Near shadings > Table) and click on recompute. We have seen a few bugs where an incorrect older shading factor table was not recomputed automatically. If you can, use the "slow" mode (recomputed at each simulation step) and check whether the discrepancy still exists. Sometimes the shading factor table doesn't have enough resolution especially with complicated shadings. Nothing beats a visual check. You can use the shading animation for a day in winter to visual differences for a day in winter for example. Electrical shading losses are in yellow. You may find that shadings have different patterns in the two variants. If the differences persist, there may be another external reason / bug / parameter choice not listed above. You can send both projects at support@pvsyst.com we'll gladly have a look. Now I should make a comment about first solar modules vs Jinko Solar JKM400M-72HL-V and partitioning in general: The two modules have very different technologies, and they respond to shadings in different ways. Jinko solar is a half-cut cells module and when in portrait, you should partition it with two partitions (in height) per module row. On the other hand First Solar modules are thin film modules that are quite resilient to shadings as well. When installed in portrait, they will not suffer much from inter-row shadings. If shadings are only inter-row I think they advise to deactivate electrical shading losses, by using "linear shadings" instead of "according to strings" in PVsyst. Since you have other shading objects such as trees etc, which give more vertical shadings, I would suggest keeping the "according to strings" and lowering the fraction for electrical effect, for example to 30%. I would suggest sending them (First Solar people) an email for detailed guidelines, I am not too sure of how to determine a good fration for electrical effect in this case. Maybe someone on the forum has some info for First Solar modules in complex shading situations ? In general for partitioning, you can check the help page: https://www.pvsyst.com/help/shadings_partitioninstrings.htm we will be updating these pages again soon, but they already offer some guidelines for partitioning.

The risk is that some tables are constantly shaded throughout the simulation if they touch. In general though, the safety margin by PVsyst is quite ample so you can try disabling the interpenetration check as you did. Just make sure to compare results just as you did. We noted the issue about moving things one by one, we will try to improve on this point.

Hi, Thank you for the different comments. First of all, I am not sure that "partial shadings group" will help in your case. Indeed, it allows to take calculate the frontside shading factors using only part of the tables, but has no impact on system or orientation. If there are two nominal orientations in your scene, even though you use the partial shadings group, in "Orientation" there will still be two orientations. If I'm not mistaken the pitch used by the bifacial is still the average of the whole scene as well, not only the partial shadings group. Second, the bifacial model is limited in its use to a single orientation in "Orientations". If you want to avoid the issue of using the average orientation, you will have to do two different variants, each with its shading scene containing only the objects from group 1 or group 2, respectively. In future (long term) major version v8 we will link the bifacial model to the orientation so you don't need to split in two variants. But this is still in development. Changing the pitch rms limit serves the purpose of bypassing the error message in PVsyst and proceed by using the average pitch even though your scene has several pitches. So there is no direct effect on the simulation results. Again thanks for the comments and sorry for the complications for this kind of scenes. Your post will definitely help making PVsyst better in the future.

Sorry, at the moment there is no way in PVsyst. We have plans to improve this eventually. Even with rows of a single orientation the gain is ~5% (10% if ideal), so I would expect little gain for domes e.g. 1% or even less.

So far, the only way is to compute it manually. Solar fraction is defined as EUser / ELoad, so you can use the total EUser and total ELoad instead.

Dear Hossam, I would say this must be a coincidence, (taking the demo projects you can find different examples). Are you using the same weather data ?

PR and weather corrected PR are not the same of course, so they shouldn't be equal in general. Or do you mean you find a difference between your calculation and the PVsyst calculation? The issue has been fixed and you can follow the help page to see the formula ? Edit: in fact you are right, there seems to be still a small mistake. the PR and PR corrected for temperature should be the same for the yearly value. We will track down the error.

Sure, if you select custom tracker only that tracker (green) and the shading ones (orange) will be considered. Sorry in my previous answer I meant "if the threshold number found in the advanced parameters (default 40, but you may have changed) exceeds the total number of trackers in your 3D scene" + having selected "automatic". If you select custom tracker this will override the "automatic" setting.

Since the performance ratio is normalized to the plane irradiance, each month is not equivalent. The total PR should be a weighted average according to GlobInc.

Hi ! Thanks for the interest in this feature. Yes we are working on implementing that in PVsyst ! We will be trying to release it this year, but it's not possible to be more specific at the moment.

Hi, The interface is currently a bit unintuitive, but before clicking apply you should be able to check the radio button (the left circle) in front of "All tables of the scene". Clicking then on apply should then turn the checkbox automatically on.

If you have selected the option "all trackers" or if the threshold number found in the advanced parameters (default 40, but you may have changed) exceeds the total number of trackers in your 3D scene, the diffuse shading factors will take some time since all trackers will be used for the calculation. The time it takes depends drastically on the complexity of the scene and shading objects.

Sorry, at the moment it is not possible to have both monofacial and bifacial modules in the same system in PVsyst. This will be addressed in the future.

Hi ! https://forum.pvsyst.com/topic/3085-electrical-shading-losses-in-versions-73x/

After trying with the aging I was able to reproduce the error, although not in an extreme fashion as what happens in your project. Nonetheless, I will be able to post a detailed ticket to tackle the issue. EDIT: the error also appears in standard simulations in some cases.

Hi, I am sorry you are having such a bad experience. We will of course look into it. Regarding the quoted post, we had been waiting for a project that shows this error. You now mention the error is related to using the aging tool. Can you confirm that we are talking about the same error described here, with the updated info that you are using the aging tool ?

Cutting it short: the P75 yield is added to the report of a single TMY or reference year simulation if you go to Energy management > P50/P90 estimation. PVsyst cannot provide automatically a 25 year list of P75 values at the moment.

Hi, I don't think that the concepts of P50 and P75 always apply well to simulations over multiple years. Basically you get a P50 result when you simulate with an "average year" and "average parameters". When you run 25 years of simulations there are two cases: - You are using the same weather input file (an "average" one) for all of the simulations, and what changes is just the aging. In this case, it could make sense to call the results for each year a P50 estimate. However the P75, P90 etc depend on the uncertainty of the parameters (which you can define once in Energy management > P50/P90 estimation). For 25 years you would probably need to increase the uncertainty of the aging parameters as the years go by. This is not yet implemented. - You are using a time series to run 25 years. In this case you are not using "average weather files". So it is not possible to get a P50 value from that. You can use a 25 year time series to get a TMY with PVsyst. Using that file as "average weather" file will bring you back to the previous point. The multiplier to get the P75 value depends on the width of the distribution. Given a standard deviation sigma, the multiplier is (1-0.674*sigma).

Dear Yann, Could you reproduce the comparison with 7.2.21 instead of 7.2.6 ? There have been many patches in between, and several major errors have been corrected. I would feel more comfortable comparing more stable versions. There have been some changes in the electrical shadings evaluation. For this I would advise reading: The horizon losses have also had an improvement. From the release notes in 7.3.3: - Horizon (far shadings): the calculation of the horizon shading has been corrected for times the sun passes the horizon line. This may slightly change the simulation results

In fact it is compatible, as long as there is only one nominal orientation, that all tables have the same width, and that the pitch between tables is fairly regular. You can check this help page for more details: https://www.pvsyst.com/help/bifacial-conditions.htm

Uc > 32 seems to be very optimistic, although I do not have a strong basis for this argument. Since Uv = 0, this value depends on the particulars of the site (average wind speed) and of course the structure so it is difficult to say for sure. We do not know of any studies that recommend this value, but we may not be up to date. I would encourage you to discuss with your client the fact that this is well above the usual PVsyst defaults.