Jump to content

Michele Oliosi

Moderators
  • Posts

    733
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @nicolasrata indeed I think you have answered correctly here.
  2. 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.
  3. 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.
  4. 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 %".
  5. 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?
  6. @JamesLenton indeed, and glad that it worked !
  7. @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.
  8. 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).
  9. 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.
  10. Pnom without temperature correction means nominal power, and not maximum power. So in your example it is relative to 320kW.
  11. @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).
  12. Hi ! Which version of PVsyst are you running ? We will make some checks to see if we can reproduce this behavior
  13. If you can, let us know what you find that would be great.
  14. 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:
  15. 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.
×
×
  • Create New...