Michele Oliosi

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?

@JamesLenton indeed, and glad that it worked !

@SPdesai Sorry it seems there was a wrong sign in my answer above. I have corrected it. The sign is positive. We are adding it back, indeed. Indeed, we expect that the rear POA sensor will not be shaded (mostly) by mounting structures or cables.

Hi ! Indeed, currently the backside and reflected irradiance modeling is quite picky. The idea is that the geometry it assumes is that of trackers on flat ground. The discrepancy between 3D scene and backside irradiance model therefore leads to this message, to warn users of the possible inaccuracy. However, there is no alternative model, and the approximation of flat ground is not too bad if the slope is only 5°. In other words: You can change an advanced parameter to ignore the axis tilt message: Home window > Settings > Edit advanced parameters: I think a good way currently is to build fixed tilt structures first and then use the "transform to trackers" option: This will ensure that you can use the row-to-row slope options which are available for fixed tilt arrays (if I am not mistaken).

I see, I have checked and indeed this is not the case. PVsyst 8 also has the same issue. I have created a ticket to fix this in a future patch.

Pnom without temperature correction means nominal power, and not maximum power. So in your example it is relative to 320kW.

@NGS In case you have a warning due to the average axis tilt not being horizontal: you can override this error in the following way. Home window > setting > Edit advanced parameters: Note that this is only forcing PVsyst to proceed, but the backside irradiance model is still modeling things with a zero axis tilt (which generates a discrepancy with the actual orientation, and means there will be some uncertainty in the results).

Hi ! Which version of PVsyst are you running ? We will make some checks to see if we can reproduce this behavior

If you can, let us know what you find that would be great.

Hi, It's more likely a problem of compatibility of the PVsyst output with the regional format on your Excel/Windows installation. In PVsyst you can try changing the format and see if anything helps There are also more options on Excel, but I'm no expert there:

I put a note in the ticket about this. By the way, to speed up things when you are running several simulations, you can use the representative tracker mode (3D scene > Tools > Trackers diffuse shadings definition). Although less precise if you are doing many iterations it can save much time.

If you follow Daniel's latter examples (1-0.4)/2 = 0.3%? Indeed here you would assume that the loss increases to 0.6% in one year so on average during the first year it is about half of that. But I am not sure if this assumption is good for all cases of LID. The value is certainly between (1-0.4/2) = 0.8% LID if it occurs during the first few hours, or 0.3% if you interpret the first year degradation value as a linearly increasing function without any further assumption. I would tendentially use the more conservative estimate of 0.8% LID.