Michele Oliosi
-
Posts
747 -
Joined
-
Last visited
Posts posted by Michele Oliosi
-
-
PVsyst usually takes the minimum pitch as default value for the backtracking algorithm. If only one of your trackers has a pitch of 6.24 this may explain what you observe.
Note that you can anyway override the backtracking parameters from the 3D scene > Tools menu > Backtracking management. -
Two corrections impacting electrical shading results
Release note:
- Shadings: the bottom cell size is now taken into account also when computing the shading factor table from the Near shadings window.
Between versions 8.0.0 and 8.0.11, the bottom cell width was not available in the Near shadings window calculations. Therefore, recomputing the shading factor tables by clicking the “Recompute” button, or computing the tables when prompted when closing the Near shadings window could lead to slightly incorrect results, especially for low sun heights.
Version 8.0.13 corrects this bug. Shading factor table calculations will be consistent no matter where they were called from. If you were using the "according to module strings" model in "Fast", it is possible that electrical shadings will slightly increase due to this correction.
Release note:
- Shadings, thin objects: the partition model results in presence of thin objects have been corrected. This may impact the simulation results, by increasing the electrical shadings slightly in some cases.
In previous patches of PVsyst 8, the electrical shading factor in the presence of thin objects, when using the fast simulation mode (table interpolation), was not calculated correctly. This could lead to an underestimate of electrical shading losses. Note that this bug was not present in version 7.
Moreover (also in previous PVsyst versions), whenever the total irradiance loss was lower than the electrical shading loss from normal objects (case with many thin objects), the electrical shading loss could also be underestimated. Although very rare, this case is now corrected as well.
Improvements of the bifacial view factor model
Release note:
- Bifacial: corrected calculation of the sky diffuse contribution on the rear side of the PV modules
This patch addresses several issues in the modeling of the sky diffuse on the rear side.
- The impact of the number of rows has been reassessed; it now better captures the fact that the rows at the extreme end of the array do not experience mutual shadings, for all diffuse components.
- The rear side diffuse view factor has been revised; a normalization factor now correctly depends on the tilt.
- A discretization effect that caused an East-West asymmetry for trackers has been fixed.
These issues were most impactful in the following two cases: systems with vertical tables, and systems with few rows of tables. With this correction, the modeling of irradiance on the front and on the rear have been harmonized and generally have a better match. However, the impact on the total system output remains small, amounting to less than 0.5% for most bifacial systems.
Note: Systems with a single table, or a single row of tables, can currently only be designed with “unlimited” orientations. A workaround duplicate all the elements in your 3D scene and place it sufficiently far away so that mutual shading effects are negligible.
Considering the power factor in the System window for sizing assistance
Release note:
- System design: Overload losses are now adjusted when a Power Factor is specified in “Energy Management”.
When requesting an inverter to produce reactive power, its overload conditions may be impacted. This will depend on its nominal power specifications.
If the nominal power (PNom) is specified as apparent power ([kVA]), a power limitation will apply in terms of active power according to the formula: PNom(active) [kW] = PNom(apparent) [kVA] × cos(φ).
Since PNom(active) is lower than PNom(apparent), overload losses increase and depend on the chosen power factor (cos(φ)). Once a yearly power factor is specified, the estimation of overload losses in both the System and Sizing windows will take this effect into account, indicated as “Overload loss, with PF”. This estimation now more closely reflects the values shown in the loss diagram.
Future versions will include the estimation of overload losses for monthly power factor as well.
A more detailed explanation is available in the Help section: https://www.pvsyst.com/help/project-design/grid-connected-system-definition/power-factor/index.html
Warning message “inverter is slightly/strongly undersized”
Release note:
- System Sizing: warning and error messages for inverter slightly and strongly undersized are now triggered at 2% and 4% overload losses, respectively. These errors are not fatal anymore.
In addition to the previous point (considering the power factor in the System window), the fatal error message “the inverter is strongly undersized” is no longer triggered at 3% overload loss. Instead, it is now issued as a warning that does not block the simulation.
For new projects, the threshold for displaying this message has been updated to 4%, acknowledging that moderate inverter overloading has become a common practice. For older projects, the threshold is still set at 3%, which can be modified in the parameters of the project.
-
@Pete if you can send the zipped project (Export button in the project window) as well as your result tables (including the batch results file if you used the batch) to the email address support@pvsyst.com
As usual with these investigations, comparing intermediate variables and not just the final energy gives good results in pinpointing the main effect. If ShdDLss is not the issue, then we should look at other variables before and after this point, to see if the energy increase is due to a specific loss or gain along the loss tree.
-
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.
-
On 4/15/2025 at 4:04 AM, Chen said:
"maximum average degradation factor"="1/2 of yearly warranty"="0.175%", right？
Why do you divide by two ? I am not sure I am following.
On 4/15/2025 at 4:04 AM, Chen said:"Average degradation factor"+2*"Imp/Vmp RMS dispersion" ＜ "The worse possible annual degradation rate (the upper limit of warranty is 0.35%) " ；
so that "Imp/Vmp RMS dispersion"="0.0875%" ，( 0.35% - 0.175%)/2= 0.0875%
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.
On 4/15/2025 at 4:25 AM, Chen said:The Average degradation value obtained from the the module warranty interface is 0.38%/ year. Is 0.38% used in the PV module ageing parameters input settings interface？should we change 0.35% to 0.38%？thanks!
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:
-
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).
-
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:
-
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).
Orientations and new 8.0 update
in How-to
Posted
This is a good remark, it will be useful for many users.
In principle, we do recommend trying to group orientations into fewer average orientations. Usually, orientations should fall into an average whenever there are identical nominal orientations (for example, despite the irregularities caused by a complex terrain), or when they fall into the same DC array, which will facilitate the “System” window definitions.
When there are notable differences, such as different ground types, backtracking parameters, types of racking, etc. it may be worth keeping separate orientations, of course. This will facilitate definitions. For example, if there are different ground types, determining albedo values for each of them makes sense.
However, the default behavior when importing a 3D drawing is not fully in tune with these recommendations, yet. Indeed, by default, the 3D import will separate orientations based on effective angles. Therefore, a necessary step is to regroup orientations. The simplest way is to select all concerned PV tables in the 3D scene, and then use the right-click menu to create an orientation from the selection. Any other method works here, as long as it allows for an educated grouping of orientations.
We are looking into improving this default behavior at the stage of 3D import. Ideally, we want this experience to be more in line with our recommendation of grouping orientations.