Michele Oliosi

Hi, I would suggest looking at more variables. I strongly suspect that the dominant loss factor is the losses on the diffuse component. These will have a less sharp decrease than other losses, especially in the case of backtracking, which zeroes-out the direct shading losses. You can take a look at ShdDLss and ShdALss.

Dear Ishan, Real sorry, your question is taking some time to answer. Unfortunately, there are some details that need to be understood. We are trying to provide as informed an answer as possible. We should be able to reply by the end of the week.

When importing, you should have multiple choices to define the orientation: Can you try "longest edge" ?

The issue of reflection is that it is not explicitly modeled by PVsyst (currently). You should therefore find an indirect way to estimate it, or, better, find another tool that is more adapted. Also you interested in the reflection as a directional quantity? (for the purposes of glare regulations, for example). Or is are you interested in the amount of light “lost” to reflection, as a way to understand the energy flows?

@Leticia Currently, albedo is still stored in the weather file as monthly coefficients. This means that the time series will be summarized into monthly values. The hourly time series will be exploited in a later patch. These coefficients can then be used in the project settings, but it still requires going to the project settings and click on the button to copy the values from the MET file. Since these coefficients can end up in the project settings, they are currently intended to be used for the far albedo.

Indeed, this is interesting. As you say, changing the backtracking pitch can be done in PVsyst, but not a different one for morning and evening. Thanks for the feedback !

Hi, this is an unfortunate error message, because it sometimes appears in situations that can actually be handled by the backtracking strategy. It does not depend on having a mixed orientation, rather it is due to dealing with a small number and/or dispersed trackers. You can change the following advanced parameter (home window > Settings > Edit advanced parameters) : You can try 50% or 75% before trying higher values until the error changes. This will affect how the statistics is taken when checking for this message. After the message has disappeared, it is recommended to enter the 3D scene and go to the menu Tools > Backtracking management. There you can review the second orientation, and review the backtracking parameters. If necessary, you can uncheck "automatic" and enter the pitch and other parameters manually.

@Debbie thanks for reporting this. It probably happens when the trackers are on a topography thus at different heights (even slightly) or different axis tilts. Can you confirm? I will create a new ticket to fix this.

Indeed, I have also been able to see confirm this on my side. I have added this to our internal discussion keypoints. We are working on another correction for 8.0.12 which depends on the number of rows. I think this will improve the noise that you see for low number of rows.

Unfortunately, I do not think there are sufficient studies on the aging of these types of modules for us to conclude on new guidelines on the dispersion of the aging. One way would be to contact manufacturers directly about that. In general, I would advise taking a conservative approach, and leave the default values when unsure. I personally would go on with the 0.4% by default.

@nicolasrata indeed I think you have answered correctly here.

Hi @smeredith sorry for the late response, and thanks for reviving this thread. I have made a ticket we will be looking into this possible issue soon.

Why do you divide by two ? I am not sure I am following. No, Imp RMS dispersion are not comparable to a degradation factor. You should first translate into a degradation of the Pmpp. This is done stochastically by PVsyst. The following is really important remark. In PVsyst we consider that the warranty is not equal to the actual degradation ! Therefore what you enter under "Module warranty" has no impact on the simulation. If you want to model the unrealistic scenario in which modules age according to the warranty, then my advice is the following. Simply enter 0.35% per year as average degradation factor, 0% for both RMS dispersions, and put 1% in LID loss (in the tab "Module quality - LID - Mismatch") (almost the same as you did in the screenshot). The lower warranty on the first year is often times due to the LID.

The degradation in PVsyst compounds the average degradation rate, and the fact that there is an RMSD in this degradation rate. The worse possible degradation rate is therefore AVG + 2*RMSD. A warranty is in principle below the worst case (because manufacturers need to play safe with these numbers). Therefore, you could estimate an upper limit for the degradation model by saying: WARRANTY > AVG + 2*RMSD (PMPP degradation). Note that given the first year degrading differently, this is not entirely correct. I also note that this warranty seems too good. But in this case, I do not think you should set "Vm RMS dispersion be set to 0.35/2 = 0.175 %".

This is a very interesting suggestion. Do you have an example of such setting specification ? Do you known if this is to account for irregularities on tracker placement, or rather to keep up with grid demands?